PACLOG in disaster recovery

When a disaster recovery is necessary, only local site data that has already been dispatched to the recovery site can be used in the recovery.

The point in time to which applications can be recovered is determined by the end point of the most recent local site archive log taken to the recovery site. Records of transactions occurring after the last archive log were created and prior to the failure exist only in the active log and cannot be recovered from the data taken to the recovery site.

Related topic

Key-concepts

PACLOG can contribute to disaster recovery contingency planning in the following areas:

  • At the local site, PACLOG can make and catalog additional archive logs (copies 3 and 4) for use at the recovery site. Using PACLOG for this task allows you to filter and compress the logs before dispatching them to the recovery site.

    If you use BMC AMI Recovery Manager for Db2, consider using PACLOG to make processed offsite archive logs instead of using the BMC AMI Recovery Manager archive log copy program (ARMBARC) to make copies of the original (unprocessed) archive logs.

  • At the recovery site, PACLOG can restore archive log copies 3 and 4 to disk.

    If you use BMC AMI Recovery Manager, this step can be automatically included in the disaster recovery JCL. If you do not use BMC AMI Recovery Manager, you must first restore the BSDS at the recovery site and then use the CHANGE LOG INVENTORY utility to modify it so that archive log copies 3 and 4 are renamed as copies 1 and 2.

Important

If archive log copies 3 and 4 are being compressed, then the 

PACLOG

 subsystem started tasks must be started at the recovery site when the system is started.

For detailed information about the role of archive logs in disaster recovery, see the section on disaster recovery in the BMC AMI Recovery Manager for Db2 documentation.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*