MSSQL產(chǎn)生死鎖的根本原因及解決方法
一、 什么是死鎖
死鎖是指兩個或兩個以上的進(jìn)程在執(zhí)行過程中,因爭奪資源而造成的一種互相等待的現(xiàn)象,若無外力作用,它們都將無法推進(jìn)下去.此時(shí)稱系統(tǒng)處于死鎖狀態(tài)或系統(tǒng)產(chǎn)生了死鎖,這些永遠(yuǎn)在互相等的進(jìn)程稱為死鎖進(jìn)程.
二、 死鎖產(chǎn)生的四個必要條件
•互斥條件:指進(jìn)程對所分配到的資源進(jìn)行排它性使用,即在一段時(shí)間內(nèi)某資源只由一個進(jìn)程占用。如果此時(shí)還有其它進(jìn)程請求資源,則請求者只能等待,直至占有資源的進(jìn)程用畢釋放
•請求和保持條件:指進(jìn)程已經(jīng)保持至少一個資源,但又提出了新的資源請求,而該資源已被其它進(jìn)程占有,此時(shí)請求進(jìn)程阻塞,但又對自己已獲得的其它資源保持不放
•不剝奪條件:指進(jìn)程已獲得的資源,在未使用完之前,不能被剝奪,只能在使用完時(shí)由自己釋放
•環(huán)路等待條件:指在發(fā)生死鎖時(shí),必然存在一個進(jìn)程——資源的環(huán)形鏈,即進(jìn)程集合{P0,P1,P2,···,Pn}中的P0正在等待一個P1占用的資源;P1正在等待P2占用的資源,……,Pn正在等待已被P0占用的資源
這四個條件是死鎖的必要條件,只要系統(tǒng)發(fā)生死鎖,這些條件必然成立,而只要上述條件之一不滿足,就不會發(fā)生死鎖。
三、 如何處理死鎖
1) 鎖模式
1.共享鎖(S)
由讀操作創(chuàng)建的鎖,防止在讀取數(shù)據(jù)的過程中,其它事務(wù)對數(shù)據(jù)進(jìn)行更新;其它事務(wù)可以并發(fā)讀取數(shù)據(jù)。共享鎖可以加在表、頁、索引鍵或者數(shù)據(jù)行上。在SQL SERVER默認(rèn)隔離級別下數(shù)據(jù)讀取完畢后就會釋放共享鎖,但可以通過鎖提示或設(shè)置更高的事務(wù)隔離級別改變共享鎖的釋放時(shí)間。
2.獨(dú)占鎖(X)
對資源獨(dú)占的鎖,一個進(jìn)程獨(dú)占地鎖定了請求的數(shù)據(jù)源,那么別的進(jìn)程無法在此數(shù)據(jù)源上獲得任何類型的鎖。獨(dú)占鎖一致持有到事務(wù)結(jié)束。
3.更新鎖(U)
更新鎖實(shí)際上并不是一種獨(dú)立的鎖,而是共享鎖與獨(dú)占鎖的混合。當(dāng)SQL SERVER執(zhí)行數(shù)據(jù)修改操作卻首先需要搜索表以找到需要修改的資源時(shí),會獲得更新鎖。
更新鎖與共享鎖兼容,但只有一個進(jìn)程可以獲取當(dāng)前數(shù)據(jù)源上的更新鎖,
其它進(jìn)程無法獲取該資源的更新鎖或獨(dú)占鎖,更新鎖的作用就好像一個序列化閥門(serialization gate),將后續(xù)申請獨(dú)占鎖的請求壓入隊(duì)列中。持有更新鎖的進(jìn)程能夠?qū)⑵滢D(zhuǎn)換成該資源上的獨(dú)占鎖。更新鎖不足以用于更新數(shù)據(jù)—實(shí)際的數(shù)據(jù)修改仍需要用到獨(dú)占鎖。對于獨(dú)占鎖的序列化訪問可以避免轉(zhuǎn)換死鎖的發(fā)生,更新鎖會保留到事務(wù)結(jié)束或者當(dāng)它們轉(zhuǎn)換成獨(dú)占鎖時(shí)為止。
4. 意向鎖(IX,IU,IS)
意向鎖并不是獨(dú)立的鎖定模式,而是一種指出哪些資源已經(jīng)被鎖定的機(jī)制。
如果一個表頁上存在獨(dú)占鎖,那么另一個進(jìn)程就無法獲得該表上的共享表鎖,這種層次關(guān)系是用意向鎖來實(shí)現(xiàn)的。進(jìn)程要獲得獨(dú)占頁鎖、更新頁鎖或意向獨(dú)占頁鎖,首先必須獲得該表上的意向獨(dú)占鎖。同理,進(jìn)程要獲得共享行鎖,必須首先獲得該表的意向共享鎖,以防止別的進(jìn)程獲得獨(dú)占表鎖。
5. 特殊鎖模式(Sch_s,Sch_m,BU)
SQL SERVER提供3種額外的鎖模式:架構(gòu)穩(wěn)定鎖、架構(gòu)修改鎖、大容量更新鎖。
6.轉(zhuǎn)換鎖(SIX,SIU,UIX)
轉(zhuǎn)換鎖不會由SQL SERVER 直接請求,而是從一種模式轉(zhuǎn)換到另一種模式所造成的。SQL SERVER 2008支持3種類型的轉(zhuǎn)換鎖:SIX、SIU、UIX.其中最常見的是SIX鎖,如果事務(wù)持有一個資源上的共享鎖(S),然后又需要一個IX鎖,此時(shí)就會出現(xiàn)SIX。
7.鍵范圍鎖
鍵范圍鎖是在可序列化隔離級別中鎖定一定范圍內(nèi)數(shù)據(jù)的鎖。保證在查詢數(shù)據(jù)的鍵范圍內(nèi)不允許插入數(shù)據(jù)。
SQL SERVER 鎖模式 |
||
縮寫 |
鎖模式 |
說明 |
S |
Shared |
允許其他進(jìn)程讀取但不能修改鎖定的資源 |
X |
Exclusive |
防止別的進(jìn)程讀取或者修改鎖定資源中的數(shù)據(jù) |
U |
Update |
防止其它進(jìn)程獲取更新鎖或獨(dú)占鎖;在搜索要修改的數(shù)據(jù)時(shí)使用 |
IS |
Intent shared |
表示該資源的一個組件被共享鎖鎖定了。只有在表或頁級別才能獲得這類鎖 |
IU |
Intent update |
表示該資源的一個組件被更新鎖鎖定了。只有在表或頁級別才能獲得這類鎖 |
IX |
Intent exclusive |
表示該資源的一個組件被獨(dú)占鎖鎖定了。只有在表或頁級別才能獲得這類鎖 |
SIX |
Shared with intent exclusive |
表示一個正持有共享鎖的資源還有一個組件(一頁或一行)被獨(dú)占鎖鎖定了 |
SIU |
Shared with intent Update |
表示一個正持有共享鎖的資源還有一個組件(一頁或一行)被更新鎖鎖定了 |
UIX |
Update with intent exclusive |
表示一個正持有更新鎖的資源還有一個組件(一頁或一行)被獨(dú)占鎖鎖定了 |
Sch-S |
Schema stability |
表示一個使用該表的查詢正在被編譯 |
Sch-M |
Schema modification |
表示表的結(jié)構(gòu)正在被修改 |
BU |
Bulk Update |
在一個大容量復(fù)制操作將數(shù)據(jù)導(dǎo)入表中并且(手動或自動)應(yīng)用了TABLOCK查 詢提示時(shí)使用 |
2) 鎖粒度
SQL SERVER 可以在表、頁、行等級別鎖定用戶的數(shù)據(jù)資源即非系統(tǒng)資源(系統(tǒng)資源是用閂鎖來保護(hù)的)。此外SQL SERVER 還可以鎖定索引鍵和索引鍵范圍。
通過sys.dm_tran_locks視圖可以查看誰被鎖定了(如行,鍵,頁)、鎖的模式以及特定資源的標(biāo)志符?;趕ys.dm_tran_locks視圖創(chuàng)建如下視圖用于查看鎖定的資源以及鎖模式(通過這個視圖可以查看事務(wù)鎖定的表、頁、行以及加在數(shù)據(jù)資源上的鎖類型)。
CREATE VIEW dblocks AS SELECT request_session_id AS spid, DB_NAME(resource_database_id) AS dbname, CASE WHEN resource_type='object' THEN OBJECT_NAME(resource_associated_entity_id) WHEN resource_associated_entity_id=0 THEN 'n/a' ELSE OBJECT_NAME(p.object_id) END AS entity_name, index_id, resource_type AS RESOURCE, resource_description AS DESCRIPTION, request_mode AS mode, request_status AS STATUS FROM sys.dm_tran_locks t LEFT JOIN sys.partitions p ON p.partition_id=t.resource_associated_entity_id WHERE resource_database_id=DB_ID()
3) 如何跟蹤死鎖
通過選擇sql server profiler 事件中的如下選項(xiàng)就可以跟蹤到死鎖產(chǎn)生的相關(guān)語句。
4) 死鎖案例分析
在該案例中process65db88, process1d0045948為語句1的進(jìn)程,process629dc8 為語句2的進(jìn)程; 語句2獲取了1689766頁上的更新鎖,在等待1686247頁上的更新鎖;而語句1則獲取了1686247頁上的更新鎖在等待1689766頁上的更新鎖,兩個語句等待的資源形成了一個環(huán)路,造成死鎖。
5) 如何解決死鎖
針對如上死鎖案例,分析其對應(yīng)語句執(zhí)行計(jì)劃如下:
通過執(zhí)行計(jì)劃可以看出,在查找需要更新的數(shù)據(jù)時(shí)使用的是索引掃描,比較耗費(fèi)性能,這樣就造成鎖定資源時(shí)間過長,增加了語句并發(fā)執(zhí)行時(shí)產(chǎn)生死鎖的概率。
處理方式:
1. 在表上建立一個聚集索引。
2. 對語句更新的相關(guān)字段建立包含索引。
優(yōu)化后該語句執(zhí)行計(jì)劃如下:
優(yōu)化后的執(zhí)行計(jì)劃使用了索引查找,將大幅提升該查詢語句的性能,降低了鎖定資源的時(shí)間,同時(shí)也減少了鎖定資源的范圍,這樣就降低了鎖資源循環(huán)等待事件發(fā)生的概率,對于預(yù)防死鎖的發(fā)生會有一定的作用。
死鎖是無法完全避免的,但如果應(yīng)用程序適當(dāng)處理死鎖,對涉及的任何用戶及系統(tǒng)其余部分的影響可降至最低(適當(dāng)處理是指發(fā)生錯誤1205時(shí),應(yīng)用程序重新提交批處理,第二次嘗試大多能成功。一個進(jìn)程被殺死,它的事務(wù)被取消,它的鎖被釋放,死鎖中涉及到的另一個進(jìn)程就可以完成它的工作并釋放鎖,所以就不具備產(chǎn)生另一個死鎖的條件了。)
四、 如何預(yù)防死鎖
阻止死鎖的途徑就是避免滿足死鎖條件的情況發(fā)生,為此我們在開發(fā)的過程中需要遵循如下原則:
1.盡量避免并發(fā)的執(zhí)行涉及到修改數(shù)據(jù)的語句。
2.要求每一個事務(wù)一次就將所有要使用到的數(shù)據(jù)全部加鎖,否則就不允許執(zhí)行。
3.預(yù)先規(guī)定一個加鎖順序,所有的事務(wù)都必須按照這個順序?qū)?shù)據(jù)執(zhí)行封鎖。如不同的過程在事務(wù)內(nèi)部對對象的更新執(zhí)行順序應(yīng)盡量保證一致。
4.每個事務(wù)的執(zhí)行時(shí)間不可太長,對程序段的事務(wù)可考慮將其分割為幾個事務(wù)。在事務(wù)中不要求輸入,應(yīng)該在事務(wù)之前得到輸入,然后快速執(zhí)行事務(wù)。
5.使用盡可能低的隔離級別。
6.數(shù)據(jù)存儲空間離散法。該方法是指采用各種手段,將邏輯上在一個表中的數(shù)據(jù)分散的若干離散的空間上去,以便改善對表的訪問性能。主要通過將大表按行或者列分解為若干小表,或者按照不同的用戶群兩種方法實(shí)現(xiàn)。
7.編寫應(yīng)用程序,讓進(jìn)程持有鎖的時(shí)間盡可能短,這樣其它進(jìn)程就不必花太長的時(shí)間等待鎖被釋放。
- MS sqlserver 2008數(shù)據(jù)庫轉(zhuǎn)換成2000版本的方法
- MSSql簡單查詢出數(shù)據(jù)表中所有重復(fù)數(shù)據(jù)的方法
- MSSQL分頁存儲過程完整示例(支持多表分頁存儲)
- PHP封裝的MSSql操作類完整實(shí)例
- 拯救你的數(shù)據(jù) 通過日志恢復(fù)MSSQL數(shù)據(jù)
- SQL(MSSQLSERVER)服務(wù)啟動錯誤代碼3414的解決方法
- PHP連接MSSQL方法匯總
- ASP.NET和MSSQL高性能分頁實(shí)例代碼
- 如何處理Python3.4 使用pymssql 亂碼問題
- MS SQL 實(shí)現(xiàn)驗(yàn)證字符串是否包含有大小寫字母的功能
相關(guān)文章
使用Rotate Master實(shí)現(xiàn)MySQL 多主復(fù)制的實(shí)現(xiàn)方法
眾所周知,MySQL只支持一對多的主從復(fù)制,而不支持多主(multi-master)復(fù)制2012-05-05SQL Server 完整備份遇到的一個不常見的錯誤及解決方法
這篇文章給大家介紹了SQL Server 完整備份遇到的一個不常見的錯誤及解決方法,非常不錯,具有一定的參考借鑒價(jià)值,需要的朋友參考下吧2019-05-05MySQL中實(shí)現(xiàn)插入或更新操作(類似Oracle的merge語句)
這篇文章主要介紹了在MySQL中實(shí)現(xiàn)插入或更新操作(類似Oracle的merge語句)的相關(guān)資料,非常不錯,具有參考借鑒價(jià)值,需要的朋友可以參考下2016-09-09