在眾多數據庫當中，雖然DB2數據庫很少見，但是應用卻十分廣泛。DB2的主要操作環境是UNIX，Linux，IBMi，z / OS和Windows服務器版本。DB2的功能也相對強大，因為它具有完整的查詢優化器，并且其外部連接提高了查詢性能并支持多個Task并行查詢。同時DB2還具有良好的網絡支持功能，每個子系統可以連接成千上萬的分布式用戶，并且可以同時激活數千個活動線程，這特別適合于大型分布式應用程序系統。那么DB2數據庫管理系統是如何解決死鎖的？

　　DB2數據庫管理系統是如何解決死鎖的？

生產環境里使用的數據庫是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數據庫管理系統是如何解決死鎖的相信大家已經清楚了吧，想了解更多關于DB2數據庫的信息，請繼續關注中培偉業。