Q Replication and Event Publishing

Preparing to create Q subscriptions and publications

Before you can create Q subscriptions and publications that specify the tables that you want to replicate or publish from, you need to create and configure your servers, ensure that they can connect to each other, and create control tables.

Required: Setting DATA CAPTURE CHANGES on DB2 source tables and DB2 for z/OS system tables
You must set the DATA CAPTURE CHANGES attribute on any DB2 table that you want to replicate. Also, on DB2® for z/OS® Version 9 and later, you must set DATA CAPTURE CHANGES on the SYSIBM.SYSTABLES, SYSIBM.SYSCOLUMNS, and SYSIBM.SYSTABLEPART system catalog tables.
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.
Configuring for GDPS active/active continuous availability (z/OS)
Q Replication is used by GDPS® active/active continuous availability for data synchronization. Q Replication supports the Network Management Interface (NMI) for monitoring the replication environment from IBM® Tivoli® NetView® Monitoring for GDPS. The NMI provides equivalent monitoring information to what is available in the Q Replication monitor tables, but with a socket interface.
Cataloging the DB2 Administration Server for the Replication Center
When you catalog an instance of the DB2 Administration Server (DAS) as a local node for another DB2 for Linux, UNIX, and Windows instance on which the Replication Center is installed, you must specify the SYSTEM parameter or use the CATALOG TCPIP NODE command.
Using parallel send queues (z/OS)
You can specify that the Q Capture program use multiple send queues, each with its own transmission queue, to send transactions to a single receive queue on the Q Apply server. This configuration is referred to as using parallel send queues.
Authorization requirements
The user IDs that run the Q replication and event publishing programs need authority to connect to servers, access or update tables, and perform other operations.
Setting up WebSphere MQ for Q Replication and Event Publishing
Q Replication and Event Publishing use WebSphere® MQ, formerly known as MQ Series, to transmit transactional data and exchange other messages.
Creating control tables for the Q Capture and Q Apply programs
Before you can publish or replicate data, you must create control tables for a Q Capture program, a Q Apply program, or both. Control tables store information about Q subscriptions and publications, message queues, operational parameters, and user preferences.
Creating control tables at a different version (Linux, UNIX, Windows)
You can use a version of replication or publishing that is newer than your DB2 version. To do so, you must create the replication control tables to match the version of replication and publishing instead of the version of DB2. For example, if you plan to use replication Version 9.7 with a DB2 Version 9.5 database, your control tables must be at Version 9.7.
Configuring databases for Q Replication and Event Publishing (Linux, UNIX, Windows)
Before you can replicate data, you must set environment variables and configure the source and target databases. For event publishing, you need to configure only the source database.
Data type considerations
When you replicate or publish certain data types, such as LONG VARCHAR or LOB data types, you should be aware of certain conditions and restrictions.
Data conversion for Q Replication and Event Publishing
In Q Replication and Event Publishing, data passes between various servers and programs, and sometimes the data must be converted between different code pages.
Naming rules and guidelines for Q Replication and Event Publishing—Overview
When you create objects for Q Replication and Event Publishing, you must observe certain restrictions for the types of characters and length of each object's name.
Working with scripts and commands generated by the replication administration tools
The ASNCLP command-line program and Replication Center generate SQL scripts for defining and changing replication objects. The Replication Center also generates operational commands for such tasks as starting and stopping the replication programs, pruning control tables, changing parameters, or checking program status.

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

Last updated: 2013-10-25