Q Replication and Event Publishing

Configuring for older or remote DB2 databases

You can configure Q Replication with some older DB2® databases so that you can use the most recent replication features without upgrading your database. You can also configure Q Replication to run on a system that is remote from the source or target database. Both configurations use similar steps.

Before you begin

If you plan to use a newer version of Q Replication on the same system as an older DB2 database, see Installation scenarios for important considerations during installation.

If you plan to use a Q Capture that is a different version or release than your Q Apply, see Coexistence support in Version 10.1 or Coexistence support in Version 9.7.

About this task

The following figure shows the basic configuration for using Q Replication with an older version of DB2, in this example, WebSphere® Replication Server Version 9.5 with DB2 Version 8.2.

Figure 1. A Q Replication configuration with older DB2 databases

WebSphere Replication Server Version 9.5 configured with a Version 8.2 DB2 database.

The following figure shows the basic configuration for using remote DB2 databases.

Figure 2. A Q Replication configuration with remote DB2 databases

This figure shows Q Replication residing on a different server than the source and target DB2 databases.

Installing Q Replication does not upgrade any existing DB2 databases, even if an existing DB2 is an older version. After Q Replication is installed and licensed, the replication programs can work with any DB2 database that is at the same release or lower (down to Version 8.2), regardless of whether that database resides in another DB2 instance or on another system. A new DB2 instance is created as part of the installation, however the new DB2 instance never needs to be started and no database needs to be created in it.

When you need to replicate from a remote or down-level DB2 instance, the Q Capture version must be the same as the DB2 version and the Q Capture must be the same as or higher than the DB2 release within the version. Table 1 shows the required Q Capture levels.

Table 1. Required Q Capture level for different DB2 versions and releases
DB2 version and release	Required Q Capture level
9.1, 9.5, 9.7	The Version 9.7 level that is shipped with InfoSphere® Data Replication Version 10 or DB2 Version 9.7.
10.1	The Version 10.1 level that is shipped with InfoSphere Data Replication Version 10 or DB2 Version 10.1.

The following extra steps are required in a mixed-version or remote replication configuration:

The older or remote DB2 databases must be cataloged at the instance that contains the replication programs.
In mixed-version configurations, the replication control tables must be created to match the higher-level version of the replication programs.
In mixed-version configurations, the instance owner of the higher-level DB2 that is installed with the latest replication programs must have permission to read the DB2 logs of the older version DB2.

Restrictions

The replication administration tools will not create pre-Version 10.1 control tables on DB2 for Linux, UNIX, and Windows Version 10.1.

For Q Capture or Q Apply that are local to DB2

Replication from compressed or partitioned tables on DB2 for Linux, UNIX, and Windows is only supported for DB2 Version 9.7 or later. DB2 uncompresses log records before passing them to the Q Capture program. The data is passed uncompressed from source to target and the target does not need to have compression set.
To replicate load operations, the source database and Q Capture must be at APAR PK78558 or newer on z/OS®, or at Version 9.7 or newer on Linux, UNIX, and Windows.

For Q Capture or Q Apply that are remote from DB2

The Q Capture program, Q Apply program, and the source and target databases must be on the same Linux, UNIX, or Windows platform and must all have the same bit architecture, for example 32/32 bit or 64/64 bit.
You cannot use the replication administration tools to list or validate queues.
The endianness and code page of the system where the remote Q Capture program runs must match the endianness and code page of the source database and operating system.

Procedure

Install Q Replication and create an instance as prompted by the installer. You can install the products on the same system as an older DB2 version (down to Version 8.2) or you can install on a remote system.
Catalog the DB2 node and database that is your source or target at the newly installed instance by using the CATALOG NODE and CATALOG DATABASE commands. Open a DB2 command window from the DB2 instance that is used by replication or event publishing, and catalog the node and database of the older or remote database.
Create an asnpwd password file to be used by the replication and publishing programs.
If the source or target database is a lower version than Q Capture or Q Apply, use the ASNCLP or Replication Center to create replication control tables that match the version of the replication programs.
Use the Replication Center or ASNCLP program to create the queue maps and Q subscriptions.
If the database is to be a replication source, grant SYSADM or DBADM permission to the user ID with which the Q Capture program connects to the source. This gives the Q Capture program permission to retrieve DB2 log records.
Start Q Capture and Q Apply from the replication instance, whether it is a new version or the same version on a remote system. For example, start replication from the newly installed instance by providing the alias for the older or remote DB2 database that you specified in the CATALOG DATABASE command.

Send your feedback | Information roadmap | The Q+SQL Replication Forum

Last updated: 2013-10-25