2. 程式人生 > >SQL Server檢測和結束死鎖

SQL Server檢測和結束死鎖

阿新 • • 發佈：2019-01-20

上面列出的所有資源均參與資料庫引擎死鎖檢測方案。死鎖檢測是由鎖監視器執行緒執行的，該執行緒定期搜尋資料庫引擎例項的所有任務。以下幾點說明了搜尋程序：

  • 預設時間間隔為 5 秒。

  • 如果鎖監視器執行緒查詢死鎖，根據死鎖的頻率，死鎖檢測時間間隔將從 5 秒開始減小，最小為 100 毫秒。

  • 如果鎖監視器執行緒停止查詢死鎖，資料庫引擎將兩個搜尋間的時間間隔增加到 5 秒。

  • 如果剛剛檢測到死鎖，則假定必須等待鎖的下一個執行緒正進入死鎖迴圈。檢測到死鎖後，第一對鎖等待將立即觸發死鎖搜尋，而不是等待下一個死鎖檢測時間間隔。例如，如果當前時間間隔為 5 秒且剛剛檢測到死鎖，則下一個鎖等待將立即觸發死鎖檢測器。如果鎖等待是死鎖的一部分，則將會立即檢測它，而不是在下一個搜尋期間才檢測。

通常，資料庫引擎僅定期執行死鎖檢測。因為系統中遇到的死鎖數通常很少，定期死鎖檢測有助於減少系統中死鎖檢測的開銷。

鎖監視器對特定執行緒啟動死鎖搜尋時，會標識執行緒正在等待的資源。然後，鎖監視器查詢特定資源的所有者，並遞迴地繼續執行對那些執行緒的死鎖搜尋，直到找到一個迴圈。用這種方式標識的迴圈形成一個死鎖。

檢測到死鎖後，資料庫引擎通過選擇其中一個執行緒作為死鎖犧牲品來結束死鎖。資料庫引擎終止正為執行緒執行的當前批處理，回滾死鎖犧牲品的事務並將 1205 錯誤返回到應用程式。回滾死鎖犧牲品的事務會釋放事務持有的所有鎖。這將使其他執行緒的事務解鎖，並繼續執行。1205 死鎖犧牲品錯誤將有關死鎖涉及的執行緒和資源的資訊記錄在錯誤日誌中。

預設情況下，資料庫引擎選擇執行回滾開銷最小的事務的會話作為死鎖犧牲品。此外，使用者也可以使用 SET DEADLOCK_PRIORITY 語句指定死鎖情況下會話的優先順序。可以將 DEADLOCK_PRIORITY 設定為 LOW、NORMAL 或 HIGH，也可以將其設定為範圍（-10 到 10）間的任一整數值。死鎖優先順序的預設設定為 NORMAL。如果兩個會話的死鎖優先順序不同，則會選擇優先順序較低的會話作為死鎖犧牲品。如果兩個會話的死鎖優先順序相同，則會選擇回滾開銷最低的事務的會話作為死鎖犧牲品。如果死鎖迴圈中會話的死鎖優先順序和開銷都相同，則會隨機選擇死鎖犧牲品。

使用 CLR 時，死鎖監視器將自動檢測託管過程中訪問的同步資源（監視器、讀取器/編寫器鎖和執行緒聯接）的死鎖。但是，死鎖是通過在已選為死鎖犧牲品的過

死鎖資訊工具

為了檢視死鎖資訊，資料庫引擎提供了監視工具，分別為兩個跟蹤標誌以及 SQL Server Profiler 中的死鎖圖形事件。

跟蹤標誌 1204 和跟蹤標誌 1222

發生死鎖時，跟蹤標誌 1204 和跟蹤標誌 1222 會返回在 SQL Server 2005 錯誤日誌中捕獲的資訊。跟蹤標誌 1204 會報告由死鎖所涉及的每個節點設定格式的死鎖資訊。跟蹤標誌 1222 會設定死鎖資訊的格式，順序為先按程序，然後按資源。可以同時啟用這兩個跟蹤標誌，以獲取同一個死鎖事件的兩種表示形式。

除了定義跟蹤標誌 1204 和 1222 的屬性之外，下表還顯示了它們之間的相似之處和不同之處。

屬性 跟蹤標誌 1204 和跟蹤標誌 1222 僅跟蹤標誌 1204 僅跟蹤標誌 1222

輸出格式

在 SQL Server 2005 錯誤日誌中捕獲輸出。

主要針對死鎖所涉及的節點。每個節點都有一個專用部分，並且最後一部分說明死鎖犧牲品。

返回採用不符合 XML 架構定義 (XSD) 架構的類 XML 格式的資訊。該格式有三個主要部分。第一部分宣告死鎖犧牲品；第二部分說明死鎖所涉及的每個程序；第三部分說明與跟蹤標誌 1204 中的節點同義的資源。

標識屬性

SPID:<x> ECID:<x>。標識並行程序中的系統程序 ID 執行緒。項 SPID:<x> ECID:0（其中，<x> 將替換為 SPID 值）表示主執行緒。項SPID:<x> ECID:<y>（其中，<x> 將替換為 SPID 值，<y> 大於 0）表示具有相同 SPID 的子執行緒。

BatchID（對於跟蹤標誌 1222 為 sbid）。標識程式碼執行從中請求鎖或持有鎖的批處理。多個活動的結果集 (MARS) 禁用後，BatchID 值為 0。MARS 啟用後，活動批處理的值為 1 到n。如果會話中沒有活動的批處理，則 BatchID 為 0。

Mode。指定執行緒所請求的、獲得的或等待的特定資源的鎖的型別。模式可以為 IS（意向共享）、S（共享）、U（更新）、IX（意向排他）、SIX（意向排他共享）和 X（排他）。有關詳細資訊，請參閱鎖模式。

Line #（對於跟蹤標誌 1222 為 line）。列出發生死鎖時當前批處理中正在執行的語句的行數。

Input Buf（對於跟蹤標誌 1222 為 inputbuf）。列出當前批處理中的所有語句。

Node。表示死鎖鏈中的項數。

Lists。鎖所有者可能屬於以下列表：

  • Grant List。列舉資源的當前所有者。

  • Convert List。列舉嘗試將其鎖轉換為較高級別的當前所有者。

  • Wait List。列舉對資源的當前新鎖請求。

Statement Type。說明執行緒對其具有許可權的 DML 語句的型別（SELECT、INSERT、UPDATE 或 DELETE）。

Victim Resource Owner。指定 SQL Server 選擇作為犧牲品來中斷死鎖迴圈的參與執行緒。選定的執行緒和所有的現有子執行緒都將終止。

Next Branch。表示死鎖迴圈中涉及的兩個或多個具有相同 SPID 的子執行緒。

deadlock victim。表示選為死鎖犧牲品的任務的實體記憶體地址（請參閱 sys.dm_os_tasks）。如果任務為無法解析的死鎖，則它可能為 0（零）。不能選擇正在回滾的任務作為死鎖犧牲品。

executionstack。表示發生死鎖時正在執行的 Transact-SQL 程式碼。

priority。表示死鎖優先順序。在某些情況下，資料庫引擎可能在短時間內改變死鎖優先順序以更好地實現併發。

logused。任務使用的日誌空間。

owner id。可控制請求的事務的 ID。

status。任務的狀態。為下列值之一：

  • pending。正在等待工作執行緒。

  • runnable。可以執行，但正在等待量程。

  • running。當前正在計劃程式上執行。

  • suspended。執行已掛起。

  • done。任務已完成。

  • spinloop。正在等待自旋鎖釋放。

waitresource。任務需要的資源。

waittime。等待資源的時間（毫秒）。

schedulerid。與此任務關聯的計劃程式。請參閱 sys.dm_os_schedulers (Transact-SQL)。

hostname。工作站的名稱。

isolationlevel。當前事務隔離級別。

Xactid。可控制請求的事務的 ID。

currentdb。資料庫的 ID。

lastbatchstarted。客戶端程序上次啟動批處理執行的時間。

lastbatchcompleted。客戶端程序上次完成批處理執行的時間。

clientoption1 和 clientoption2。此客戶端連線上的 Set 選項。這是一個位掩碼，包含有關 SET 語句（如 SET NOCOUNT 和 SET XACTABORT）通常控制的選項的資訊。

associatedObjectId。表示 HoBT（堆或 b 樹）ID。

資源屬性

RID：標識持有鎖或請求鎖的表中的單行。RID 表示為 RID: db_id:file_id:page_no:row_no。例如，RID: 6:1:20789:0。

OBJECT：標識持有鎖或請求鎖的表。OBJECT 表示為 OBJECT: db_id:object_id。例如，TAB: 6:2009058193。

KEY：標識持有鎖或請求鎖的索引中的鍵範圍。KEY 表示為 KEY: db_id:hobt_id (index key hash value)。例如，KEY: 6:72057594057457664 (350007a4d329)。

PAG：標識持有鎖或請求鎖的頁資源。PAG 表示為 PAG: db_id:file_id:page_no。例如，PAG: 6:1:20789。

EXT：標識區結構。EXT 表示為 EXT: db_id:file_id:extent_no。例如，EXT: 6:1:9。

DB：標識資料庫鎖。DB 以下列方式之一表示：

  • DB: db_id

  • DB: db_id[BULK-OP-DB]，這標識備份資料庫持有的資料庫鎖。

  • DB: db_id[BULK-OP-LOG]，這標識此特定資料庫的備份日誌持有的鎖。

APP：標識應用程式資源持有的鎖。APP 表示為 APP: lock_resource。例如，APP: Formf370f478。

METADATA：表示死鎖所涉及的元資料資源。由於 METADATA 具有許多子資源，因此，返回的值取決於已發生死鎖的子資源。例如，METADATA.USER_TYPE 將返回user_type_id = <integer_value>。有關 METADATA 資源和子資源的詳細資訊，請參閱 sys.dm_tran_locks (Transact-SQL)。

HOBT：表示死鎖所涉及的堆或 b 樹。

此跟蹤標誌沒有任何排他。

此跟蹤標誌沒有任何排他。

跟蹤標誌 1204 示例

下面的示例顯示啟用跟蹤標誌 1204 時的輸出。在此示例中，節點 1 中的表為沒有索引的堆，節點 2 中的表為具有非聚集索引的堆。節點 2 中索引鍵在發生死鎖時正在進行更新。

複製程式碼 
Deadlock encountered .... Printing deadlock information
Wait-for graph

Node:1

RID: 6:1:20789:0               CleanCnt:3 Mode:X Flags: 0x2
 Grant List 0:
   Owner:0x0315D6A0 Mode: X        
     Flg:0x0 Ref:0 Life:02000000 SPID:55 ECID:0 XactLockInfo: 0x04D9E27C
   SPID: 55 ECID: 0 Statement Type: UPDATE Line #: 6
   Input Buf: Language Event: 
BEGIN TRANSACTION
   EXEC usp_p2
 Requested By: 
   ResType:LockOwner Stype:'OR'Xdes:0x03A3DAD0 
     Mode: U SPID:54 BatchID:0 ECID:0 TaskProxy:(0x04976374) Value:0x315d200 Cost:(0/868)

Node:2

KEY: 6:72057594057457664 (350007a4d329) CleanCnt:2 Mode:X Flags: 0x0
 Grant List 0:
   Owner:0x0315D140 Mode: X        
     Flg:0x0 Ref:0 Life:02000000 SPID:54 ECID:0 XactLockInfo: 0x03A3DAF4
   SPID: 54 ECID: 0 Statement Type: UPDATE Line #: 6
   Input Buf: Language Event: 
     BEGIN TRANSACTION
       EXEC usp_p1
 Requested By: 
   ResType:LockOwner Stype:'OR'Xdes:0x04D9E258 
     Mode: U SPID:55 BatchID:0 ECID:0 TaskProxy:(0x0475E374) Value:0x315d4a0 Cost:(0/380)

Victim Resource Owner:
 ResType:LockOwner Stype:'OR'Xdes:0x04D9E258 
     Mode: U SPID:55 BatchID:0 ECID:0 TaskProxy:(0x0475E374) Value:0x315d4a0 Cost:(0/380)

跟蹤標誌 1222 示例

下面的示例顯示啟用跟蹤標誌 1222 時的輸出。在此示例中，一個表為沒有索引的堆，另一個表為具有非聚集索引的堆。在第二個表中，索引鍵在發生死鎖時正在進行更新。

複製程式碼 
deadlock-list
 deadlock victim=process689978
  process-list
   process id=process6891f8 taskpriority=0 logused=868 
   waitresource=RID: 6:1:20789:0 waittime=1359 ownerId=310444 
   transactionname=user_transaction 
   lasttranstarted=2005-09-05T11:22:42.733 XDES=0x3a3dad0 
   lockMode=U schedulerid=1 kpid=1952 status=suspended spid=54 
   sbid=0 ecid=0 priority=0 transcount=2 
   lastbatchstarted=2005-09-05T11:22:42.733 
   lastbatchcompleted=2005-09-05T11:22:42.733 
   clientapp=Microsoft SQL Server Management Studio - Query 
   hostname=TEST_SERVER hostpid=2216 loginname=DOMAIN\user 
   isolationlevel=read committed (2) xactid=310444 currentdb=6 
   lockTimeout=4294967295 clientoption1=671090784 clientoption2=390200
    executionStack
     frame procname=AdventureWorks2008R2.dbo.usp_p1 line=6 stmtstart=202 
     sqlhandle=0x0300060013e6446b027cbb00c69600000100000000000000
     UPDATE T2 SET COL1 = 3 WHERE COL1 = 1;     
     frame procname=adhoc line=3 stmtstart=44 
     sqlhandle=0x01000600856aa70f503b8104000000000000000000000000
     EXEC usp_p1     
    inputbuf
      BEGIN TRANSACTION
       EXEC usp_p1
   process id=process689978 taskpriority=0 logused=380 
   waitresource=KEY: 6:72057594057457664 (350007a4d329)   
   waittime=5015 ownerId=310462 transactionname=user_transaction 
   lasttranstarted=2005-09-05T11:22:44.077 XDES=0x4d9e258 lockMode=U 
   schedulerid=1 kpid=3024 status=suspended spid=55 sbid=0 ecid=0 
   priority=0 transcount=2 lastbatchstarted=2005-09-05T11:22:44.077 
   lastbatchcompleted=2005-09-05T11:22:44.077 
   clientapp=Microsoft SQL Server Management Studio - Query 
   hostname=TEST_SERVER hostpid=2216 loginname=DOMAIN\user 
   isolationlevel=read committed (2) xactid=310462 currentdb=6 
   lockTimeout=4294967295 clientoption1=671090784 clientoption2=390200
    executionStack
     frame procname=AdventureWorks2008R2.dbo.usp_p2 line=6 stmtstart=200 
     sqlhandle=0x030006004c0a396c027cbb00c69600000100000000000000
     UPDATE T1 SET COL1 = 4 WHERE COL1 = 1;     
     frame procname=adhoc line=3 stmtstart=44 
     sqlhandle=0x01000600d688e709b85f8904000000000000000000000000
     EXEC usp_p2     
    inputbuf
      BEGIN TRANSACTION
        EXEC usp_p2    
  resource-list
   ridlock fileid=1 pageid=20789 dbid=6 objectname=AdventureWorks2008R2.dbo.T2 
   id=lock3136940 mode=X associatedObjectId=72057594057392128
    owner-list
     owner id=process689978 mode=X
    waiter-list
     waiter id=process6891f8 mode=U requestType=wait
   keylock hobtid=72057594057457664 dbid=6 objectname=AdventureWorks2008R2.dbo.T1 
   indexname=nci_T1_COL1 id=lock3136fc0 mode=X 
   associatedObjectId=72057594057457664
    owner-list
     owner id=process6891f8 mode=X
    waiter-list
     waiter id=process689978 mode=U requestType=wait

事件探查器死鎖圖形事件

這是 SQL Server Profiler中表示死鎖所涉及的任務和資源的圖形描述的事件。下面的示例顯示啟用死鎖圖形事件時 SQL Server Profiler 的輸出。

相關推薦

SQL Server檢測和結束死鎖

上面列出的所有資源均參與資料庫引擎死鎖檢測方案。死鎖檢測是由鎖監視器執行緒執行的，該執行緒定期搜尋資料庫引擎例項的所有任務。以下幾點說明了搜尋程序： 預設時間間隔為 5 秒。如果鎖監視器執行緒查詢死鎖，根據死鎖的頻率，死鎖檢測時間間隔將從 5 秒開始減小，最小為 100 毫秒。如果鎖監視器執行緒停止查詢死鎖

SQL SERVER 查看近期死鎖

擴展 ted 查詢 -- 分配 sys ons next char 在項目運行的過程中，死鎖不可能完全避免，但要盡可能減少死鎖的出現， 產生死鎖的原因主要是： 1，系統資源不足。 2，進程運行推進的順序不合適。 3，資源分配不當等。 產生死鎖的四個必要條件：- 互斥條件

SQL Server 檢測到基於一致性的邏輯 I/O 錯誤 校驗和不正確 解決方案

之前在做sql server資料統計儲存過程，統計方式大致是先根據時間範圍查詢資料，將查詢結果儲存到臨時表中，再對臨時表中的資料進行統計，最後刪除臨時表。由於這個儲存過程相對比較複雜，中間做了很多調整，今天終於把儲存過程改的差不多了，執行的時候卻出現“SQL Server

SQL Server中的事務與鎖

ani 否則 編譯 什麽 高並發 設置時間 檢測 isolation 管理 了解事務和鎖 事務：保持邏輯數據一致性與可恢復性，必不可少的利器。 鎖：多用戶訪問同一數據庫資源時，對訪問的先後次序權限管理的一種機制，沒有他事務或許將會一塌糊塗，不能保證數據的安全正確讀寫。 死鎖

SQL Server 檢測到基於一致性的邏輯 I/O 錯誤 pageid不正確、數據庫日誌文 件丟失

日誌文件 科技 文件丟失 i/o 處理 企業管理 eid dbcc 無法連接 客戶名稱：深圳某科技信息有限公司 數據庫類型：sql2000 數據庫大小：20g 故障經過 電腦突然斷電，軟件就顯示某數據庫錯誤，無法連接，打開企業管理器，顯示數 據庫質疑，DBCC查詢顯示“ S

SQL Server 索引和視圖

student 索引 1、 什麽是索引 索引就是數據表中數據和相應的存儲位置的列表，利用索引可以提高在表或視圖中的查找數據的速度。 2、 索引分類 數據庫中索引主要分為兩類：聚集索引和非聚集索引。SQL Server 2005還提供了唯一索引、索引視圖、全文索引、xml

SQL Server 檢測到基於一致性的邏輯 I/O 錯誤 pageid 不正確(應為 1:1772，但實際為 0:0)。在文件 'D:Program FilesMicrosoft SQL Ser

red 完成 sdn blank net tools ocl views 偏移 SQL Server 檢測到基於一致性的邏輯 I/O 錯誤 pageid 不正確(應為 1:1772，但實際為 0:0)。在文件 ‘D:\Program Files\Microsoft S

【轉】查看oracle死鎖進程並結束死鎖

alter pro 一定的 查看 pid time table over 機器名 --查看鎖表進程SQL語句1： select sess.sid, sess.serial#, lo.oracle_username, lo.os_user_name, ao.object_n

SQL Server備份和還原

sql 數據庫 備份 還原 楊書凡 對於生產數據來講，數據的安全性是至關重要的，任何數據的丟失都可能產生嚴重的的後果。而備份作為數據的副本，可以有效的保護和恢復數據數據丟失的原因 數據丟失的原因主要包括以下幾類：（1）程序錯誤。例如，程序異常終止或邏輯錯誤等（2）人為錯誤。例

SQL SERVER 數據庫的鎖

ali style student fff 概念 create one 分享 shadow 1SQL SERVER 鎖的概念

linux連sql server 2012 和開啟PHP sqlserver擴展

linux sqlserver php連接sql server 2012數據庫http://www.freetds.org/userguide/choosingtdsprotocol.htm下載安裝 ftp://ftp.freetds.org/pub/freetds/stable/freetds-1.00.2

SQL Server PageIOLatch和PageLatch

nis 自動 called 應該 sbo 可能 ora 裏的 service Latch是輕量級的鎖，它是SQL Server內部用來同步資源訪問的一個數據結構，使數據的訪問同步有序，這意味著，當一個線程獲得資源R的Latch的獨占使用權時，如果其他的線程也想訪問這個La

T-SQL查詢進階--SQL Server中的事務與鎖

錯誤 span 設備 限制 數據復制 默認 base 數據 insert 為什麽需要鎖在任何多用戶的數據庫中，必須有一套用於數據修改的一致的規則，當兩個不同的進程試圖同時修改同一份數據時，數據庫管理系統（DBMS）負責解決它們之間潛在的沖突。任何關系數據庫必須支持事務的AC

Sql Server併發和事務

鎖的作用範圍通常在事務中，事務是建立在併發模式下。 從SQL Server 2005開始，加入了一種新的併發模式-----樂觀併發。不管使用哪種併發模式，如果多個會話同時修改相同的資料，都會產生資源爭用，然後引發一系列的問題。 1.存在的讀現象:包括髒讀、不可重複讀和幻讀。 2.丟失更新：一個會話的修改

SQL Server 索引和表體系結構（非聚集索引）

非聚集索引 概述      對於非聚集索引，涉及的資訊要比聚集索引更多一些，由於整個篇幅比較大涉及接下來的要寫的“包含列的索引”，“索引碎片”等一些知識點，可能要結合起來閱讀理解起來要更容易一些。非聚集索引和聚集索引一樣都是B-樹結構，但是非聚集索引不改變資料的儲存方式，所以一個表允許建多個非聚集索引；非

SQL Server 索引和表體系結構（聚集索引）

聚集索引 概述       關於索引和表體系結構的概念一直都是討論比較多的話題，其中表的各種儲存形式是討論的重點，在各個網站上面也有很多關於這方面寫的不錯的文章，我寫這篇文章的目的也是為了將所有的知識點儘可能的組織起來結合自己對這方面的瞭解些一篇關於的詳細文章出來，同時也會列出一些我自己有疑惑的地方拿出來

SQL Server 建立和使用索引 （轉載）

使用CREATE INDEX語句建立索引： CREATE[ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX索引名 ON {表名|檢視名} (列名[ ASC | DESC ] [ ,...n ] ) 例： 在資料庫HrSystem中為表Employees建立基於IDC

oracle資料庫檢視和解除死鎖

檢視死鎖： select sess.sid, sess.serial#, lo.oracle_username, lo.os_user_name, ao.object_name, lo.locked_mode, SESS.machine from v$locked_object lo, dba_o

死鎖的定義 產生原因 必要條件 避免死鎖和解除死鎖的方法

                1.死鎖：如果一組程序中的每一個程序都在等待僅由該組程序中的其它程序才能引發的事件，那麼該組程序是

C#連線sql server windows 和 sqlserver 身份驗證的兩種連線字串

//sql server 身份驗證 連線字串 private string ConnstrSqlServer = "server=伺服器名稱;uid=登入名稱;pwd=登入密碼;database=資料庫名稱"; //windows 身份驗證連線字串 private str