4.實例屬性中,設為動態使用內存. 这个是只的max min server memory吗，如果是就应该都没问题我之前提问过一贴，用的启动账号是local system而且两台的启动日志中都有Address Windowing Extensions is enabled.
buffer pool主要用于数据库页数据，sql语句，执行计划，网络包等。开启了awe后，buffer pool中的数据库页，放到了awe那部分内存，就是你说用了4G多的那个部分。 而其他的单页数据，包括：sql语句，执行计划，网络包等，还是存放在原来的4G内存的空间在出现701错误的时候，最好能看一下errorlog中的详细的错误信息，以确定，内存到底都用到哪儿去了。如果大部分都是被数据库页消耗了，那基本上是正常的。但也有可能是其他的，比如，执行计划缓存太多导致的原来的那个非常有限的4G内存吃紧， 因为正常情况下，如果是数据库页消耗很多，那么既然你开启了awe，他还可以继续往上涨，比如用到6G、7G的，就像你上面提到的通过sys.dm_os_memory_clerks中的awe，你能很清楚的awe的消耗。你上面提到的你的服务器是32位的16G内存，需要特别注意的是max server memory指的就是单页内存，也就是buffer pool，你设置的max server memory是否足够大，比如像你的系统可以设置为13个G，剩余的3个G可windows使用，以及sql server 的除数据库页的单页内存、多页内存使用。还有，开启了awe后，必须要开启Lock page in memory功能，这样sql server就会向windows申请自己的内存，永久的放到物理内存中，否则很容易被交换到硬盘上的页文件中。对了，你的服务器上只放了数据库，没有放应用服务器吧。
能帮忙看看log吗，我对比log中的错误跟现有的值，差别较大的就这一组现有： Buffer Counts Buffers ------------------------------ -------------------- Committed 1653218 Target 1769472 Hashed 1413290 Stolen Potential 50608 External Reservation 128 Min Free 512 Visible 137216 Available Paging File 530788 error log： Buffer Counts: Committed=522368 Target=1769472 Hashed=397166 Internal Reservation=27443 External Reservation=39534 Stolen Potential=-6465 Min Free=512 Visible=137216 Available Paging File=13630070784在晚上找了一篇文章，就是关于Stolen Potential为负数的情况： http://www.tuicool.com/articles/IjMzQf Having said that, it is evident if the value of stolen potential goes negative, there won’t be any further pages that Engine can steal from the Buffer Pool. Hence in such cases where stolen potential is negative, SQL Server will throw an OOM. 大概的意思是：很明显的，当stolen potential的值变为负时，数据库引擎就不能再从buffer pool中stolen更多的页(这里的stolen值的是直接committed的内存，不用先reserved的内存)，因此这种情况下，stolen potential为负，那么sql server就会抛出oom异常，也就是out of memory，也就是内存不足。
执行下面的语句，提交上来结果： select @@VERSION select counter_name, ltrim(cntr_value*1.0/1024/1024)+'G' from master.sys.dm_os_performance_counters where counter_name like '%target%server%memory%'or counter_name like '%total%memory%' Select sum(awe_allocated_kb)*1.0/1024/1024 as [AWE allocated, Gb] From sys.dm_os_memory_clerksselect top 5 type, SUM(single_pages_kb) as total_single_pages_kb, SUM(multi_pages_kb) as total_multi_pages_kb, SUM(virtual_memory_reserved_kb) as total_virtual_memory_reserved_kb, SUM(virtual_memory_committed_kb) as total_virtual_memory_committed_kb, SUM(awe_allocated_kb) as total_awe_allocated_kb, SUM(shared_memory_reserved_kb) as total_shared_memory_reserved_kb, SUM(shared_memory_committed_kb) as total_shared_memory_committed_kb from sys.dm_os_memory_clerks group by type order by SUM(single_pages_kb) desc
1.C:\boot.ini文件 添加 /PAE
2.本地安全策略-->鎖定內存分頁-->添加SQL Server執行帳號
3.啟用AWE選項,
use master
exec sp_configure 'show advanced options',1
reconfigure
exec sp_configure 'awe enabled',1
reconfigure
4.實例屬性中,設為動態使用內存.
5.重新啟動SQL Server服務.
我上面已经描述了问题了哦~~我有两台服务器，配置相同，一台开了pae选项，一台没开
都用sys.dm_os_memory_clerks查看awe占有内存量
开了的只占4.4G，没开的占13.8G有问题的就是这台开了pae的嘛
4.實例屬性中,設為動態使用內存.
这个是只的max min server memory吗，如果是就应该都没问题我之前提问过一贴，用的启动账号是local system而且两台的启动日志中都有Address Windowing Extensions is enabled.
而其他的单页数据，包括：sql语句，执行计划，网络包等，还是存放在原来的4G内存的空间在出现701错误的时候，最好能看一下errorlog中的详细的错误信息，以确定，内存到底都用到哪儿去了。如果大部分都是被数据库页消耗了，那基本上是正常的。但也有可能是其他的，比如，执行计划缓存太多导致的原来的那个非常有限的4G内存吃紧，
因为正常情况下，如果是数据库页消耗很多，那么既然你开启了awe，他还可以继续往上涨，比如用到6G、7G的，就像你上面提到的通过sys.dm_os_memory_clerks中的awe，你能很清楚的awe的消耗。你上面提到的你的服务器是32位的16G内存，需要特别注意的是max server memory指的就是单页内存，也就是buffer pool，你设置的max server memory是否足够大，比如像你的系统可以设置为13个G，剩余的3个G可windows使用，以及sql server 的除数据库页的单页内存、多页内存使用。还有，开启了awe后，必须要开启Lock page in memory功能，这样sql server就会向windows申请自己的内存，永久的放到物理内存中，否则很容易被交换到硬盘上的页文件中。对了，你的服务器上只放了数据库，没有放应用服务器吧。
建议测试跑一些耗内存的语句后再观测一下.另: 检查一下SQL2005 SP4补丁安装了没.
建议测试跑一些耗内存的语句后再观测一下.另: 检查一下SQL2005 SP4补丁安装了没.
先谢过两位大神的关注，我再重新描述一下问题跟环境
win03 32位企业版sp2补丁，16G内存
sql2005 企业版sp4补丁，已开启awe，设置12~14G内存，启动账户用的local system
在帖子http://bbs.csdn.net/topics/390613303中提到权限足够可以不用额外设置Lock page in memory然后有两个问题，一个是对于现在服务器是否不必要开启pae，关于hot-add的说法？
另一个就是701错误的问题，记得好像有一个singlepage是负的指数，而当前的正常运行的是正的
至于“可能跟服务器当时的负载有关,当负载小时,SQL进程不会占用那么大内存的.”
貌似不大可能，这台是网站服务器，使用量也是不小的
建议测试跑一些耗内存的语句后再观测一下.另: 检查一下SQL2005 SP4补丁安装了没.
先谢过两位大神的关注，我再重新描述一下问题跟环境
win03 32位企业版sp2补丁，16G内存
sql2005 企业版sp4补丁，已开启awe，设置12~14G内存，启动账户用的local system
在帖子http://bbs.csdn.net/topics/390613303中提到权限足够可以不用额外设置Lock page in memory然后有两个问题，一个是对于现在服务器是否不必要开启pae，关于hot-add的说法？
另一个就是701错误的问题，记得好像有一个singlepage是负的指数，而当前的正常运行的是正的
至于“可能跟服务器当时的负载有关,当负载小时,SQL进程不会占用那么大内存的.”
貌似不大可能，这台是网站服务器，使用量也是不小的上面，我提到，会否和awe的使用没关系，从你监控的情况来看，awe使用了大概4G多，不太可能是由于在分配数据页时，报无法分配内存，因为这个时候可以用更多的awe内存，awe内存的消耗也会更多。会不会是其他的单页内存，就是消耗的还是32位服务器的原始的那4G内存，因为那个内存是有限的，到了限制，就无法分配，必然会报错。
我没太理解“就是消耗的还是32位服务器的原始的那4G内存”，这句中的4G内存跟我提到awe中用的4G内存是什么区别呢？？从性能监视器上看，sql plan占用的比较高，而且这个库的数据量整体是不大的，那这也就是awe所占内存不能再增长的缘故吗？
我没太理解“就是消耗的还是32位服务器的原始的那4G内存”，这句中的4G内存跟我提到awe中用的4G内存是什么区别呢？？从性能监视器上看，sql plan占用的比较高，而且这个库的数据量整体是不大的，那这也就是awe所占内存不能再增长的缘故吗？“就是消耗的还是32位服务器的原始的那4G内存” 这里指的消耗的内存不是awe中的4G的内存，而是本来作为32位服务器，本来只能最大有4G的内存。“而且这个库的数据量整体是不大的，那这也就是awe所占内存不能再增长的缘故吗？” ：我觉得是这样的，
否则的话，数据量大，awe那部分内存，应该会不断增加。所以，报错的原因，可能是由于缓存的执行计划太多，比如，没有使用绑定变量，即席查询太多，无法重用执行计划，不仅导致每个语句都得解析，而且导致有限的内存中存储了大量的执行计划，而这部分内存，不能使用awe内存，只能是使用最原始的4G内存中的部分，所以最终导致了再次分配内存时报错。这是我大概想到的。
我查过计划缓存，大概有3千左右的数量，大部分是预定义语句，即席查询只占三分之一
这个评判数量过多有什么标准吗？
我查过计划缓存，大概有3千左右的数量，大部分是预定义语句，即席查询只占三分之一
这个评判数量过多有什么标准吗？一般，通过sql server 的dmv：
select sum(virtual_memory_reserved_kb),
--已提交
sum(virtual_memory_committed_kb) *1.0/ 1024 as virtual_committed_MB,
sum(single_pages_kb)*1.0/ 1024 as single_MB,
sum(multi_pages_kb)*1.0/ 1024 as multi_MB,
sum(awe_allocated_kb)*1.0/ 1024 as awe_MB --数据库页
from sys.dm_os_memory_clerks
一个是你的数据为大小，另一个是你的应用需要取到的数据的大小。例如，你的库只有4GB，那么AWE管理的内存也就是4G左右。
例如，你的库有10GB，但其中6GB是冷数据，应用程序从不访问，那你的AWE管理的内存也可能的4GB左右。另外对于32位的701错误，有两种情况，
一种是memtoleave内存不足造成的，这个错误只能通过升级到64位系统+64位SQL才能解决
一种是buffer pool内stolen内存不足，这个要监控具体哪些语句申请大内存造成的。
能帮忙看看log吗，我对比log中的错误跟现有的值，差别较大的就这一组现有：
Buffer Counts Buffers
------------------------------ --------------------
Committed 1653218
Target 1769472
Hashed 1413290
Stolen Potential 50608
External Reservation 128
Min Free 512
Visible 137216
Available Paging File 530788
error log：
Buffer Counts:
Committed=522368
Target=1769472
Hashed=397166
Internal Reservation=27443
External Reservation=39534
Stolen Potential=-6465
Min Free=512
Visible=137216
Available Paging File=13630070784
哦 不是，awe的内存和single都是在buffer pool里的，awe用来缓存数据库页，single是buffer pool中不超过8K的sql执行计划、网络包等
能帮忙看看log吗，我对比log中的错误跟现有的值，差别较大的就这一组现有：
Buffer Counts Buffers
------------------------------ --------------------
Committed 1653218
Target 1769472
Hashed 1413290
Stolen Potential 50608
External Reservation 128
Min Free 512
Visible 137216
Available Paging File 530788
error log：
Buffer Counts:
Committed=522368
Target=1769472
Hashed=397166
Internal Reservation=27443
External Reservation=39534
Stolen Potential=-6465
Min Free=512
Visible=137216
Available Paging File=13630070784在晚上找了一篇文章，就是关于Stolen Potential为负数的情况：
http://www.tuicool.com/articles/IjMzQf
Having said that, it is evident if the value of stolen potential goes negative, there won’t be any further pages that Engine can steal from the Buffer Pool. Hence in such cases where stolen potential is negative, SQL Server will throw an OOM. 大概的意思是：很明显的，当stolen potential的值变为负时，数据库引擎就不能再从buffer pool中stolen更多的页(这里的stolen值的是直接committed的内存，不用先reserved的内存)，因此这种情况下，stolen potential为负，那么sql server就会抛出oom异常，也就是out of memory，也就是内存不足。
是否可以是供更为详细的errorlog ?xp_readerrorlog
select @@VERSION
select counter_name, ltrim(cntr_value*1.0/1024/1024)+'G' from master.sys.dm_os_performance_counters
where counter_name like '%target%server%memory%'or counter_name like '%total%memory%'
Select sum(awe_allocated_kb)*1.0/1024/1024 as [AWE allocated, Gb] From sys.dm_os_memory_clerksselect top 5
type,
SUM(single_pages_kb) as total_single_pages_kb,
SUM(multi_pages_kb) as total_multi_pages_kb,
SUM(virtual_memory_reserved_kb) as total_virtual_memory_reserved_kb,
SUM(virtual_memory_committed_kb) as total_virtual_memory_committed_kb,
SUM(awe_allocated_kb) as total_awe_allocated_kb,
SUM(shared_memory_reserved_kb) as total_shared_memory_reserved_kb,
SUM(shared_memory_committed_kb) as total_shared_memory_committed_kb
from sys.dm_os_memory_clerks
group by type
order by SUM(single_pages_kb) desc
凌晨做了索引维护，现在awe占的内存上去了，应该是一直没使用到的缘故吧其他列值都是0了
据上面几位大神的指点，感觉应该是sql plan部分占的太多了，回头仔细研究研究这部分的优化另外，大神对我开始提到的服务器中是否必要开启pae这里能否再指点一二啊
不过一旦达到了，貌似它就不会吐出来了你是正确的。对于现在的硬件，PAE似乎不需要再关注了，很早以前在32位里才有设置。
另外，早点迁到64位能解决一些性能问题，因为AWE不能映射所有的内存申请，如29楼所述，难超2GB限制。
不过一旦达到了，貌似它就不会吐出来了你是正确的。对于现在的硬件，PAE似乎不需要再关注了，很早以前在32位里才有设置。
另外，早点迁到64位能解决一些性能问题，因为AWE不能映射所有的内存申请，如29楼所述，难超2GB限制。
这也不是我说让迁就能迁的问题啊~
不过就算是64位，好像查这个问题的时候也看到有内存错误的啊。。
os64 db64
os64 db32
这些组合下的pae awe的设置要求？
不过一旦达到了，貌似它就不会吐出来了你是正确的。对于现在的硬件，PAE似乎不需要再关注了，很早以前在32位里才有设置。
另外，早点迁到64位能解决一些性能问题，因为AWE不能映射所有的内存申请，如29楼所述，难超2GB限制。
这也不是我说让迁就能迁的问题啊~
不过就算是64位，好像查这个问题的时候也看到有内存错误的啊。。64位的确也有，但都是内存较小的情况下发生，比如4/8GB，内存再大点，发生的概率很小了。
各位大神~32位系统很难超2GB的限制，这里的2GB都是哪里用的啊？
awe是缓存数据页的，可以设置大小，single是sql执行计划之类的，最多2GB？
这个指数有阈值吗？性能计数器中哪个可以显示啊？
各位大神~32位系统很难超2GB的限制，这里的2GB都是哪里用的啊？
awe是缓存数据页的，可以设置大小，single是sql执行计划之类的，最多2GB？
这个指数有阈值吗？性能计数器中哪个可以显示啊？1.这2G主要用在了sql cache、连接、锁、优化时用的内存、授予工作空间的内存等，还有其他的。2.single主要就是sql cache，差不多2G，还有384MB的multi page内存哈。3.没有具体的阀值，但有计数器哈：
莫非这所谓的2G是single_pages_kb+multi_pages_kb+virtual_memory_committed_kb，
还有一小部分应该是sql server进程之外使用的multi page。