本文探討南大通用GBase 8s數(shù)據(jù)庫的事務處理特性，揭示其如何確保ACID特性，并有效管理并發(fā)事務。

事務的概念及ACID特性

事務（Transaction）

將用戶在數(shù)據(jù)庫中的某些操作集合看作一個整體，在其有序執(zhí)行的過程中不被其他操作影響，這樣的操作集合就是事務。

事務（Transaction）是對數(shù)據(jù)庫進行操作的集合。該集合是一個不可分割的具有邏輯功能的工作單元，集合中的操作在事務的一次執(zhí)行中必須全部被執(zhí)行或者全部。

事務的特性（ACID 特性）

• Atomicity: 原子性

構(gòu)成該事務的操作集合中的全部操作在事務的運行過程中全部執(zhí)行或者全部不執(zhí)行。

• Consistency: 一致性

事務運行的結(jié)果應該使數(shù)據(jù)庫保持數(shù)據(jù)一致性。

• Isolation:隔離性

構(gòu)成某個事務的全部操作與其他事務或操作是隔離的，同時執(zhí)行的事務之間不能夠互相影響，一個事務單獨運行的結(jié)果應該與該事務和其他多個事務同時運行的結(jié)果一致。

• Durability: 持久性

事務的持久性是指事務運行完畢并成功提交后，其對數(shù)據(jù)庫全部操作的結(jié)果應該永久地保留在數(shù)據(jù)庫中。

并發(fā)事務的調(diào)度

1、并發(fā)問題和并發(fā)操作

實際應用中，通常會有來自不同用戶的多個事務并發(fā)執(zhí)行，事務之間會有交叉，這個問題就是事務的并發(fā)問題。

并發(fā)事務之間相互影響，會破壞相關(guān)事務的正常運行，無法保證事務的 ACID 特性，產(chǎn)生數(shù)據(jù)錯誤。

并發(fā)操作（Simultaneous Concurrency）是并發(fā)事務中包含的對數(shù)據(jù)庫的操作，由多個事務并發(fā)進行而產(chǎn)生，其最大問題是容易導致數(shù)據(jù)庫的不一致性

舉例說明

兩個售票點同時售出同一天同一車次的車票，第一個售票點執(zhí)行的數(shù)據(jù)庫事務 T1 為：
（1）讀出當前車票的剩余數(shù)量 A，假設(shè) A=50；
（2）售出一張票，剩余數(shù)量變?yōu)?A=A-1，即 A=49。

第二個售票點執(zhí)行的數(shù)據(jù)庫事務 T2 為：
（1）讀出當前車票的剩余數(shù)量 A，假設(shè) A=50；
（2）售出一張票，剩余數(shù)量變?yōu)?A=A-1，即 A=49。

事務 T1 和 T2 按照如下順序并發(fā)執(zhí)行：
（1）讀出當前車票的剩余數(shù)量 A，假設(shè) A=50；
（2）讀出當前車票的剩余數(shù)量 A，假設(shè) A=50；
（3）售出一張票，剩余數(shù)量變?yōu)?A=A-1，即 A=49；
（4）售出一張票，剩余數(shù)量變?yōu)?A=A-1，即 A=49。

事務執(zhí)行的結(jié)果是只賣了一張車票，而實際上售出了兩張，這樣就可能導致同一個座位售出兩張車票，數(shù)據(jù)庫出現(xiàn)了數(shù)據(jù)的不一致性錯誤。

并發(fā)操作導致數(shù)據(jù)庫出現(xiàn)數(shù)據(jù)不一致性的問題，如下表所示。事務 T1 將數(shù)據(jù)對象，即火車票的總數(shù) A 進行了修改，變?yōu)?49，而事務 T2 在 T1 修改 A 之前讀取的 A 的值仍然是 50，T2 將此值修改為 49 后寫回數(shù)據(jù)庫并覆蓋了 T1 事務對 A 的修改，此時，A 的值為49，就會出現(xiàn)這種情況：賣出兩張車票后車票總數(shù)應為 48，而數(shù)據(jù)庫中車票的總數(shù)為 49，顯然出現(xiàn)了數(shù)據(jù)的不一致性錯誤。

2、調(diào)度

調(diào)度（Schedule）是指事務的執(zhí)行次序。如果多個事務依次執(zhí)行，則稱為事務的串行調(diào)度（Serial Schedule）。如果多個事務同時執(zhí)行，則稱為事務的并發(fā)調(diào)度（Concurrent Schedule）

3、沖突

沖突（conflict）：事務調(diào)度中的兩個操作（讀操作或?qū)懖僮鳎绻粨Q順序執(zhí)行，它們所屬的事務運行結(jié)果會改變，那么這兩個操作就被稱為沖突。

不同事務對于不同數(shù)據(jù)對象進行操作（無論是讀操作還是寫操作）不會產(chǎn)生沖突；不同事務對同一數(shù)據(jù)對象進行讀操作也不會產(chǎn)生沖突。

4、封鎖

并發(fā)控制的主要技術(shù)是封鎖（Locking）。封鎖的對象是數(shù)據(jù)庫中的數(shù)據(jù)對象，如關(guān)系型數(shù)據(jù)庫中的表、記錄、屬性、索引等。對數(shù)據(jù)對象加鎖的時機是在事務對其進行操作之前，向系統(tǒng)發(fā)出加鎖請求。

加鎖后事務 T就取得了對該數(shù)據(jù)對象的控制，在事務 T 釋放它的鎖之前，其他事務不能對此數(shù)據(jù)對象進行任何操作。

封鎖是一種排隊機制，將并行任務按鎖的先后順序排隊，把并行任務變成串行任務。

5、封鎖產(chǎn)生的問題

封鎖技術(shù)在一定程度上解決了數(shù)據(jù)庫的并發(fā)事務處理過程中，并發(fā)操作給數(shù)據(jù)庫帶來的數(shù)據(jù)一致性問題，但同時產(chǎn)生了新的問題如活鎖和死鎖。

• 活鎖問題

在處理并發(fā)事務的過程中，如果事務T1在數(shù)據(jù)對象R上加鎖，事務T2又請求為數(shù)據(jù)對象R加鎖，則 T2 必須等待T1釋放加在R上的鎖。如果事務 T3 也請求為 R加鎖，當T1釋放了R上的鎖之后系統(tǒng)首先響應T3的請求，則允許T3對R加鎖，此時 T2 仍需等待T3 釋放加在R上的鎖。然后事務T4又請求封鎖R，當T3釋放了R上的封鎖之后系統(tǒng) 又響應了T4的請求……T2有可能永遠等待而無法為R加鎖，這就是活鎖（Live lock）。

活鎖由于事務永遠得不到封鎖而導致。避免活鎖可以采用先來先服務的策略。當多個事務請求封鎖同一個數(shù)據(jù)對象時，可按照請求封鎖的先后次序?qū)κ聞张抨牐瑪?shù)據(jù)對象上的鎖一旦釋放就批準申請隊列的第一個事務獲得封鎖。　

• 死鎖問題

如果事務 T1 對數(shù)據(jù)對象 R1 進行封鎖，T2 對數(shù)據(jù)對象 R2 進行封鎖，然后 T1 又請求對 R2 進行封鎖，由于 T2 已封鎖了 R2，則 T1 必須等待 T2 釋放 R2 上的鎖。接著 T2 又申請對 R1 進行封鎖，由于 T1 已封鎖 R1，因此，T2 也只能等待 T1 釋放 R1 上的鎖。這樣就出現(xiàn)了事務 T1 等待另一個事務 T2 釋放相關(guān)數(shù)據(jù)對象上的鎖，而 T2 又在等待 T1 釋放相關(guān)對象上的鎖，T1 和 T2 兩個事務由于相互等待對方釋放數(shù)據(jù)對象上的鎖而永遠不能繼續(xù)執(zhí)行，這樣就出現(xiàn)了死鎖。

死鎖（Dead Lock）：系統(tǒng)中有兩個或兩個以上的事務都處于等待狀態(tài)，并且每個事務都在等待其中另一個事務釋放封鎖，這樣才能繼續(xù)執(zhí)行下去，結(jié)果造成任何一個事務都無法繼續(xù)執(zhí)行，這種現(xiàn)象稱數(shù)據(jù)庫系統(tǒng)進入了“死鎖”（Dead Lock）狀態(tài)。

用例簡單復現(xiàn)死鎖產(chǎn)生

GBase模式下（會話1）：

那么兩個會話分別在同一個庫中，對a表和b表加上共享鎖S，當想進行更新時，會話1在等待會話2釋放a的S鎖，而會話2在等待會話1釋放b的S鎖，從而導致死鎖產(chǎn)生。

那么在oracle模式下，該用例卻不能產(chǎn)生死鎖。因為在GBase模式下，開啟事務后，可以保證兩個會話在執(zhí)行更新后才提交保證兩個會話同時進行。

而在oracle模式下，只能開啟多語句模式，DML語句會自動開啟事務，通過commit/rollback結(jié)束事務，DDL會提交事務。從而導致兩個會話可能無法同時進行，因此并行變成串行，導致死鎖無法產(chǎn)生。

寫在最后

南大通用GBase 8s數(shù)據(jù)庫的事務處理能力和并發(fā)控制機制，為企業(yè)提供了一個可靠、高效和安全的數(shù)據(jù)處理平臺。無論是金融交易還是在線事務處理，GBase 8s都能確保數(shù)據(jù)的完整性和一致性，滿足企業(yè)對數(shù)據(jù)庫系統(tǒng)的要求。