DBA_2PC_PENDING
Oracle會自動處理分布事務，保證分布事務的一致性，所有站點全部提交或全部回滾。一般情況下，處理過程在很短的時間內完成，根本無法察覺到。但是，如果在commit或rollback的時候，出現了連接中斷或某個數據庫站點CRASH的情況，則提交操作可能會無法繼續，此時DBA_2PC_PENDING和DBA_2PC_NEIGHBORS中會包含尚未解決的分布事務。
對於絕大多數情況，當恢復連接或CRASH的數據庫重新啟動後，會自動解決分布式事務，不需要人工干預。只有分布事務鎖住的對象急需被訪問，鎖住的回滾段阻止了其他事務的使用，網絡故障或CRASH的數據庫的恢復需要很長的時間等情況出現時，才使用人工操作的方式來維護分布式事務。
手工強制提交或回滾將失去二層提交的特性，Oracle無法繼續保證事務的一致性，事務的一致性應由手工操作者保證。
對於分布式事務，給事務命名是一個好的習慣。而且在事務執行過程中，可以使用ALTER SESSION ADVISE COMMIT(ROLLBACK);語句，為手工解決分布事務提供參考信息。
當手工解決分布事務出現了沖突，比如一個站點進行了提交而另一個進行了ROLLBACK，這時，DBA_2PC_PENDING中的記錄不會清除，必須使用DBMS_TRANSACTION.PURGE_MIXED過程來清除。
如果CRASH的數據庫必須重建，或者無法再次啟動，則DBA_2PC_PENDING中的記錄也無法自動清除，需要使用DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY過程來清除。
Oracle9i中，當使用上述兩個過程時，必須處於UNDO_MANAGEMENT＝MANUAL的模式，這個限制條件Oracle沒有寫到文檔中。一般使用9i都會使用AUTO模式（Oracle也是這樣推薦的），也就是說，想要清除DBA_2PC_PENDING中的信息，必須重起數據庫兩次，感覺這兩個過程的實際用處不大。
出現無法解決的分布式事務時，可能會鎖住分布式事務中涉及的表，由於Oracle無法確定哪些數據是提交過的，哪些是沒有提交的，無法確定查詢操作可見的結果集，因此，即使是查詢操作也無法在該表上執行。
使用ALTER SYSTEM DISABLE DISTRIBUTED RECOVERY，可以使Oracle不再自動解決分布事務，即使網絡恢復連接或者CRASH的數據庫重新啟動。ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY恢復自動解決分布事務。
為了保證數據庫之間的SCN同步，可以采用兩種方法：在查詢數據前，執行SELECT * FROM DUAL@REMOTE或者在執行查詢前提交或回滾當前事務。
