參考資料：
什么是事務？
事務(Transaction)是訪問並可能更新數據庫中各種數據項的一個程序執行單元(unit)。事務由事務開始(begin transaction)和事務結束(end transaction)之間執行的全體操作組成。
事務的屬性-ACID
-
原子性（Atomicity）-事務的原子性強調了一個事物是一個邏輯工作單元，是一個整體，是不可分割的。一個事務所包含的操作要么全部做，要不全部不做。
-
一致性（Consistency）-一個事務執行一項數據庫操作，事務使數據庫從一種一致性的狀態變換成另一種一致性狀態。
-
隔離性（Isolation）-在事務未提交前，它操作的數據，對其他用戶不可見。
-
持久性（Durability）-一旦事務成功完成，該事務對數據庫所施加的所有更新都是永久的。
- redo日志--提交的事務被永久的記錄到redo日志中。
數據庫事務的開始和結束
以第一個DML語句的執行作為開始
以下面的其中之一作為結束：
- commit或rollback語句
- DDL或DCL語句（自動提交）
- 用戶會話正常結束--commit
- 系統異常終了--rollback
並發與數據的讀取
當多個會話同時訪問（操作）相同的數據時，將會出現一些意想不到的結果。包括：
-
臟讀 --dirty reads
一個事務讀取了另一個事務未提交的數據,而這個數據是有可能回滾
-
不可重復讀 --non-repeatable reads
在數據庫訪問中，一個事務范圍內兩個相同的查詢卻返回了不同數據。這是由於查詢時系統中其他事務修改的提交而引起的。
-
幻讀 --Phantom（虛幻的） reads
事務1讀取記錄時事務2增加了記錄並提交，事務1再次讀取時可以看到事務2新增的記錄。對事物1而言就好像出現了幻覺一樣。
事務的隔離等級
ANSI定義的事務的隔離等級：
| 事務隔離等級 | 臟讀 | 不可重復讀 | 幻讀 |
|---|---|---|---|
| Read uncommited（讀未提交的） | Y | Y | Y |
| Read commited（讀提交的） | N | Y | Y |
| Repeatable read | N | N | Y |
| Serializable | N | N | N |
Oracle定義的事務隔離等級：
| 事務隔離等級 | 影響 |
|---|---|
| Read commited | Oracle默認的隔離等級，對一條SQL，可以保證數據的一致性，對於一個事務，無法做到repeatable read。 |
| Serializable | 只能看到事務開始時所有提交的改變以及自身的改變 |
| Read-only | 只能看到事務開始時所有提交的改變，自身不允許DML操作 |
事務的並發控制-鎖
Oracle的鎖定機制
-
Oracle盡可能的減少鎖定的使用
-
Oracle的讀操作不會對表加鎖，一些數據庫會使用查詢鎖定（共享鎖，排它鎖）
-
Oracle通過回滾機制，保證讀不會受到阻塞
-
Oracle沒有鎖管理器
-
Oracle中鎖作為數據塊的一種屬性存在
Oracle和Sql Server鎖的區別
| Sql Server | Oracle |
|---|---|
| 並發和讀一致性不可兼得，必須犧牲一方 | 可兼得 |
| 因為鎖實現方式，事務代價昂貴 | 沒有真正的鎖，事務沒有資源代價 |
| 提倡盡快提交 | 主張按照業務需求確定事務邊界 |
事務的控制-savepoint
通過在事務中間設置檢查點，可以更加精細的控制事務，防止一部分錯誤操作導致整個事務重新運行。演示如下：
SQL> create table t(id int);
表已創建。
SQL> insert into t values(1);
已創建 1 行。
SQL> savepoint s1;
保存點已創建。
SQL> select * from t;
ID
----------
1
SQL> update t set id=2;
已更新 1 行。
SQL> savepoint s2;
保存點已創建。
SQL> select * from t;
ID
----------
2
SQL> rollback to s1;
回退已完成。
SQL> select * from t;
ID
----------
1
一旦返回到保存點s1之后s2就失去了效果，因為已經回到s1了，這時候s2還不存在。
自治事務
自治事務允許在一個事務中存在獨立的事務，它的操作不會對當前事務產生影響。
語法：
pragma autonomous_transaction
關於自治事務的使用可以參考：ORACLE中的自治事務
實驗演示如下：(演示用例來自參考資料Oracle中的自治事務)
首先是不使用自治事務
SQL> create table msg (msg varchar2(120));
SQL> set serveroutput on
SQL> declare
2 cnt number := -1; --} Global variables
3 procedure local is
4 begin
5 select count(*) into cnt from msg;
6 dbms_output.put_line('local: # of rows is '||cnt);
7
8 insert into msg values ('New Record');
9 commit;
10 end;
11 begin
12 delete from msg ;
13 commit;
14 insert into msg values ('Row 1');
15 local;
16 select count(*) into cnt from msg;
17 dbms_output.put_line('main: # of rows is '||cnt);
18 rollback;
19
20 local;
21 insert into msg values ('Row 2');
22 commit;
23
24 local;
25 select count(*) into cnt from msg;
26 dbms_output.put_line('main: # of rows is '||cnt);
27 end;
28 /
local: # of rows is 1 -> 子程序local中可以’看到’主匿名塊中的uncommitted記錄
main: # of rows is 2 -> 主匿名塊可以’看到’2條記錄(它們都是被local commit掉的)
local: # of rows is 2 -> 子程序local首先’看到’2條記錄,然后又commit了第三條記錄
local: # of rows is 4 -> 子程序local又’看到’了新增加的記錄(它們都是被local commit掉的),然后又commit了第五條記錄
main: # of rows is 5 -> 主匿名塊最后’看到’了所有的記錄.
PL/SQL 過程已成功完成。
從這個例子中,我們看到COMMIT和ROLLBACK的位置無論是在主匿名塊中或者在子程序中,都會影響到整個當前事務.
現在如果將procedure local改成自治事務,在procedure local后面加上：
pragma AUTONOMOUS_TRANSACTION;
效果如下：
SQL> declare
2 cnt number := -1; --} Global variables
3 procedure local is
4 pragma AUTONOMOUS_TRANSACTION;
5 begin
6 select count(*) into cnt from msg;
7 dbms_output.put_line('local: # of rows is '||cnt);
8
9 insert into msg values ('New Record');
10 commit;
11 end;
12 begin
13 delete from msg ;
14 commit;
15 insert into msg values ('Row 1');
16 local;
17 select count(*) into cnt from msg;
18 dbms_output.put_line('main: # of rows is '||cnt);
19 rollback;
20
21 local;
22 insert into msg values ('Row 2');
23 commit;
24
25 local;
26 select count(*) into cnt from msg;
27 dbms_output.put_line('main: # of rows is '||cnt);
28 end;
29 /
local: # of rows is 0 -> 子程序local中無法可以’看到’主匿名塊中的uncommitted記錄 (因為它是獨立的)
main: # of rows is 2 -> 主匿名塊可以’看到’2條記錄,但只有一條是被commited.
local: # of rows is 1 -> 子程序local中可以’看到’它前一次commit的記錄,但是主匿名塊中的記錄已經被提前rollback了
local: # of rows is 3 -> 子程序local 中可以’看到’3條記錄包括主匿名塊commit的記錄
main: # of rows is 4 ->主匿名塊最后’看到’了所有的記錄.
PL/SQL 過程已成功完成。
分布式事務
- 發生在多台數據庫之間的事務。
- 通過dblink方式進行事務處理。
- 分布式事務要比單機事務要復雜的多。
- 可能的風險：軟件，服務器，網絡。
分布式事務的組成
| 角色 | 描述 |
|---|---|
| client | 調用其它數據庫信息的節點 |
| database | 接受來自其它節點請求的節點 |
| Global coordinate | 發起分布式事務的節點（全局調度者） |
| Local coordinate | 處理本地事務，並和其它節點通信的節點（本地調度者） |
| Commit point site | 被global coordinate指定第一個提交或回滾事務的節點 |
commit Point Strength
Oracle選取Commit Point Strength（相當於權重）最大的數據庫作為Commit point。
Oracle分布式事務的機制-兩階段提交
2PC-two phase commit
- prepare phase
- commit phase
准備階段prepare phase
為了完成准備階段，除了commit point機器外，其它的數據庫機器按照以下步驟執行：
-
每個節點檢查自己是否被其它節點所引用，如果有，就通知這些節點准備提交（進入prepare階段）
-
每個節點檢查自己運行的事務，如果發現本地運行的事務不做修改數據操作，則跳過后面的步驟，直接返回一個read only給全局協調進程。
-
如果事務需要修改數據，為事務分配相應的資源用於保證修改的正常進行。
-
對事物做的修改，記錄redo信息。
-
本地redo保證事務失敗后的回滾。
-
當上面的工作都成功后，給全局協調進程返回准備就緒的信息，反之，返回失敗的信號。
提交階段commit phase
提交階段按下面的步驟進行：
- 全局協調器通知commit point進行提交
- commit point提交完成。
- commit point服務器通知全局協調器提交完成
- 全局協調器通知其它節點進行提交
- 其它節點提交本地的事務，釋放資源（提交先后順序根據Commit Point Strength）
- 其它節點在redo上記錄相應的redo日志，並標注提交完成
- 其它節點通知全局協調器提交完成。
分布式事務的結束
分布式事務的結束就是全局協調器和commit point兩者之間釋放資源的順序。
- 全局協調器通知commit point數據庫所有節點提交完成。
- commit point數據庫釋放和事務相關的所有資源，然后通知全局協調器。
- 全局協調器釋放自己持有的資源
- 分布式事務結束
分布式事務的安全性
2PC是否真的可以保證分布式事務的一致性？
- 理論上是不可能保證分布式事務的一致性。
關於CAP理論可以參見：CAP理論
記得幫我點贊哦！
精心整理了計算機各個方向的從入門、進階、實戰的視頻課程和電子書，按照目錄合理分類，總能找到你需要的學習資料，還在等什么？快去關注下載吧！！！
念念不忘，必有回響，小伙伴們幫我點個贊吧，非常感謝。
我是職場亮哥，YY高級軟件工程師、四年工作經驗，拒絕咸魚爭當龍頭的斜杠程序員。
聽我說，進步多，程序人生一把梭
如果有幸能幫到你，請幫我點個【贊】，給個關注，如果能順帶評論給個鼓勵，將不勝感激。
職場亮哥文章列表：更多文章
本人所有文章、回答都與版權保護平台有合作，著作權歸職場亮哥所有，未經授權，轉載必究！