译码阻塞和死锁的等待资源

译码阻塞和死锁的等待资源

经常使用等待资源介绍

如下表格列出了经常使用等待资源的格式和意义。

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