关系型数据库甚至其他数据库都吃内存，正常现象

应该是正常，sqlserver2005默认内存设置是无限大，只用那麼多的话证明那些足够它内部数据转换的了。 



手动设置 SQL Server 内存选项有两种主要方法：



第一种方法，将 min server memory 和 max server memory 设置为同一值。此值与达到该值后分配给 SQL Server 缓冲池的固定内存量相对应。



第二种方法，将 min server memory 和 max server memory 设置成一个内存范围。这种方法在系统或数据库管理员希望配置 SQL Server 实例，同时又要考虑在同一台计算机上运行的其他应用程序的内存需求时很有用。

min server memory 保证了 SQL Server 实例的缓冲池可用的最小内存量。SQL Server 不会在启动时立即分配 min server memory 指定的内存量。不过，除非降低 min server memory 的值，否则当内存使用量由于客户端负荷而达到该值后，SQL Server 不能从已分配的缓冲池中释放内存。

max server memory 避免了 SQL Server 缓冲池使用的内存量多于指定的内存量，这样剩余的可用内存可以用来快速启动其他应用程序。SQL Server 不会在启动时立即分配 max server memory 指定的内存量。内存使用量会随着 SQL Server 的需要增加，直到达到 max server memory 指定的值。除非提高 max server memory 的值，否则 SQL Server 不能超过此内存使用量。

应该是正常，sqlserver2005默认内存设置是无限大，只用那麼多的话证明那些足够它内部数据转换的了。 

手动设置 SQL Server 内存选项有两种主要方法：

第一种方法，将 min server memory 和 max server memory 设置为同一值。此值与达到该值后分配给 SQL Server 缓冲池的固定内存量相对应。

第二种方法，将 min server memory 和 max server memory 设置成一个内存范围。这种方法在系统或数据库管理员希望配置 SQL Server 实例，同时又要考虑在同一台计算机上运行的其他应用程序的内存需求时很有用。
min server memory 保证了 SQL Server 实例的缓冲池可用的最小内存量。SQL Server 不会在启动时立即分配 min server memory 指定的内存量。不过，除非降低 min server memory 的值，否则当内存使用量由于客户端负荷而达到该值后，SQL Server 不能从已分配的缓冲池中释放内存。
max server memory 避免了 SQL Server 缓冲池使用的内存量多于指定的内存量，这样剩余的可用内存可以用来快速启动其他应用程序。SQL Server 不会在启动时立即分配 max server memory 指定的内存量。内存使用量会随着 SQL Server 的需要增加，直到达到 max server memory 指定的值。除非提高 max server memory 的值，否则 SQL Server 不能超过此内存使用量。

主要内存用于：
1、缓存所需数据，sqlserver不直接操作磁盘上的数据，需要用时会从磁盘加载到内存，这部分是内存最大的消耗者，而且除非内存有压力，不然一般数据会驻留内存相当长的时间，除非重启或者用DBCC命令清除。
2、缓存执行计划，减少编译时间，降低CPU压力。提高重用机会
看sqlserver的内存不能仅看用了多少，还要借助某些计数器或者其他技术来识别是否有内存压力，可以看看我的文章：http://blog.csdn.net/dba_huangzj/article/details/8627000

内存这东西几本书都讲不完，大概就那样，不要过多在意用了多少，而是检查是否有压力。当然用的多还是要监控

有新的查询就会产生新的内存需求，变大是正常的

学习了，至于“如何识别是否有内存压力”，也就是我是不是要再加内存，这个问题，看了不太懂。
能再解释一下不？再加内存，也是耗完？

如果你现在内存没有压力，那就没必要加，sqlserver和windows还不至于不会调整内存使用。对于数据库，优化代码和设计往往才是根本，加资源还是要先考虑是否已经到达最大吞吐量。我的文章有介绍一些计数器，可以去监控一下是否到达建议的阈值

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

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

引用 楼主 skytear 的回复:

环境：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 启动帐号的lock page in memory。
这是推荐设置。

引用 9 楼 ap0405140 的回复:

看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，到时候看看效果。
另外，做一个一周自动重启一次的计划任务。

引用 17 楼 skytear 的回复:

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

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

引用 18 楼 SmithLiu328 的回复:

Quote: 引用 17 楼 skytear 的回复:

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

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

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

不需要周期性重启，周期性重启会导致日志回滚，同时服务重启后，日志再次的需要还原，同时，重启服务后，小数据库还好，大数据库容易在重启后的一段时间内疯狂的读盘，还有，经常重启服务有可能会导致数据库出现不可预知的疑难问题。

引用 19 楼 skytear 的回复:

Quote: 引用 18 楼 SmithLiu328 的回复:

Quote: 引用 17 楼 skytear 的回复:

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

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

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

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

--清除过程缓存
dbcc freeproccache
go

--清除数据缓存
dbcc dropcleanbuffers
go

引用 19 楼 skytear 的回复:

Quote: 引用 18 楼 SmithLiu328 的回复:

Quote: 引用 17 楼 skytear 的回复:

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

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

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

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