同事的程序中,經常發(fā)生的情況是:在程序運行過程中,突然無緣無故的停住了,沒有在繼續(xù)運行下去。后來經過調試發(fā)現(xiàn)是因為 數(shù)據(jù)庫 發(fā)生了死鎖。對于 數(shù)據(jù)庫 的死鎖,不是很明白,google了下,查到一些資料。 地址:http://www.cnblogs.com/xzq686/archive/20
同事的程序中,經常發(fā)生的情況是:在程序運行過程中,突然無緣無故的停住了,沒有在繼續(xù)運行下去。后來經過調試發(fā)現(xiàn)是因為數(shù)據(jù)庫發(fā)生了死鎖。對于數(shù)據(jù)庫的死鎖,不是很明白,google了下,查到一些資料。
地址:http://www.cnblogs.com/xzq686/archive/2008/04/24/1168784.html
表現(xiàn)一:
一個用戶A 訪問表A(鎖住了表A),然后又訪問表B
另一個用戶B 訪問表B(鎖住了表B),然后企圖訪問表A
這時用戶A由于用戶B已經鎖住表B,它必須等待用戶B釋放表B,才能繼續(xù),好了他老人家就只好老老實實在這等了
同樣用戶B要等用戶A釋放表A才能繼續(xù)這就死鎖了
解決方法:
這種死鎖是由于你的程序的BUG產生的,除了調整你的程序的邏輯別無他法
仔細分析你程序的邏輯,
1:盡量避免同時鎖定兩個資源
2: 必須同時鎖定兩個資源時,要保證在任何時刻都應該按照相同的順序來鎖定資源.
表現(xiàn)二:
用戶A讀一條紀錄,然后修改該條紀錄
這是用戶B修改該條紀錄
這里用戶A的事務里鎖的性質由共享鎖企圖上升到獨占鎖(for update),而用戶B里的獨占鎖由于A有共享鎖存在所以必須等A釋
放掉共享鎖,而A由于B的獨占鎖而無法上升的獨占鎖也就不可能釋放共享鎖,于是出現(xiàn)了死鎖。
這種死鎖比較隱蔽,但其實在稍大點的項目中經常發(fā)生。
解決方法:
讓用戶A的事務(即先讀后寫類型的操作),在select 時就是用Update lock
語法如下:
select * from table1 with(updlock) where ....
如果真的table被鎖住了,可以通過下面的方法來解鎖:
Sql server企業(yè)管理器->對應的數(shù)據(jù)庫->管理->當前活動->鎖/進程ID
將對應的被鎖住的進程關閉。
還有一種方法,就是在你不知道究竟是哪張表被鎖,由何種原因被鎖,可以重新啟動數(shù)據(jù)庫來解決,但不保證下次又被鎖住,因為還沒有找到問題的根本原因。
要避免鎖表,在操作數(shù)據(jù)庫最好不要用獨占方式。
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯(lián)系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com