我在做SQL Server 7.0技術(shù)支持的時(shí)候有客戶(hù)問(wèn)我,“我的SQL Server buffer pool很大,有辦法知道是哪些對(duì)象吃掉我的buffer Pool內(nèi)存么？比方說(shuō)，能否知道是哪個(gè)數(shù)據(jù)庫(kù)，哪個(gè)表，哪個(gè)index占用了buffer Pool么？”當(dāng)時(shí)我沒(méi)有找到這個(gè)問(wèn)題的答案，但是我一直記著這個(gè)問(wèn)題。直到SQL server 2005 版本出現(xiàn)，這個(gè)問(wèn)題迎刃而解。答案就是使用動(dòng)態(tài)視圖（DMV） sys.dm_os_buffer_descriptors。

這個(gè)DMV非常強(qiáng)大。根據(jù)SQL Server 聯(lián)機(jī)叢書(shū)，這個(gè)視圖的作用是　“返回有關(guān) SQL Server 緩沖池中當(dāng)前所有數(shù)據(jù)頁(yè)的信息。可以使用該視圖的輸出，根據(jù)數(shù)據(jù)庫(kù)、對(duì)象或類(lèi)型來(lái)確定緩沖池內(nèi)數(shù)據(jù)庫(kù)頁(yè)的分布”。具體點(diǎn)說(shuō)，這個(gè)視圖能夠返回buffer pool里面一個(gè)8K 的data page的下列屬性：

(1)該頁(yè)屬于哪個(gè)數(shù)據(jù)庫(kù)

(2)該頁(yè)屬于數(shù)據(jù)庫(kù)哪個(gè)文件

(3)該頁(yè)的Page_ID

(4)該頁(yè)的類(lèi)型?？梢愿鶕?jù)這個(gè)來(lái)判斷此頁(yè)時(shí)索引頁(yè)還是數(shù)據(jù)頁(yè)

(5)該頁(yè)內(nèi)有多少行數(shù)據(jù)

(6)該頁(yè)有多少可用空間。

(7)該頁(yè)從磁盤(pán)讀取以來(lái)是否修改過(guò)。

有了上面的信息，我們就可以很方便的統(tǒng)計(jì)出幾種很有用的數(shù)據(jù)，如下。

1.?????? Buffer Pool的內(nèi)存主要是由那個(gè)數(shù)據(jù)庫(kù)占了？

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;

結(jié)果如下：

從上面的結(jié)果可以看到數(shù)據(jù)庫(kù)AdventureWorks占用了大概30MB左右的緩沖池空間。

注意該DMV 并不返回Buffer Pool里面有關(guān)非數(shù)據(jù)頁(yè)(如執(zhí)行計(jì)劃的緩存等)的信息。也就是說(shuō)這個(gè)DMV并沒(méi)有返回Buffer Pool里面所有頁(yè)面的信息。

2.?????? 再具體一點(diǎn)，當(dāng)前數(shù)據(jù)庫(kù)的哪個(gè)表或者索引占用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;

輸出結(jié)果如下 （部分）:

??

從上面的結(jié)果可以看到表Individual 在Pool內(nèi)存里面緩沖最多，可能這個(gè)就是經(jīng)常訪問(wèn)的熱表，或者是比較大的表。注意Pool里面的緩沖頁(yè)是經(jīng)常變化的。 你如果再跑一次語(yǔ)句，出現(xiàn)在頭條的可能是另外一個(gè)表了。

3.?????? Buffer Pool緩沖池里面修改過(guò)的頁(yè)總數(shù)大小。這個(gè)比較容易：

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

??????? 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;

結(jié)果：

?

從上面的結(jié)果可以看到，AdventureWorks數(shù)據(jù)庫(kù)大概有13.84%的數(shù)據(jù)是修改過(guò)的。如果一個(gè)數(shù)據(jù)庫(kù)的大部分（超過(guò)80%） 是修改過(guò)的，那么這個(gè)數(shù)據(jù)庫(kù)寫(xiě)操作非常多。反之如果這個(gè)比例接近0，那么該數(shù)據(jù)庫(kù)的活動(dòng)幾乎是只讀的。讀寫(xiě)的比例對(duì)磁盤(pán)的安排是很重要的。當(dāng)然還有其他性能數(shù)據(jù)來(lái)獲得數(shù)據(jù)庫(kù)讀寫(xiě)的大概比例，這里限于篇幅就不多談了。

總結(jié)

以上是生活随笔為你收集整理的谁占用了我的Buffer Pool?的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。