Consistency after termination or failure
If a Db2 failure occurs while Db2 acts as a coordinator, Db2 has the information to determine whether to commit or roll back after restart. However, if a Db2 failure occurs while Db2 acts as the participant, Db2 must determine after restart whether to commit or roll back units of recovery that were active at the time of the failure.
For certain units of recovery, Db2 has enough information to make the decision. For others, Db2 must get information from the coordinator after the connection is re-established.
The status of a unit of recovery after a termination or failure depends on the moment when the incident occurred. The following figure shows possible statuses.
- Status
- Description and Processing
- Inflight
- The participant or coordinator failed before finishing phase 1 (period a or b); during restart, both systems back out the updates.
- Indoubt
- The participant failed after finishing phase 1 and before starting phase 2 (period c); only the coordinator knows whether the failure happened before or after the commit (point 9). If it happened before, the participant must back out its changes; if it happened afterward, it must make its changes and commit them. After restart, the participant waits for information from the coordinator before processing this unit of recovery.
- In-commit
- The participant failed after it began its own phase 2 processing (period d); it makes committed changes.
- In-abort
- The participant or coordinator failed after a unit of recovery began to be rolled back but before the process was complete (not shown in the figure). The operational system rolls back the changes; the failed system continues to back out the changes after restart.
- postponed-abort
- If the LIMIT BACKOUT installation option is set to YES or AUTO, any backout not completed during restart is postponed. The status of the incomplete URs is changed from inflight or in-abort to postponed-abort.