譯碼阻塞和死鎖的等待資源

譯碼阻塞和死鎖的等待資源

經常使用等待資源介紹

如下表格列出了經常使用等待資源的格式和意義。

Resource	Format	Example
Table	DatabaseID:ObjectID:IndexID	TAB: 5:261575970:1           In this case, database ID 5 is the pubs sample database and object ID 261575970 is the titles table and 1 is the clustered index.
Page	DatabaseID:FileID:PageID	PAGE: 5:1:104           In this case, database ID 5 is pubs, file ID 1 is the primary data file, and page 104 is a page belonging to the titles table.             To identify the object id that the page belongs to, use the DBCC PAGE (dbid, fileid, pageid, output_option) command, and look at the m_objId. For example: DBCC TRACEON ( 3604 )           DBCC PAGE ( 5 , 1 , 104 , 3 )
Key	DatabaseID:Hobt_id (Hash value for index key)	KEY: 5:72057594044284928 (3300a4f361aa)           In this case, database ID 5 is Pubs, Hobt_ID 72057594044284928 corresponds to non clustered index_id 2 for object id 261575970 (titles table). Use the sys.partitions catalog view to associate the hobt_id to a particular index id and object id. There is no way to unhash the index key hash to a specific index key value.
Row	DatabaseID:FileID:PageID:Slot(row)	RID: 5:1:104:3           In this case, database ID 5 is pubs , file ID 1 is the primary data file, page 104 is a page belonging to the titles table, and slot 3 indicates the row's position on the page.
Compile	DatabaseID:ObjectID `COMPILE`	TAB: 5:834102012 `COMPILE` This is not a table lock, but rather a compile lock on a stored procedure. Database ID 5 is pubs, object ID 834102012 is stored procedure usp_myprocedure. See Knowledge Base Article 263889 for more information on blocking caused by compile locks.

等待資源示例分析

咱們開啓blocked process report捕獲阻塞信息，經過system_health捕獲死鎖信息。在分析捕獲的XML結果時發現，除非將不一樣類型的等待資源匹配到一個表或索引，不然沒有意義。這裏，我來完整的分析一個死鎖XML文件(見附件)，解釋下如何將等待資源匹配到一個表或索引。

鍵等待資源

如下是第一個進程的信息：

鍵等待資源KEY: 10:72057594048217088的第一部分是數據庫id，第二部分是Hobt_Id。根據數據庫id經過DB_NAME()函數獲得數據庫名爲CSTS。Hobt是Heap Or B Tree的首字母縮寫詞。Hobt_id能夠經過sys.partitions匹配到sys.indexes和sys.objcets。如下腳本能夠匹配鍵等待資源到相應的索引和表。

USE CSTS
GO
SELECT
o.name AS TableName,
i.name AS IndexName,
SCHEMA_NAME(o.schema_id) AS SchemaName
FROM sys.partitions p JOIN sys.objects o ON p.OBJECT_ID = o.OBJECT_ID
JOIN sys.indexes i ON p.OBJECT_ID = i.OBJECT_ID AND p.index_id = i.index_id
WHERE p.hobt_id = 72057594048217088

結果以下：

查詢原表結構以下：

頁等待資源

如下是第二個進程的信息：

頁等待資源PAGE: 10:1:5533603的第一部分是數據庫id，第二部分是文件id，第三部分是頁號。經過如下步驟與這個頁相關的對象id。

DBCC traceon (3604)
GO
DBCC page (10, 1, 5533603) --Database_id,file_id,page_id

輸出結果的部分截圖以下：

根據ObjectId能夠經過系統函數object_name()系統函數匹配到一個表。

SELECT object_name(1573580644)

以上是這個死鎖XML的兩個進程等待資源。固然，還有其餘一些等待資源。

對象等待資源

對象等待資源相似waitresource=」OBJECT: 10:1365579903:22」，第一部分爲數據庫id，第二部分爲對象id，第三部分爲鎖分區id。對象id能夠經過系統函數object_name()匹配到一個對象。鎖分區id在阻塞和死鎖問題排查中不是頗有用。只有當服務器有多於16個CPU時該值纔有價值。

行等待資源

行等待資源相似waitresource=」RID: 5:1:166:0」多爲堆錶行資源，共有4個值，第一部分爲數據庫id，第二部分爲文件id，第三部分爲頁id，第四部分爲槽位號。

表等待資源

表等待資源相似waitresource=」TAB: 5:261575970:1」，第一部分爲數據庫id，第二部分爲對象id，第三部分爲索引id。

編譯等待資源

編譯等待資源相似waitresource=」TAB: 5:834102012 `COMPILE`」，這不是一個表鎖，而是一個存儲過程上的編譯鎖。第一部分爲數據庫id，第二部分爲對象id。

參考：

https://support.microsoft.com/en-us/help/224453/inf-understanding-and-resolving-sql-server-blocking-problems