在眾多數(shù)據(jù)庫當中，DB2數(shù)據(jù)庫是大家很少見到的，因此很多關(guān)于DB2數(shù)據(jù)庫的問題，大家都不清楚。就好比如何解決DB2數(shù)據(jù)庫死鎖問題的？下面我們將通過解決DB2數(shù)據(jù)庫死鎖過程記錄來為大家詳細介紹解決這個問題的方法。具體包括8個階段，相信通過這8個階段的學習，您就知道如何解決這個問題了。

大家可以想象，在沒有快照等功能下，分析死鎖就只能靠分析代碼了。但是這個處理非常復雜，單憑分析代碼，沒有任何頭緒。

　　階段1：我們懷疑是數(shù)據(jù)量的原因

由于生產(chǎn)環(huán)境的數(shù)據(jù)量特別大，這個處理還有很多其他表的處理。所以我們懷疑是不是大數(shù)據(jù)量導致系統(tǒng)負荷過高，導致了死鎖？

于是我們?nèi)〉昧税l(fā)生死鎖時CPU，硬盤，網(wǎng)絡(luò)等等負載信息。沒有找到任何線索。

　　階段2：做一個測試程序，在測試環(huán)境中用多線程模擬多用戶去做這個處理。

為了能夠在開發(fā)環(huán)境再現(xiàn)出這個死鎖，我們做了一個多線程的測試程序，模擬多用戶運行。可惜，還是沒有再現(xiàn)出來。

　　階段3：分析測試環(huán)境數(shù)據(jù)庫和產(chǎn)品環(huán)境數(shù)據(jù)庫的差異

此時我們懷疑還是數(shù)據(jù)量導致的問題。于是我們盡可能的將開發(fā)環(huán)境的數(shù)據(jù)弄得和產(chǎn)品環(huán)境一樣多。之后在運行測試，還是沒有再現(xiàn)出來。

　　階段4：分析用戶的操作log

沒有任何辦法的情況下，我們只好分析用戶的操作log，希望從中找到一點線索。功夫不負有心人，我們發(fā)現(xiàn)，當兩個人同時；

進行這個操作的時候，基本都會發(fā)生死鎖。所以，我們判斷還是兩個人同時操作導致的問題。但是，為什么開發(fā)環(huán)境上模擬了。

很多人的操作，卻沒有發(fā)生死鎖呢？

　　階段5：發(fā)現(xiàn)數(shù)據(jù)庫設(shè)置的問題

我們又修改了測試程序，將模擬的用戶數(shù)量提高，但是很不幸，仍然沒有再現(xiàn)這個問題。此時我們注意到了：是不是開發(fā)環(huán)境的；

數(shù)據(jù)庫設(shè)置和產(chǎn)品環(huán)境的數(shù)據(jù)庫設(shè)置不同？我們對比了一下兩個數(shù)據(jù)庫的設(shè)置：發(fā)現(xiàn)好多參數(shù)不同。但是我們僅僅關(guān)注了和鎖有關(guān)的設(shè)置，也就是包含 LOCK關(guān)鍵字的設(shè)置。

　　階段6：將測試環(huán)境數(shù)據(jù)庫和產(chǎn)品環(huán)境數(shù)據(jù)庫的設(shè)置保持一致

我們將所有和lock有關(guān)的設(shè)置都改成了和產(chǎn)品環(huán)境一直。但是仍然沒有再現(xiàn)這個死鎖。終于，一個人發(fā)現(xiàn)，"cur_commit"這個設(shè)置不同。于是查詢文檔，發(fā)現(xiàn)了 cur_commit的特點。

當cur_commit = false的時候，下列情況會造成死鎖：

線程1插入數(shù)據(jù)A，然后線程2插入數(shù)據(jù)B。

　　在線程2還沒有提交事物之前，線程1查詢數(shù)據(jù)A，就會造成死鎖了。

開發(fā)環(huán)境中，cur_commit = true，所以我們一直也模擬不出來這個現(xiàn)象。

于是，我們把cur_commit也改成了 false。

　　階段7：使用測試程序去模擬

我們修改了測試程序，模擬上面兩個線程的操作，成功地再現(xiàn)了這個死鎖。錯誤的log信息和產(chǎn)品環(huán)境上也是一致的。

　　階段8：使用畫面操作去模擬

然后我們修改了程序，使用畫面去操作，也成功地再現(xiàn)了這個死鎖。

　　解決方案：

解決方案很簡單，就是把查詢語句中的條件加為索引，就不會出現(xiàn)死鎖了。由于這個表數(shù)據(jù)量不大，所以性能幾乎沒有任何影響。

以上就是關(guān)于如何解決DB2數(shù)據(jù)庫死鎖問題的全部內(nèi)容，想了解更多關(guān)于DB2數(shù)據(jù)庫的信息，請繼續(xù)關(guān)注中培偉業(yè)。