生活随笔
收集整理的這篇文章主要介紹了
一次查找sqlserver死锁的经历
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
查找bug是程序員的家常便飯，我身邊的人喜歡讓用戶來重現(xiàn)問題。當然他們也會從正式服務器上下載錯誤log，然后嘗試分析log，不過當錯誤不是那種不經(jīng)思考就可識別的情況，他們就會將問題推向用戶，甚至怪罪程序依賴的平臺。他們常用的借口就是“這個問題很難重現(xiàn)，需要持續(xù)監(jiān)控，而且不知道要監(jiān)控幾天”。下次出現(xiàn)，同樣是這個說法。
編程珠璣一書的作者說，“對付問題而不是程序”，這是方向。程序員一旦有了方向就是全世界最聰明的人，反之則會用最聰明的頭腦做最蠢的事情，說最蠢的話。查找錯誤的方向就是基于科學的方法理解問題、解決問題。
查找錯誤的一般方法
列出問題出現(xiàn)的可能原因(清單)。 針對問題發(fā)現(xiàn)的可能性進行排序清單。 假設問題就如清單其中一項所述，然后(編寫程序)去重現(xiàn)問題。 循環(huán)3，并且在不可能出現(xiàn)的行畫上一條刪除線。 你可以說，這是窮舉法。以下是查找問題的過程簡述。
問題描述
前幾天被突然叫到會議室，老板讓暫停所有的工作，優(yōu)先處理一個緊急問題。然后屏幕上出現(xiàn)了以下的一段log：
“事務(進程 ID 78)與另一個進程被死鎖在 鎖 資源上，并且已被選作死鎖犧牲品。請重新運行該事務。; nested exception is com.microsoft.sqlserver.jdbc.SQLServerException: 事務(進程 ID 78)與另一個進程被死鎖在 鎖 資源上，并且已被選作死鎖犧牲品。請重新運行該事務。”
看完了log，老板接著說明這個問題的緊急性--系統(tǒng)正處于驗收階段。
列出可能的清單
針對這個問題，我google了一下，發(fā)現(xiàn)大部分文章描述sqlserver的死鎖時，經(jīng)常談到兩種場景。
場景1：
事務A: delele from table1 where id= 1; select * from table2;
事務B: delele from table2 where id= 1; select * from table1;
?
要理解這個場景，首先要了解兩種鎖的區(qū)別：X鎖和S鎖。簡單的說，就是當試圖刪除、更新表時，我們會在該表上加一個X鎖，這個X鎖是排他鎖，影響是除非表上的X鎖被釋放，不然其它人無法再加如何鎖；而S鎖是一個共享鎖，它允許同一時間有多個共享鎖存在，但是除了X鎖以外。
假設場景1是并行執(zhí)行的，事務1開始對table1加上了X鎖，同時事務2也對table2加上了X鎖。接下來它們又分別試圖請求，在對方已經(jīng)加上了X鎖的表上加上S鎖。從前面得知，X鎖是排他鎖，而事務的特性是，所有的鎖資源都會在事務完成以后才釋放。 這時候事務間各自擁有對方請求的資源，又同時請求對方擁有的資源，并且要釋放自身的資源，先要請求到對方的資源，就發(fā)生死鎖了。
場景2：
事務A：delete from table1 where id =(1,..,n);
據(jù)說這個場景的死鎖比較普遍，但是很難理解，因為它們由始至終只操作一個表。要理解這個，還需從sqlserver中的bookmark search說起:如果select 語句中，查詢的欄位不包含在邏輯索引中，比如c3，那么sqlserver將試圖在使用物理索引id來查找c3的值。
現(xiàn)在再來看一下過程中發(fā)生的鎖，select語句會在邏輯索引(c1,c2)上加上S鎖，然后為了返回不在邏輯索引的欄位(c3)，它還需要在物理索引(id)上加上S鎖；而更新呢？我們都知道，更新表時，我們需要對物理索引(id)加上排他鎖以完成表的更新，并且隨后還會被要求更新邏輯索引(c1,c2)。所以事務A先請求對id列的X鎖，隨后請求c1,c2列的X鎖；而事務B會先請求c1,c2的S鎖，接著請求id的S鎖來返回c3的值。死鎖就這樣發(fā)生了。
幸虧這個場景發(fā)生的前提是頻繁查詢以及頻繁更新表。
至此，我們的清單中有了兩項場景1與場景2。根據(jù)2/8原則，先嘗試最有可能的往往事半功倍。我隨之放棄了猜測，馬上進入驗證階段。開始先給它們排個序，我將場景1放在第一項，原因是它比場景2更容易被發(fā)現(xiàn)。因為場景2的特點是隨機，即使有這樣的兩個事務并發(fā)(這種情況太普遍了)，死鎖也是很難出現(xiàn)。
重現(xiàn)問題
假設清單第一項(場景1)是問題的原因，那么它應該是這樣的：系統(tǒng)中肯定存在這樣的兩個事務，一個事務對產(chǎn)生死鎖的表(暫時稱為deadlockedtable)讀取，并且對另外的表(暫時稱為causelockedtable)更新；而另一事務對deadlockedtable更新，對causelockedtable讀取。
以此，我查找了項目的所有事務代碼，沒有找到。
接下來，我在這個選項上劃上一條刪除線。
開始選擇清單的下一項，然后繼續(xù)
關(guān)于場景2在系統(tǒng)中的確存在，這要從系統(tǒng)的業(yè)務談起，出現(xiàn)錯誤的系統(tǒng)是一個考勤管理系統(tǒng)，客戶公司有大約2000人使用系統(tǒng)，系統(tǒng)每天凌晨都會計算2000人當天的考勤排配表。由于公司嚴格的考勤機制，員工上班前都會查看自己當天的考勤排配表；對于那些請假、出差的員工，他們在系統(tǒng)中請假被批準后，系統(tǒng)需要重新計算其考勤。這里一直提到考勤結(jié)果，是因為出現(xiàn)死鎖的表就是考勤結(jié)果表，而出現(xiàn)死鎖的時間剛好為員工上班高峰期及凌晨計算全公司員工排配表兩個時段，并且很隨機及短暫。
這和場景2描述的很類似--頻繁更新和查詢。
問題時如何重新這個異常。
2000人的公司，由于三班倒的機制，我按照大約只有二分之一的員工在某個點上班，1/10的并發(fā)幾率，100個并發(fā)。該公司的員工總有5%左右的人需要申請請假、調(diào)休或者出差等等。他們經(jīng)常被統(tǒng)一時間批準申請。所以計算的并發(fā)可能為50。
模擬代碼如下
public class PerformanceTest extends BaseTestCase {
??? private int logLevel = 0;
??? public void setLogLevel(int i) {
??? private static class TaskStats {
??? class PerfTask implements Callable<TaskStats> {
??????? public void runOnce() {
??????????????? long rbegin = System.currentTimeMillis();
??????????????? long rend = System.currentTimeMillis();
??????????????? long bend = System.currentTimeMillis();
??????????????? Thread.yield();
?????? @Override
??? private void run(int nrIterations, int nrThreads) {
??????? ExecutorService threadPool = Executors.newFixedThreadPool(nrThreads);
??????? List<Callable<TaskStats>> tasks = new ArrayList<Callable<TaskStats>>();
??????? if (logLevel >= 1) {
??????? if (logLevel >= 1) { System.out.println("started"); }
??????? if (logLevel >= 1) { System.out.println("go"); }
??????? if (logLevel >= 1) { System.out.println("finish"); }
??????? TaskStats aggregate = new TaskStats();
??????? System.out.println("-----------------------------------------");
??????? threadPool.shutdown();
??? @Test
為了盡可能的接近真實情況，這個代碼最好在兩臺以上的電腦上運行，并且要注意避免sql共享機制，這點可以讓參數(shù)隨機產(chǎn)生。
程序跑了10分鐘后，死鎖果真出現(xiàn)了，如log錯誤描述一般。
轉(zhuǎn)載于:https://blog.51cto.com/ijeremy/1062688
總結(jié)
以上是生活随笔 為你收集整理的一次查找sqlserver死锁的经历 的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
如果覺得生活随笔 網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔 推薦給好友。
