博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
SQL Server为啥使用了这么多内存?
阅读量:5962 次
发布时间:2019-06-19

本文共 2699 字,大约阅读时间需要 8 分钟。

原文地址:

SQL Server为啥使用了这么多内存?

SQL Server的用户,常常会发现SQL进程使用了很多内存。这些内存大多数都是用来缓存用户要访问的数据,以达到最优的效率。那怎么能够知道哪些数据现在正缓存在内存中呢?其实,数据库管理员跑几句查询,就能得到答案。

 

谁占用了我的Buffer Pool?

 

我在做SQL Server 7.0技术支持的时候有客户问我,“我的SQL Server buffer pool很大,有办法知道是哪些对象吃掉我的buffer Pool内存么?比方说,能否知道是哪个数据库,哪个表,哪个index占用了buffer Pool么?”当时我没有找到这个问题的答案,但是我一直记着这个问题。直到SQL server 2005 版本出现,这个问题迎刃而解。答案就是使用动态视图(DMV) sys.dm_os_buffer_descriptors。这个DMV非常强大。根据SQL Server 联机丛书,这个视图的作用是 “返回有关 SQL Server 缓冲池中当前所有数据页的信息。可以使用该视图的输出,根据数据库、对象或类型来确定缓冲池内数据库页的分布”。具体点说,这个视图能够返回buffer pool里面一个8K 的data page的下列属性: (1)该页属于哪个数据库 (2)该页属于数据库哪个文件 (3)该页的Page_ID (4)该页的类型。可以根据这个来判断此页时索引页还是数据页 (5)该页内有多少行数据 (6)该页有多少可用空间。 (7)该页从磁盘读取以来是否修改过。 有了上面的信息,我们就可以很方便的统计出几种很有用的数据,如下。

 

    1. Buffer Pool的内存主要是由那个数据库占了?

SELECT count(*)*8  as cached_pages_kb,CASE database_id

        WHEN 32767 THEN 'ResourceDb'

        ELSE db_name(database_id)

        END AS Database_name

FROM sys.dm_os_buffer_descriptors

GROUP BY db_name(database_id) ,database_id

ORDER BY cached_pages_kb DESC;

结果如下: 从上面的结果可以看到数据库AdventureWorks占用了大概30MB左右的缓冲池空间。 注意该DMV 并不返回Buffer Pool里面有关非数据页(如执行计划的缓存等)的信息。也就是说这个DMV并没有返回Buffer Pool里面所有页面的信息。

 

    2. 再具体一点,当前数据库的哪个表或者索引占用Pool缓冲空间最多?

SELECT count(*)*8 AS cached_pages_kb

    ,obj.name ,obj.index_id,b.type_desc,b.name

FROM sys.dm_os_buffer_descriptors AS bd

    INNER JOIN

    (

        SELECT object_name(object_id) AS name

            ,index_id ,allocation_unit_id,object_id

        FROM sys.allocation_units AS au

            INNER JOIN sys.partitions AS p

                ON au.container_id = p.hobt_id

                    AND (au.type = 1 OR au.type = 3)

        UNION ALL

        SELECT object_name(object_id) AS name  

            ,index_id, allocation_unit_id,object_id

        FROM sys.allocation_units AS au

            INNER JOIN sys.partitions AS p

                ON au.container_id = p.partition_id

                    AND au.type = 2

    ) AS obj

        ON bd.allocation_unit_id = obj.allocation_unit_id

        LEFT JOIN sys.indexes b on b.object_id = obj.object_id AND b.index_id = obj.index_id

 

WHERE database_id = db_id()

GROUP BY obj.name, obj.index_id ,b.name,b.type_desc

ORDER BY cached_pages_kb DESC;

 

输出结果如下 (部分): 从上面的结果可以看到表Individual 在Pool内存里面缓冲最多,可能这个就是经常访问的热表,或者是比较大的表。注意Pool里面的缓冲页是经常变化的。 你如果再跑一次语句,出现在头条的可能是另外一个表了。

 

    3. Buffer Pool缓冲池里面修改过的页总数大小。这个比较容易:

 

SELECT count(*)*8  as cached_pages_kb,

       convert(varchar(5),convert(decimal(5,2),(100-1.0*(select count(*) from sys.dm_os_buffer_descriptors b where b.database_id=a.database_id and is_modified=0)/count(*)*100.0)))+'%' modified_percentage

        ,CASE database_id span>

        WHEN 32767 THEN 'ResourceDb'

        ELSE db_name(database_id)

        END AS Database_name

FROM sys.dm_os_buffer_descriptors a

GROUP BY db_name(database_id) ,database_id

ORDER BY cached_pages_kb DESC;

结果: 从上面的结果可以看到,AdventureWorks数据库大概有13.84%的数据是修改过的。如果一个数据库的大部分(超过80%) 是修改过的,那么这个数据库写操作非常多。反之如果这个比例接近0,那么该数据库的活动几乎是只读的。读写的比例对磁盘的安排是很重要的。当然还有其他性能数据来获得数据库读写的大概比例,这里限于篇幅就不多谈了。

转载地址:http://tdjax.baihongyu.com/

你可能感兴趣的文章
关于在VS2005中编写DLL遇到 C4251 警告的解决办法
查看>>
Go语言大神亲述:历七劫方可成为程序员!
查看>>
CYQ.Data 轻量数据层之路 V4.5 版本发布[更好的使用体验,更优的缓存机制]
查看>>
NetApp针对其集群化方案“不值得升级”言论回击Wikibon
查看>>
QQ把游戏放进聊天框,这一点Facebook和微信都没做到
查看>>
在线匿名之父意欲终结“加密战争”
查看>>
WLAN市场销量逐步逼近有线网络
查看>>
力龙信息布局大数据领域
查看>>
大数据巧治职业差评师 生存空间锐减九成
查看>>
天津开展免费无线局域网建设
查看>>
提高信息安全意识对网络勒索病毒说不
查看>>
英国政府可能利用曼彻斯特自杀袭击要求互联网公司破解加密
查看>>
Mozilla 将大幅简化火狐浏览器的同步操作
查看>>
Convert Url to InetAddress
查看>>
oracle 限制特定ip登录
查看>>
解酒方法
查看>>
vi 命令
查看>>
1.1
查看>>
[logstash-input-redis]插件使用详解
查看>>
优化应用的电池寿命(笔记)-1
查看>>