達夢8 死鎖模擬

1.創建兩個簡單的表t1_deadlock和t2_deadlock，每個表中僅僅包含一個字段a

SQL> create table t1_deadlock (a int);

操作已執行

已用時間: 6.906(毫秒). 執行號:23.

SQL> create table t2_deadlock (a int);

操作已執行

已用時間: 3.168(毫秒). 執行號:24.

2.每張表中僅初始化一條數據

SQL> create table t2_deadlock (a int);

操作已執行

已用時間: 3.168(毫秒). 執行號:24.

SQL> insert into t1_deadlock values (1);

影響行數 1

已用時間: 0.566(毫秒). 執行號:25.

SQL> insert into t2_deadlock values (2);

影響行數 1

已用時間: 0.803(毫秒). 執行號:26.

SQL> commit;

操作已執行

已用時間: 1.057(毫秒). 執行號:27.

3.在第一個會話session1中更新表t1_deadlock中的記錄“1”為“1000”，不進行提交

SQL> update t1_deadlock set a = 1000 where a = 1;

影響行數 1

已用時間: 1.608(毫秒). 執行號:28.

4.在第二個會話session2中更新表t2_deadlock中的記錄“2”為“2000”，不進行提交

SQL> update t2_deadlock set a = 2000 where a = 2;

影響行數 1

已用時間: 3.345(毫秒). 執行號:29.

5.此時，沒有任何問題發生。OK，現在注意一下下面的現象，我們再回到會話session1中，更新t2_deadlock的記錄

SQL> update t2_deadlock set a = 2000 where a = 2;

這里出現了“鎖等待”（“阻塞”）的現象，原因很簡單，因為在session2中已經對這條數據執行過這個操作，在session2中已經對該行加了行級鎖。

注意，這里是“鎖等待”，不是“死鎖”，注意這兩個概念的區別！

6.我們關注的“死鎖”馬上就要隆重出場了：在會話session2中，更新t1_deadlock的記錄

SQL> update t1_deadlock set a = 1000 where a = 1;

update t1_deadlock set a = 1000 where a = 1;


[-6403]:死鎖.

已用時間: 310.980(毫秒). 執行號:0.

7.以上種種現象說明什么？

說明： DM對于“死鎖”是會做自動處理的，而不是不聞不問。

8.總結

死鎖與阻塞的不同之處在于死鎖包括兩個或者多個已阻塞事務，它們之間形成了等待環，每個都等待其他事務釋放鎖。例如事務1給表T1上了排他鎖，第二個事務給表T2上了排他鎖，此時事務1請求T2的排他鎖，就會處于等待狀態，被阻塞。若此時T2再請求表T1的排他鎖，則T2也處于阻塞狀態。此時這兩個事務發生死鎖，DM數據庫會選擇犧牲掉其中一個事務。

參考：《DM8系統管理員手冊》19.8 鎖等待與死鎖檢測