Plans for recovery of distributed data

In a distributed data environment, each unit of work is processed as a whole at the target system, regardless of where a unit of work originates. Therefore, a unit of work is recovered as a whole at the target system.

At a Db2 server, the entire unit is either committed or rolled back. It is not processed if it violates referential constraints that are defined within the target system. Whatever changes it makes to data are logged. A set of related table spaces can be quiesced at the same point in the log, and image copies can be made of them simultaneously. If that is done, and if the log is intact, any data can be recovered after a failure and be internally consistent.

However, Db2 provides no special means to coordinate recovery between different subsystems even if an application accesses data in several systems. To guarantee consistency of data between systems, applications should be written so that all related updates are done within one unit of work.

Point-in-time recovery (to the last image copy or to a relative byte address (RBA)) presents other challenges. You cannot control a utility in one subsystem from another subsystem. In practice, you cannot quiesce two sets of table spaces, or make image copies of them, in two different subsystems at exactly the same instant. Neither can you recover them to exactly the same instant, because two different logs are involved, and a RBA does not mean the same thing for both of them.

In planning, the best approach is to consider carefully what the QUIESCE, COPY, and RECOVER utilities do for you, and then plan not to place data that must be closely coordinated on separate subsystems. After that, recovery planning is a matter of agreement among database administrators at separate locations.

Db2 is responsible for recovering Db2 data only; it does not recover non-Db2 data. Non-Db2 systems do not always provide equivalent recovery capabilities.