1. 程式人生 > >譯碼阻塞和死鎖的等待資源

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

block waitresource 等待資源

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


常用等待資源介紹


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

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


本文出自 “SQL Server Deep Dive” 博客,請務必保留此出處http://ultrasql.blog.51cto.com/9591438/1967759

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