錯誤恢復是應用程式程式設計、系統管理和運維的一個常見任務。對於部署在多個遠端伺服器上的分散式資料庫而言，發生網路和通訊故障的概率更高。為了確保資料完整性，資料庫管理員提供了兩階段提交流程。下面解釋了DBA如何處理兩階段提交過程中發生的錯誤：

階段1錯誤

如果一個數據庫說它沒有準備好提交工作單元，資料庫客戶端將在提交過程的第二階段回滾該工作單元。這種情況下將不會發送prepare訊息給事務管理器資料庫。
在第二階段，客戶端傳送一個rollbak訊息給所有參與的並且在第一階段成功準備好的資料庫。然後每個資料庫寫一個“ABORT”記錄到日誌檔案，並釋放被這個工作單元佔用的鎖。

階段2錯誤

這一階段的錯誤處理依賴於第二階段是提交還是回滾事務。如果第一階段碰到了錯誤,第二階段只會回滾事務。

如果一個參與的資料庫提交工作單元失敗（可能是由於通訊失敗），事務管理器資料庫將嘗試在提交失敗的資料庫上重新提交。如提交成功，應用程式將會被SQLCA通  知到。DB2®資料庫在Linux，Unix，Windows平臺上將確保資料庫伺服器中未提交的事務最終被提交。資料庫管理器配置引數resync_interval用於指定重新提交的時間間隔。所有的資料庫鎖都被保留，直到工作單元被成功提交。

如果事務管理器資料庫發生失敗，它在重啟的時候會重新同步這個工作單元。這個重新同步的過程會嘗試完成所有的未完成事務(indoubt transactions)；也就是，那些第一階段已經成功完成，但第二階段提交過程還沒完成的事務。重新同步執行以下的步驟：

1. 連線那些在第一階段準備好提交(PREPARED)的資料庫
2. 嘗試在那些資料庫上提交未完成事務（indoubt transactions）。(如果沒找到未完成交易，資料庫管理器假設資料庫第二階段的提交已成功完成。)
3. 當所有參與資料庫的未完成事務都被成功提交後，再在事務管理器資料庫上提交未完成事務

如果這個事務是被一個事務處理監控器(XA相容事務管理器), 資料庫將總是依賴於這個TP監控器來發起同步.

如果, 因為某些原因, 你不能等待事務管理器來自動解決未完成事務, 你可以採取一些操作來手動解決問題. 這個操作指南通常被稱為"啟發式決定"(making a heuristic decision).

在autorestart=off時的錯誤恢復

如果autorestart資料庫配置引數設定為OFF，並且在TM或RM資料庫中存在未完成的事務，那麼啟動重新同步過程需要執行RESTART DATABASE命令。當從命令列處理器執行RESTART DATABASE命令時，要使用不同的會話。如果你從同一個會話(session)重起不同的資料庫，先前呼叫建立的連線將被丟棄，必須重新啟動一次。執行TERMINATE命令後，當LIST INDOUBTTRANSACTION命令返回不再有未完成的交易時, 執行TERMINATE命令來丟棄這個連線。

by iefreer