數據庫死鎖及解決死鎖問題

 

所謂死鎖<DeadLock>: 是指兩個或兩個以上的進程在執行過程當中,因爭奪資源而形成的一種互相等待的現象,若無外力做用,它們都將沒法推動下去.此時稱系統處於死鎖狀態或系統產生了死鎖,這些永遠在互相等待的進程稱爲死鎖進程.因爲資源佔用是互斥的，當某個進程提出申請資源後，使得有關進程在無外力協助下，永遠分配不到必需的資源而沒法繼續運行，這就產生了一種特殊現象死鎖。 一種情形，此時執行程序中兩個或多個線程發生永久堵塞（等待），每一個線程都在等待被其餘線程佔用並堵塞了的資源。例如，若是線程A鎖住了記錄1並等待記錄2，而線程B鎖住了記錄2並等待記錄1，這樣兩個線程就發生了死鎖現象。計算機系統中,若是系統的資源分配策略不當，更常見的多是程序員寫的程序有錯誤等，則會致使進程因競爭資源不當而產生死鎖的現象。鎖有多種實現方式，好比意向鎖，共享－排他鎖，鎖表，樹形協議，時間戳協議等等。鎖還有多種粒度，好比能夠在表上加鎖，也能夠在記錄上加鎖。 
產生死鎖的緣由主要是：（1） 由於系統資源不足。（2） 進程運行推動的順序不合適。（3） 資源分配不當等。
若是系統資源充足，進程的資源請求都可以獲得知足，死鎖出現的可能性就很低，不然就會因爭奪有限的資源而陷入死鎖。其次，進程運行推動順序與速度不一樣，也可能產生死鎖。產生死鎖的四個必要條件：（1） 互斥條件：一個資源每次只能被一個進程使用。
（2） 請求與保持條件：一個進程因請求資源而阻塞時，對已得到的資源保持不放。
（3） 不剝奪條件:進程已得到的資源，在末使用完以前，不能強行剝奪。
（4） 循環等待條件:若干進程之間造成一種頭尾相接的循環等待資源關係。這四個條件是死鎖的必要條件，只要系統發生死鎖，這些條件必然成立，而只要上述條件之一不知足，就不會發生死鎖。死鎖的解除與預防： 
理解了死鎖的緣由，尤爲是產生死鎖的四個必要條件，就能夠最大可能地避免、預防和
解除死鎖。因此，在系統設計、進程調度等方面注意如何不讓這四個必要條件成立，如何肯定資源的合理分配算法，避免進程永久佔據系統資源。此外，也要防止進程在處於等待狀態的狀況下佔用資源,在系統運行過程當中，對進程發出的每個系統可以知足的資源申請進行動態檢查，並根據檢查結果決定是否分配資源，若分配後系統可能發生死鎖，則不予分配，不然予以分配 。所以，對資源的分配要給予合理的規劃。

如何將死鎖減至最少

 

 

雖然不能徹底避免死鎖，但可使死鎖的數量減至最少。將死鎖減至最少能夠增長事務的吞吐量並減小系統開銷，由於只有不多的事務：

◆回滾，而回滾會取消事務執行的全部工做。

◆因爲死鎖時回滾而由應用程序從新提交。

下列方法有助於最大限度地下降死鎖：

◆按同一順序訪問對象。

◆避免事務中的用戶交互。

◆保持事務簡短並在一個批處理中。

◆使用低隔離級別。

◆使用綁定鏈接。

按同一順序訪問對象

若是全部併發事務按同一順序訪問對象，則發生死鎖的可能性會下降。例如，若是兩個併發事務得到 Supplier 表上的鎖，而後得到 Part 表上的鎖，則在其中一個事務完成以前，另外一個事務被阻塞在 Supplier 表上。第一個事務提交或回滾後，第二個事務繼續進行。不發生死鎖。將存儲過程用於全部的數據修改能夠標準化訪問對象的順序。

 

避免事務中的用戶交互

避免編寫包含用戶交互的事務，由於運行沒有用戶交互的批處理的速度要遠遠快於用戶手動響應查詢的速度，例如答覆應用程序請求參數的提示。例如，若是事務正在等待用戶輸入，而用戶去吃午飯了或者甚至回家過週末了，則用戶將此事務掛起使之不能完成。這樣將下降系統的吞吐量，由於事務持有的任何鎖只有在事務提交或回滾時纔會釋放。即便不出現死鎖的狀況，訪問同一資源的其它事務也會被阻塞，等待該事務完成。

 

保持事務簡短並在一個批處理中

在同一數據庫中併發執行多個須要長時間運行的事務時一般發生死鎖。事務運行時間越長，其持有排它鎖或更新鎖的時間也就越長，從而堵塞了其它活動並可能致使死鎖。

 

保持事務在一個批處理中，能夠最小化事務的網絡通訊往返量，減小完成事務可能的延遲並釋放鎖。

 

使用低隔離級別

肯定事務是否能在更低的隔離級別上運行。執行提交讀容許事務讀取另外一個事務已讀取（未修改）的數據，而沒必要等待第一個事務完成。使用較低的隔離級別（例如提交讀）而不使用較高的隔離級別（例如可串行讀）能夠縮短持有共享鎖的時間，從而下降了鎖定爭奪。

 

使用綁定鏈接

使用綁定鏈接使同一應用程序所打開的兩個或多個鏈接能夠相互合做。次級鏈接所得到的任何鎖能夠象由主鏈接得到的鎖那樣持有，反之亦然，所以不會相互阻塞。

用存儲過程查出引發死鎖的進程和SQL語句

 

假如發生了死鎖，咱們怎麼去檢測具體發生死鎖的是哪條SQL語句或存儲過程？此時咱們可使用如下存儲過程來檢測，就能夠查出引發死鎖的進程和SQL語句。

 

use mastergocreate procedure sp_who_lockasbegindeclare @spid int,@bl int,@intTransactionCountOnEntry int,@intRowcount int,@intCountProperties int,@intCounter intcreate table #tmp_lock_who (id int identity(1,1),spid smallint,bl smallint)IF @@ERROR<>0 RETURN @@ERRORinsert into #tmp_lock_who(spid,bl) select. 0 ,blockedfrom (select. * from sysprocesses where blocked>0 ) a where not exists(select. * from (select. * from sysprocesses where blocked>0 ) b where a.blocked=spid)union select. spid,blocked from sysprocesses where blocked>0IF @@ERROR<>0 RETURN @@ERROR -- 找到臨時表的記錄數select. @intCountProperties = Count(*),@intCounter = 1from #tmp_lock_whoIF @@ERROR<>0 RETURN @@ERROR if @intCountProperties=0select. '如今沒有阻塞和死鎖信息' as message-- 循環開始while @intCounter <= @intCountPropertiesbegin-- 取第一條記錄select. @spid = spid,@bl = blfrom #tmp_lock_who where Id = @intCounter beginif @spid =0 select. '引發數據庫死鎖的是: '+ CAST(@bl AS VARCHAR(10)) + '進程號,其執行的SQL語法以下'elseselect. '進程號SPID：'+ CAST(@spid AS VARCHAR(10))+ '被' + '進程號SPID：'+ CAST(@bl AS VARCHAR(10)) +'阻塞,其當前進程執行的SQL語法以下'DBCC INPUTBUFFER

 

與鎖定有關的兩個問題－－死鎖和阻塞

 

死鎖

 

死鎖是一種條件，不只僅是在關係數據庫管理系統 (RDBMS) 中發生，在任何多用戶系統中均可以發生的。當兩個用戶（或會話）具備不一樣對象的鎖，而且每一個用戶須要另外一個對象的鎖時，就會出現死鎖。每一個用戶都等待另外一個用戶釋放他的鎖。當兩個鏈接陷入死鎖時，Microsoft® SQL Server™ 會進行檢測。其中一個鏈接被選做死鎖犧牲品。該鏈接的事務回滾，同時應用程序收到錯誤。

 

 

若是死鎖變成單個公用事件，並且它們的回滾形成過多的性能降級，那麼就須要再次進行深刻完全的調查。使用跟蹤標記 1204。例如，下面的命令從命令提示符啓動 SQL Server，並啓用跟蹤標記 1204：

c:\\mssql\\binn\\sqlservr -T1204

 

 

如今全部消息都會顯示在啓動 SQL Server 的控制檯屏幕上和錯誤日誌中。

 

使用分佈式事務時，也可能發生死鎖。

 

阻塞

 

任何基於鎖的併發系統都不可避免地具備可能在某些狀況下發生阻塞的特徵。當一個鏈接控制了一個鎖，而另外一個鏈接須要衝突的鎖類型時，將發生阻塞。其結果是強制第二個鏈接等待，或在第一個鏈接上阻塞。

 

在本主題中，術語"鏈接"是指數據庫的單個登陸會話。每一個鏈接都做爲系統進程 ID (SPID) 出現。儘管每個 SPID 通常都不是單獨的進程上下文，但這裏經常用來指一個進程。更確切的說，每一個 SPID 都是由服務器資源和數據結構（爲給定客戶單個鏈接的請求提供服務）組成。單個客戶應用程序可能有一個或多個鏈接。就 SQL Server 而言，從單個客戶機上的單個客戶應用程序來的多個鏈接和從多個客戶應用程序或多個客戶機來的多個鏈接是沒有區別的。不論是來自同一應用程序仍是來自兩臺不一樣客戶機上單獨的應用程序，一個鏈接均可以阻塞另外一個鏈接。