DB2死鎖的解決過程全記錄

DB2主要應用於大型應用系統，具有較好的可擴充性，可支援從大型主機到單一使用者環境。 DB2提供了高層次的資料可利用性、完整性、安全性、可恢復性。這篇文章主要介紹了DB2死鎖的解決過程全記錄,本文造成死鎖的是select語句,處理過程相當困難,需要的朋友可以參考下

生產環境裡使用的資料庫是DB2。但最近常出現一個奇怪的死鎖現象：某一個select sql 語句總是會出現死鎖。

依照以往的經驗，通常都是update/delete之類的更新sql語句會出現死鎖的問題。而這個 select sql 語句是一個很普通的sql，沒有任何大數據量的處理。

分析這個死鎖，有很多難以處理的地方。

1、因為生產環境資料量大，我們無法把生產環境中關聯表的資料匯入測試環境。也就是說，無法模擬數據量。
2、沒有任何log輸出。因為生產環境的log輸出等級是ERROR。
3、無法在生產環境進行測試，因為客戶不允許。
4、生產環境的資料庫無法開啟快照等功能。因為會影響性能。

大家可以想像，在沒有快照等功能下，分析死鎖就只能靠分析程式碼了。但是這個處理非常複雜，單憑分析程式碼，沒有任何頭緒。
 
階段1：我們懷疑是資料量的原因
 
#由於生產環境的資料量特別大，這個處理還有很多其他表格的處理。所以我們懷疑是不是大數據量導致系統負荷過高，導致了死鎖？
於是我們取得了發生死鎖時CPU，硬碟，網路等等負載資訊。沒有找到任何線索。
 
階段2：做一個測試程序，在測試環境中用多執行緒模擬多用戶去做這個處理。
 
為了能夠在開發環境中再現出這個死鎖，我們做了一個多執行緒的測試程序，模擬多用戶運行。可惜，還是沒有再現出來。
 
階段3：分析測試環境資料庫與產品環境資料庫的差異
 
此時我們懷疑還是資料量所造成的問題。於是我們盡可能的將開發環境的資料弄得和產品環境一樣多。
之後在執行測試，還是沒有再現出來。
 
階段4：分析使用者的操作log
 
沒有任何方法的情況下，我們只好分析使用者的操作log，希望從中找到一點線索。功夫不負有心人，我們發現，當兩個人同時
進行這個操作的時候，基本上都會發生死鎖。所以，我們判斷還是兩個人同時操作所導致的問題。但是，為什麼開發環境上模擬了
很多人的操作，卻沒有發生死鎖呢？
 
階段5：發現資料庫設定的問題
 
我們又修改了測試程序，將模擬的使用者數量提高，但是很不幸，仍然沒有再現這個問題。此時我們注意到了：是不是開發環境的
資料庫設定和產品環境的資料庫設定不同？我們比較了一下兩個資料庫的設定：發現好多參數不同。但是我們僅僅關注了和鎖有關
的設置，也就是包含 LOCK關鍵字的設置。
 
階段6：將測試環境資料庫和產品環境資料庫的設定保持一致
 
我們將所有和lock相關的設定都改成了和產品環境一直。但仍然沒有再現這個死鎖。終於，一個人發現，"cur_commit"這個設定
不同。於是查詢文檔，發現了 cur_commit的特色。
當 cur_commit = false的時候，下列情況會造成死鎖：
執行緒1插入資料A，然後執行緒2插入資料B。
在執行緒2還沒提交事物之前，執行緒1查詢資料A，就會造成死鎖了。
開發環境中，cur_commit = true，所以我們一直也模擬不出來這個現象。
於是，我們把cur_commit也改成了 false。
 
階段7：使用測試程序去模擬
 
我們修改了測試程序，模擬上面兩個執行緒的操作，成功地再現了這個死鎖。錯誤的log訊息和產品環境上也是一致的。
 
階段8：使用畫面操作去模擬
 
然後我們修改了程序，使用畫面去操作，也成功地再現了這個死鎖。
 
解決方案：
 
解決方案很簡單，就是把查詢語句中的條件加為索引，就不會出現死鎖了。
由於這個表資料量不大，所以效能幾乎沒有任何影響。

相關推薦：

詳解離線安裝db2的python模組ibm_db方法

Python連接DB2資料庫

使用PHP運算DB2 Express C的五種方法(1)_PHP教學

#

以上是DB2死鎖的解決過程全記錄的詳細內容。更多資訊請關注PHP中文網其他相關文章！