隨著系統的複雜性不斷增加，我們所面對的分散式系統漸漸增加。分散式檔案系統、分散式訊息佇列系統等等層出不窮，在一些行業特別是網際網路行業應用廣泛。分散式也是目前使用比較常用的分散式系統之一。
簡單來說，分散式資料庫就是透過多個相互連線的資料庫節點（注意不是Instance），來支援前端系統資料訪問需要的資料庫組織結構。各個節點之間相互獨立、自我（site autonomy）。分散式資料庫系統追求的主要目標包括：可用性（availability）、準確性（accuray）、一致性（concurrence）和可性（recoverability）。
在一些橫跨多部門、多資料來源和多子系統的複雜系統環境下，使用和組織分散式資料庫可能是一種低成本且更具有靈活性的解決方案。
1、從Remote Transaction到Distributed Transaction
資料庫事務是每一個DBMS最核心關注的問題。在分散式資料庫環境下，我們的事務物件可能會橫跨多個資料庫物件。為了保證ACID的基本事務規則，引入了分散式事務（Distributed Transaction）的概念。首先我們區分一下幾個基本的事務型別：
ü Local Transaction本地事務
操作語句資料範圍只是限制在本地節點上。
ü Remote Transaction遠端事務
事務中進行的增加、修改和刪除資料物件，存放在遠端Remote端的資料庫上。本地資料庫物件沒有參與到事務範圍中去。
ü Distributed Transaction分散式事務
所謂分散式事務，就是事務過程中涉及到對本地和遠端物件的增加、修改和刪除操作。
這裡注意一個問題，我們在這裡討論的分散式事務，是透過資料庫自身特性實現的分散式事務特性。目前，很多中介軟體，如Jboss，都提供了中介軟體級別的分散式事務支援。這種情況下，中介軟體會向Oracle提出分散式事務管理權獲取，之後的事務管理過程交付給Jboss管理。這種情況不是我們今天要討論的分散式事務問題。
2、事務物件實體
完全的分散式事務物件是有多個角色的，具體來說有如下幾個型別：
ü Client（C）客戶端：在分散式事務中，能夠獲取到遠端資料庫上物件引用（reference）的結點物件；
ü （S）伺服器：在分散式事務中，直接被引用，或者被其他節點請求獲取到資料的節點物件；
ü Global Coordinator（GC）全域性協調節點：是分散式事務啟動的節點；
ü Local Coordinator（LC）本地協調節點：引用了其他節點上的資料，來完成自身工作的節點物件。
ü Point Site（CPS）事務提交站點：事務涉及的節點中，具有commit_point_strength引數的站點。它通常是分散式事務中，最重要的一個站點物件。在發生“in-doublt”事務的時候，該站點是不能出現衝突的。
ü Commit_point_strength：是init.ora中的一個初始化引數。用來在分散式環境中確定CPS站點。
SQL> show parameter commit_point;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
commit_point_strength integer 1
注意，上面我們提及的分散式事務涉及物件，是指涉及的節點角色。在通常的Distributed Transaction中，一個實際的node是可以充當多個角色的。
3、Two-Phase Commit（）
Two-Phase Commit是分散式資料庫系統中一個經典事務模型，用於解決多個資料庫節點之間在進行事務提交過程中的方式問題。
二階段提交一共具有兩個階段，分別為準備階段（Prepare Phase）和提交階段（Commit Phase）。一個分散式事務，要經歷兩個階段過程：
ü 準備階段Prepare Phase
首先，事務涉及到的各個節點需要確定一個commit point site。同時，全域性協調者（Global Coordinator）向所有其他的節點（除了commit point site）發訊息，要求進行分散式commit或者rollback動作。
在GC傳送訊息的過程中，Local Coordinators會將這些訊息傳播到其依賴的節點上。保證訊息可以傳到分散式事務涉及到的所有節點物件。
對這些被通知到的節點而言，可能的反饋結果有三個：prepared、abort和read-only nodes。
注意，如果在這個過程中，有節點發出abort過程，整個過程就轉入到全域性rollback過程。
在反饋結果中，各個節點同時將自己的SCN號傳送到Global Coordinator節點。GC來確定出各節點中最大的事務SCN號。
經過了prepared phase，我們就可以進入到commit phase階段。在prepared phase結束一直到commit phase成功結束期間，除了在commit point site上進行的事務外的其他事務都進入所謂的“in-doubt”狀態。
ü 提交階段commit phase
GC向commit point site通知到對比完的最大的SCN編號。此時，Commit Point Site將進行commit動作或者rollback動作。注意，此時在cps上的鎖被釋放掉。
如果CPS成功的進行過commit或者rollback動作，它會通知到Global Coordinator進行提交的時間點。
該通知會透過GC/LC的傳導機制，傳導到所有的節點進行commit/rollback動作。
如果所有的過程全都成功結束，每個語句都在使用相同的SCN進行提交。之後，RECO程式開始進行分散式事務清理過程，清理在“dba_2pc_pending”和“dba_2pc_neighbors”中相應的資訊。之後，各個節點進入了“forget”階段，開始“忘記”事務資訊。
ü 忘記階段forget phase
當全部參與分散式事務的節點都完成了相應的commit或者rollback操作，它們就會通知到commit point site，告知當前事務操作結果。Commit point site就可以forget事務資訊了。
各個節點通訊並不是直接同cps進行，而是同GC。GC將結果資訊告知給commit point site，之後cps將該事務的資訊清除掉。
Cps在清除完事務資訊之後，通知GC自身已經清楚了分散式事務狀態。GC之後就清楚自身上的事務資訊。