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

事務的概念及ACID特性

事務（Transaction）

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

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

事務的特性（ACID 特性）

• Atomicity: 原子性

構成該事務的操作集合中的全部操作在事務的運行過程中全部執行或者全部不執行。

• Consistency: 一致性

事務運行的結果應該使數據庫保持數據一致性。

• Isolation:隔離性

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

• Durability: 持久性

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

并發事務的調度

1、并發問題和并發操作

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

并發事務之間相互影響，會破壞相關事務的正常運行，無法保證事務的 ACID 特性，產生數據錯誤。

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

舉例說明

兩個售票點同時售出同一天同一車次的車票，第一個售票點執行的數據庫事務 T1 為：
（1）讀出當前車票的剩余數量 A，假設 A=50；
（2）售出一張票，剩余數量變為 A=A-1，即 A=49。

第二個售票點執行的數據庫事務 T2 為：
（1）讀出當前車票的剩余數量 A，假設 A=50；
（2）售出一張票，剩余數量變為 A=A-1，即 A=49。

事務 T1 和 T2 按照如下順序并發執行：
（1）讀出當前車票的剩余數量 A，假設 A=50；
（2）讀出當前車票的剩余數量 A，假設 A=50；
（3）售出一張票，剩余數量變為 A=A-1，即 A=49；
（4）售出一張票，剩余數量變為 A=A-1，即 A=49。

事務執行的結果是只賣了一張車票，而實際上售出了兩張，這樣就可能導致同一個座位售出兩張車票，數據庫出現了數據的不一致性錯誤。

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

2、調度

調度（Schedule）是指事務的執行次序。如果多個事務依次執行，則稱為事務的串行調度（Serial Schedule）。如果多個事務同時執行，則稱為事務的并發調度（Concurrent Schedule）

3、沖突

沖突（conflict）：事務調度中的兩個操作（讀操作或寫操作），如果交換順序執行，它們所屬的事務運行結果會改變，那么這兩個操作就被稱為沖突。

不同事務對于不同數據對象進行操作（無論是讀操作還是寫操作）不會產生沖突；不同事務對同一數據對象進行讀操作也不會產生沖突。

4、封鎖

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

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

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

5、封鎖產生的問題

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

• 活鎖問題

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

活鎖由于事務永遠得不到封鎖而導致。避免活鎖可以采用先來先服務的策略。當多個事務請求封鎖同一個數據對象時，可按照請求封鎖的先后次序對事務排隊，數據對象上的鎖一旦釋放就批準申請隊列的第一個事務獲得封鎖。　

• 死鎖問題

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

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

用例簡單復現死鎖產生

GBase模式下（會話1）：

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

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

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

寫在最后

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