也问一个SQL Server 2005内存相关有关问题

2013-11-19

也问一个SQL Server 2005内存相关问题环境：Microsoft SQL Server 2005 - 9.00.4035.00 (X64)Nov 24 2008 1

也问一个SQL Server 2005内存相关问题
环境：Microsoft SQL Server 2005 - 9.00.4035.00 (X64) Nov 24 2008 16:17:31 Copyright (c) 1988-2005 Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.1 (Build 7600: )

最近发现，32G的内存，大部分情况下都是占用31.7G左右，原来好像一直在20G左右。
这个啥情况？
与此同时，数据库的性能貌似没啥变化。
也问一个SQL Server 2005内存相关有关问题

SQL Server 2005的默认配置没有动过，主要是不懂。
就这个情况，请指点。

SQL Server 2005的默认配置没有动过，主要是不懂。
就这个情况，请指点。

从你提供的数据来看，一切都是正常。
但不会是默认设置，这个明显配置了sql server 启动帐号的lock page in memory。
这是推荐设置。

[解决办法]

引用:

看SQL2005版本号,SQL2005 SP4补丁尚未安装喔,请安装一下..

SQL2005 SP4的版本号应该是 Microsoft SQL Server 2005 - 9.00.5069.00

我之前也遇过这个问题,安装SP补丁就正常了.

另: SQL Server服务器最好能定期(如每周)重启一下比较好.
[解决办法]
占用内存多，并不是大问题，因为按照sql server的默认内存设置是，系统有多少内存，sql server在有需要的时候就会用多少内存。

比如，我原来的公司，服务器是64位的，64G内存，基本上都是sql server占用的，只要性能上没问题，比如，咩有突然变慢的情况，就没什么大问题。

[解决办法]
另外，一般情况下，由于数据库容量比较大，比如100G，那么在执行查询的时候，就会把需要的数据缓存在内存中，以加快查询速度，所以你的sql server 占用接近30多G的内存，可能大部分都是缓存数据了。

还有，语句的解析，执行，也会消耗很多内存，比如，每个执行的sql语句、存储过程都会缓存在内存中，这样，当相同的语句再次执行，或者存储过程再次执行，那么就不用再次编译，就能执行，这样就节省了CPU时间。

但是，如果缓存了太多的sql语句，一般是由于应用程序中没有使用绑定变量，而这样的语句，又大量的执行，所以导致内存中缓存了大量的这种无法重用的语句，不仅好用大量内存，而且无法重用，导致浪费了很大内存，严重的时候，会导致内存不足现象。
[解决办法]
可以通过下面的dmv视图，来了解内存大概的使用情况，比如reserved和committed内存占用多少，数据页占了多少，stolen也就是单页占了多少，多页占了多少，如果是32位的话，开启了awe的话，awe占用了多少：

--包括:buffer pool中的database cache使用的内存,multi-page使用的内存,stolen memory(Single-page)使用的内存.
select 
    type,
    
sum(virtual_memory_reserved_kb) as [VM Reserved],   --从buffer pool中保留的大小

sum(virtual_memory_committed_kb) as [VM Committed], --从buffer pool中提交的大小

--是Buffer Pool里的Stolen Memory的大小.在Buffer Pool中通过Stolen分配的,也就是直接Commit分配的内存量.
sum(single_pages_kb) as [SinlgePage Allocator], 
 

--分配的多页内存量(KB)，是使用内存节点的多页分配器分配的内存量。此内存在buffer pool外分配，是SQL Server自己的代码使用的MemToLeave大小。
sum(multi_pages_kb) as [MultiPage Allocator],

--内存Clerk使用地址窗口化扩展插件(AWE)分配的内存量。当启用AWE时,只有缓冲池Clerk(MEMORYCLERK_SQLBUFFERPOOL)使用此机制，不可为空值。
    --可以由buffer pool使用的内存量
sum(awe_allocated_kb) as [AWE Allocated],

sum(shared_memory_reserved_kb) as [SM Reserved],   --内存Clerk保留的共享内存量,保留给共享内存和文件映射使用.

sum(shared_memory_committed_kb) as [SM Committed]  --内存Clerk提交的共享内存量,和上面的字段一起可以追踪Shared Memory的大小.

from sys.dm_os_memory_clerks 
group by type
order by type

[解决办法]
说明缓存了（Data Buffer and Other Buffer）那么多数据喽，正常
[解决办法]
另外，你可以通过下面的语句，连接一下缓存的执行计划，各种兑现类型占用了多少内存：



--库缓存(buffer pool中stolen的单页，Multi-page的多页)

--各种对象各占了多少内存：
select objtype, 
       sum(size_in_bytes) as sum_size_in_bytes, 
       count(bucketid) as cache_counts
from sys.dm_exec_cached_plans
group by objtype

[解决办法]

引用:

计划周六装个SP4，到时候看看效果。
另外，做一个一周自动重启一次的计划任务。

哥啊，没事你重启干嘛？找事情干？
[解决办法]
不需要周期性重启，周期性重启会导致日志回滚，同时服务重启后，日志再次的需要还原，同时，重启服务后，小数据库还好，大数据库容易在重启后的一段时间内疯狂的读盘，还有，经常重启服务有可能会导致数据库出现不可预知的疑难问题。
[解决办法]

引用:

Quote: 引用:

Quote: 引用:

计划周六装个SP4，到时候看看效果。
另外，做一个一周自动重启一次的计划任务。

哥啊，没事你重启干嘛？找事情干？

不是有人建议周期性重启吗？
重启后，是不是清理了一些长期不用的Buffer之类的？
昨天重启后，现在内存消耗一般在23G左右，原来一直是在31.多G。

确实会有效，但是一般也可以通过的命令来清理buffer，不过一定要在系统维护期内用，而不要在白天系统繁忙时用：

--清除过程缓存
dbcc freeproccache
go

--清除数据缓存
dbcc dropcleanbuffers
go
[解决办法]

引用:

Quote: 引用:

Quote: 引用:

计划周六装个SP4，到时候看看效果。
另外，做一个一周自动重启一次的计划任务。

哥啊，没事你重启干嘛？找事情干？

不是有人建议周期性重启吗？
重启后，是不是清理了一些长期不用的Buffer之类的？
昨天重启后，现在内存消耗一般在23G左右，原来一直是在31.多G。

任何DBMS都吃内存，太多太多人觉得SQLServer内存吃那么多是问题，根据某本书的说法，磁盘的速度比内存速度慢接近100万倍，而SQLServer直接操作内存而不是磁盘，每次需要数据才加载，少量数据到没问题，但是大量数据并发的时候，延时相当严重。并且重启会把最重要的一部分东西去掉——执行计划缓存，这样最少第一次运行的时候要重编译，CPU压力会增大。要通过监控内存的使用情况来分析是否存在问题，而不是从任务管理器里面看内存占用就觉得高、有问题。

热点排行