Asynchronous Replication of DB2 UDB for z/OS


Asynchronous replication of data is designed for those sites that:

·        Need to maintain the highest levels of performance on their primary system

·        Need to support extended distances between primary and standby system

·        Can accept a gap of a few seconds between writes on the primary system and the subsequent write updates on the standby system

The SAP system on DB2 UDB for z/OS supports asynchronous data replication with DB2 tracker.


A DB2 tracker site is a separate DB2 subsystem or data sharing group that exists solely for the purpose of keeping shadow copies of your primary site's data. No independent work can be run in the DB2 subsystem on the standby site. For example, you cannot update the catalog and directory or the data at the standby site. The standby site is also called the "tracker site."

To copy the data between primary site and standby site, Extended Remote Copy (XRC) is used. XRC is a remote asynchronous copy facility with minimal performance impact on most applications during normal operation. XRC automatically sends copies of updated data to the standby system. To maintain high performance at the primary location, XRC lets the I/O operation on the primary database server signal completion before receiving confirmation of the write on the standby system's database server. Since this secondary copy is normally only seconds behind the primary write, there is usually little or no data loss if a system failure occurs when data is "in transit" between the two locations.

You can operate a read-only database server on the standby site. The standby site disallows update commands like INSERT or DROP but allows read-only SELECT statements.


·        To set up the standby site:


                            a.      Create a mirror image of your primary DB2 subsystem or data sharing group.

                            b.      Set the subsystem parameter TRKSITE to YES on the standby site.

                            c.      Send full offline image copies of all DB2 data of the primary site to the standby site.

·        To establish a recover cycle at the standby site:

When the standby site has full image copies of all data at the primary site, the BSDSs and the archive logs are copied from the primary site to the standby site. A LOGONLY recovery runs periodically on the standby site to keep the shadow data up-to-date.

If the tablespace or partition is reorganized, loaded, or repaired with the  LOG(NO) option, send a full image copy of any objects to the standby site.

·        If a disaster occurs at the primary site such that the primary database server fails:

The standby site becomes the takeover site. Since the standby site has been shadowing the activity on the primary site, DB2 recovery does not have to use image copies, so the time to switch over is usually minimal.

When the primary site resumes operation, you can then switch back to the primary system.