Resolving remote DBMS indoubt units of recovery

When communicating with a remote DBMS, indoubt units of recovery can result from failure with either the participant or coordinator. Failure also can result with the communication link between the participant and coordinator, even if the systems themselves have not failed.

About this task

Normally, if your subsystem fails while communicating with a remote system, you should wait until both systems and their communication link become operational. Your system then automatically recovers its indoubt units of recovery and continues normal operation. When Db2 restarts while any unit of recovery is indoubt, the data that is required for that unit of recovery remains locked until the unit of recovery is resolved.

If automatic recovery is not possible, Db2 alerts you to any indoubt units of recovery that you need to resolve. If releasing locked resources and bypassing the normal recovery process is imperative, you can resolve indoubt situations manually.

Important: In a manual recovery situation, you must determine whether the coordinator decided to commit or abort and ensure that the same decision is made at the participant. In the recovery process, Db2 attempts to automatically resynchronize with its participants. If you decide incorrectly what the recovery action of the coordinator is, data is inconsistent at the coordinator and participant.

Procedure

To resolve units of recovery manually, you must use the following approaches:

  • Commit changes that were made by logical units of work that were committed by the other system.
  • Roll back changes that were made by logical units of work that were rolled back by the other system.