Replication Guide and Reference

DB2 data replication components

DB2 DataPropagator consists of three main components: administration interfaces, change-capture mechanisms, and the Apply program.

You use the administration interfaces to create control tables, which store your replication criteria.
After you set up your replication environment, you use a change-capture mechanism to capture changes as they occur in the source database and store them temporarily in tables.
You use the Apply program to read the tables and apply these changes to target databases, or to copy data directly from the source database to the target databases.

This section describes the control tables that manage replication requests, the logical servers that contain the replication components, as well as the main components (administration interfaces, change-capture mechanisms, and the Apply program) and how they communicate with each other.

Control tables

The replication components use control tables to communicate with each other and to manage replication requests (such as defining and managing replication sources and targets, capturing changes, replicating changes, and tracking how many changes are replicated and how many remain to be done).

The change-capture mechanisms use the following control tables: register table, unit-of-work table, pruning control table, prune lock table, critical section table, warm start table, tuning parameters table, and change data tables.

The Apply program uses the following control tables: Apply trail table, critical section table, pruning control table, prune lock table, register table, subscription set table, subscription statements table, subscription events table, subscription-targets-member table, subscription columns table, unit-of-work table, and change data tables.

Logical servers

All the replication components reside on a logical server. In this book, logical servers refer to databases, not to servers in the client/server sense. For the OS/390 operating system, logical servers are equivalent to subsystems or data-sharing groups (that is, the domain of a single database catalog). There are three types of logical servers:

Source server: The source server contains the change-capture mechanism, the source tables that you want to replicate, and the control tables for the Capture program.
Target server: The target server contains the target tables.
Control server: The control server contains the control tables for the Apply program.

The Apply program can reside on any of the logical servers in the network. It uses distributed DB2 technology to connect to the control, source, and target servers.

Each Apply program is associated with one control server, which you specify when you start the Apply program. Multiple Apply programs can share a control server.

The control server can be located at the source server, the target server, or any database server that the Apply program can connect to. For better performance, the control server should be located at the server where the Apply program runs because the Apply program frequently reads the control tables at the control server. However, if the source server is in a secure environment, locating the control server at the source server can improve security and let you manage and monitor subscriptions centrally.

Administration interfaces

You use the administration interfaces to create control tables, which store your replication criteria. There are two user interfaces available: DB2 Control Center and DataJoiner Replication Administration (DJRA).

DB2 Control Center

The DB2 Control Center is a database administration tool that you can use to administer the replication of data between DB2 servers. It automates many initialization functions, such as creating target tables and control tables when you specify target information.

You can use the Control Center to perform the following administration tasks for replication:

Define DB2 tables and DB2 views as replication sources.
Define or remove subscription sets.
Add subscription-set members to existing subscription sets.
Remove subscription-set members from existing subscription sets.
Remove replication sources.
Clone subscription sets to other servers.
Activate and deactivate subscription sets.
Add or delete SQL statements or a call to a procedure that will run before or after data is replicated.

DataJoiner Replication Administration (DJRA)

The DataJoiner Replication Administration (DJRA) tool is a database administration tool that you can use to perform various replication administration tasks. You can use this tool for DB2-to-DB2 replication; however, you must use it if your replication environment includes non-IBM databases.

You can use DJRA to perform the following administration tasks:

Create the control tables and put them on your source, target, and control servers.
Define DB2 tables, non-IBM tables, and DB2 views as replication sources.
Alter the definitions for existing DB2 source and target tables to add new columns.
Remove replication sources.
Define or remove subscription sets.
Add subscription-set members to existing subscription sets.
Remove subscription-set members from existing subscription sets.
Add or delete SQL statements or called procedures that run before or after data is replicated.
Monitor the replication process.
Copy your replication environment to another system using the promote functions.
Load target tables off-line.

Change-capture mechanisms

The DB2 data replication solution offers these mechanisms for capturing data:

The Capture program for DB2 source tables.
Capture triggers for source tables in non-IBM databases, except Microsoft Access and Microsoft Jet.

The following sections describe the Capture program and triggers. For more information about how changes are replicated in Microsoft Access and Microsoft Jet databases, see Mobile replication using DB2 DataPropagator for Microsoft Jet.

Capture Program

When the source is a DB2 table, the Capture program is used to capture changes that are made to the source. The Capture program uses the database log ⁴ to capture changes made to the source database and enqueues them temporarily.

The Capture program runs at the source server. Typically it runs continuously, but you can stop it while running utilities or modifying replication sources.

Tasks that you can perform with the Capture program include:

Starting the Capture program
Scheduling the Capture program
Stopping the Capture program
Suspending the Capture program temporarily
Resuming the Capture program
Reinitializing the Capture program
Pruning the tables that temporarily store change data

See Operations for instructions about performing these tasks.

Capture triggers

When the source table is in a non-IBM database (other than Microsoft Access and Microsoft Jet), Capture triggers are used to capture committed changes made to the source. Capture triggers are fired when a particular database event (UPDATE, INSERT, DELETE) occurs.

DJRA automatically creates the Capture triggers. These triggers capture the changes made to defined replication source tables and store them temporarily in tables.

Apply program

The Apply program reads data directly from source tables or views to initially populate the target table. If you want changes captured, the Apply program reads the changed data that was previously captured and stored temporarily in staging tables, and applies the changes to target tables.

The Apply program generally runs at the target server, but it can run at any server in your network that can connect to the source, control, and target servers. Several Apply program instances can run on the same or different servers. Each Apply program can run using the same authorization, different authorization, or as part of a group of Apply programs where each Apply program in the group runs using the same authorization (user ID).

Tasks that you can perform with the Apply program include:

Starting the Apply program
Running exit routines (such as ASNLOAD to call an IBM or a vendor utility)
Scheduling the Apply program
Stopping the Apply program

See Administration for instructions about performing these tasks.

How the replication components communicate

The replication components are independent of each other, so they rely on information that is stored in control tables to communicate with each other. The Capture and Apply programs update control tables to indicate the progress of replication and to coordinate the processing of changes.

The replication components communicate differently depending on whether the source server is a DB2 server or a non-IBM server. For replication between DB2 servers, the Capture program captures changes that are made to data in replication source tables by reading the server log or journal. Then the Capture program places the changes into change data (CD) tables. For non-IBM sources, Capture triggers capture changes and store them in consistent-change-data (CCD) tables.

Each time that the Apply program copies data to the target database, the contents of the target database reflect the changes that were made to the source database. The Apply program works by applying updates accumulated since the Apply program last ran. The Apply program keeps track of the latest update that it makes to each target.

Log-based communication

The Capture program uses some of the control tables to indicate what changes have been made to the source database, and the Apply program uses these control tables to detect what needs to be copied to the target database.

Important: The Capture program will not capture any information until the Apply program signals it to do so, and the Apply program will not signal the Capture program to start capturing changes until you define a replication source and associated subscription sets. See Performing the initial replication for more information about the steps you must perform so that the components communicate with each other and replicate changes.

The following steps describe how the Apply and Capture programs communicate in a typical replication scenario to ensure data integrity:

Capturing data from a source database

The Capture program reads the register table to determine the replication sources for which it needs to start capturing changes. If new replication sources are defined while the Capture program is running, they won't be recognized by the Capture program until you run the reinit command, or until you stop and restart the Capture program.
The Capture program monitors the DB2 log or journal to detect change records from source tables that are defined as replication sources.
The Capture program adds one row (or two rows if updates are saved as DELETE and INSERT operations) to the change data (CD) table for each change that it finds in the DB2 log or journal. Each replication source has a CD table.
The Capture program stores information about committed transactions in the unit-of-work (UOW) table. The rows in this control table identify the transactions that have been committed in the replication source server. With log-based change capture, there is one UOW table for every DB2 source server.
The Capture program updates the register table to record how much committed data was captured for each replication source.
Applying data to a target database
When the Apply program is started, it checks to see if any subscription set is due for replication. If so, the Apply program checks the register table to determine whether there are changes that need to be replicated.
Before the Apply program can copy the changes to the target database, it synchronizes the target with the replication source by copying all the data from the source table to the target table. This action is called a full-refresh copy. After the full-refresh copy, the Capture program begins capturing changes at the source.
The Apply program updates the pruning control table to synchronize the capture of the related source table changes in the CD table.
The Apply program copies the changes from the join of the CD table and the UOW table to the target table. By joining the two control tables, the Apply program ensures that it copies only the changes that were committed at the replication source.
Pruning the control tables
The Apply program updates the pruning control table with a value that indicates the point to which it copied changes to the target database.
When the Capture program prunes the CD and UOW control tables, it determines which changes were applied and deletes them from the CD table and the UOW table.

Trigger-based communication

DJRA, working through DB2 DataJoiner, creates Capture triggers at the non-IBM source table when you define the table as a replication source. Three types of triggers are created on the source table: DELETE, UPDATE, and INSERT. Also, UPDATE triggers are created on the pruning control table and the register synchronization table. The Apply program uses these control tables to detect what needs to be copied to the target database.

The following steps describe how the Capture triggers and the Apply program communicate in a typical replication scenario to ensure data integrity:

Capturing data from a source

Whenever a DELETE, UPDATE, or INSERT operation occurs at the source table that is defined as a replication source, a Capture trigger records the change in the consistent-change-data (CCD) table.
Applying data to a target
When the Apply program is started, the UPDATE trigger on the register synchronization table updates the register table to record how much committed data has been captured.
The Apply program gets the source table information from the register table.
Before the Apply program can copy the changes to the target, it synchronizes the target with the replication source by copying all the data from the source table to the target table. This action is called a full-refresh copy.
The Apply program updates the pruning control table to synchronize the capture of the related changes in the CCD table.
The Apply program reads the CCD table using DB2 DataJoiner nicknames, copies the changes to the target server, and applies the changes to the target table.
Pruning the control tables
The Apply program updates pruning control table with a value that indicates the point to which it copied changes to the target database.
The UPDATE trigger on the pruning control table checks all of the CCD tables that are at the source server and deletes those entries that were replicated.

Footnotes:

⁴: The Capture program retrieves changed and committed information from the active and archive logs on DB2 for MVS 4.1 or higher and DB2 Universal Database. Capture for VSE and VM 5.1 can read only the active log on DB2 for VSE & VM.

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]

[ DB2 List of Books | Search the DB2 Books ]