Đang chuẩn bị nút TẢI XUỐNG, xin hãy chờ
Tải xuống
SQL Server MVP Deep Dives- P16: Each year Microsoft invites all the MVPs from every technology and country to Redmond for an MVP Summit—all top secret—“don’t tweet what you see!” During the MVP Summit, each product team holds a series of presentations where they explain their technologies, share their vision, and listen to some honest feedback. | 554 Chapter 42 Tracing the deadlock frame procname WF.dbo.ViewThread line 20 stmtstart 1090 stmtend 1362 sqlhandle 0x03000600b15244168cf9db002b9b00000100000000000000 This section lists the full three-part name of the procedure that the process was running. If the call was ad hoc SQL rather than a stored procedure then the procname will read adhoc. The line number indicates on which line of the procedure the specific SQL statement starts. If the line number is 1 it s a strong indication that the specific SQL statement is a piece of dynamic SQL. The statement start and statement end values specify the offsets within the procedure where the query starts and ends. The sql_handle can be used with the sys .dm_exec_sql_text DMF to get the SQL statement from the server s procedure cache. This usually isn t necessary as most of the time the statement is reproduced in full in the deadlock graph right below this line. The input buffer lists either the entire query for ad hoc SQL or the database ID and object ID for a stored procedure inputbuf Proc Database Id 6 Object Id 373576369 The object ID can be translated back to an object name using the object name function SELECT OBJECT_NAME 373576369 6 In this case it returns ViewThread matching what was shown for the process name earlier in the deadlock graph. NOTE The Object_Name function took only one parameter the object ID prior to SQL Server 2005 SP2. From SP2 onward it accepts an optional second parameter the database ID. The second process listed in the deadlock graph contains the same information and can be read in much the same way. I won t go through it all in detail as many of the explanations given for the first process apply to the second as well. The second process has a different waitresource than the first one did. In the case of the key lock it was trivial to identify the table involved. The second process was waiting on a page lock. process id process809f8748 waitresource PAGE 6 1 351 spid 55 The numbers listed .