Zero data loss disaster recovery solution (z/OS)

You can achieve a zero data loss solution for disaster recovery within metropolitan distance (up to about 125 miles) by synchronously mirroring Db2® log data to a remote site where Q Replication captures the mirrored log data by using the Db2 proxy log read function. You can use Peer to Peer Remote Copy (PPRC) to synchronously mirror the source log files in addition to the data sets that are required by Db2 for remotely reading the logs in proxy mode.

The functionality for this solution is part of IBM® Data Replication for Db2 for z/OS® Version 11.4. For details on how to enable the Q Capture program for remote log reading, refer to Enabling Q Capture to run at a Db2 log read proxy server (z/OS). Also see Handling a disaster in a proxy log read configuration.

The Q Capture control tables, except the IBMQREP_SIGNAL table, reside in the Db2 proxy instance. Q Capture requires access to the source server for certain operations. For example, when activating a new Q subscription, Q Capture retrieves the table description from the source Db2 catalogs.

Figure 1 illustrates this configuration.

If a disaster makes the source site unreachable, Q Capture must be able to finish replicating transaction logs that were already synchronously mirrored to the proxy site, without accessing the source server. To do so, Q Capture at the proxy server runs in recovery mode, continuing to replicate changes from the mirrored logs but running without functionality that requires connectivity to the source.

To set up this configuration, you create most of the Q Capture control tables at the proxy server. You need only the IBMQREP_SIGNAL table at the source Db2 server. You create an alias at the proxy server for IBMQREP_SIGNAL, and Q Capture accesses the signal table by using three-part names.

The following list describes Q Capture behavior changes when the source is unavailable.

Waiting for source database to be reachable

The Q Capture ON_REMOTE_SOURCE_UNAVAIL parameter specifies how Q Capture processes the logs when connectivity to the source is lost. If the remote database becomes unavailable, the default behavior (ON_REMOTE_SOURCE_UNAVAIL=W) is to wait for connectivity to be restored. Q Capture follows the same behavior as with term=n logic, waiting for connectivity to be restored. Note that the Q Capture term=n parameter value applies to the proxy database to which Q Capture is attached, not the source database.

Cold start

When Q Capture cold starts, it queries the source Db2 catalog for information to decode the log correctly. This information is required to ensure program correctness. Therefore, Q Capture cannot fall back to recovery mode during cold start. If ON_REMOTE_SOURCE_UNAVAIL=R is specified and the database is unavailable on cold start, Q Capture waits until connectivity is restored.

No activation of new Q subscriptions

In recovery mode, new Q subscriptions cannot be activated because access to the system catalog is required to correctly describe the table. This includes Q subscriptions in state N (new) when Q Capture starts, or CAPSTART signals read from the log.

Out-of-line LOBs

In recovery mode, large object (LOB) values cannot be sent because the source table that the LOB is fetched from is unavailable. Empty LOB values are substituted.

Handling of ADD COLUMN

While running in recovery mode, Q Capture obtains the default value for ALTER TABLE ADD COLUMN operations by decoding the log records for the SYSIBM.SYSCOLUMNS table. Replication requires DATA CAPTURE CHANGES on the Db2 catalogs so that the log records can be captured.

Signal states are not updated or pruned

If a signal is processed when running in recovery mode, the signal state is not updated to reflect the outcome of processing the signal. Signals are also not pruned until connectivity is restored.

Q Apply behavior changes

The only time that the Q Apply program interacts with a source group is during internal load of a table. In an internal load, Q Apply invokes the DSNUTILS stored procedure to load a target table over DRDA by using a SELECT statement. Q Apply already has the capabilities to specify an alternate source group, using SRC_LOCATION_ALIAS. The communication database (CDB) of the target Db2 group should be configured with the source group location name. If the source Db2 proxy is unavailable during load phase, the Q subscription is deactivated.