Migrating to replication and publishing Version 10.1 (Linux, UNIX, Windows)

Migrating to replication and publishing Version 10.1 on Linux, UNIX, and Windows involves running SQL scripts that add new columns to existing control tables, change other control tables, and update the architecture level and compatibility information in the control tables.

On Linux, UNIX, and Windows, first you upgrade your DB2® instance to Version 10.1, and then you activate InfoSphere® Data Replication Version 10.1.3. Finally, you run SQL scripts to migrate the control tables to Version 10.1.

Migrating is a multi-step process: You run a series of scripts, each of which migrates the control tables to the next version:

From Version 9.7 Fix Pack 3 to Version 10.1
From Version 9.7 to Version 9.7 Fix Pack 3
From Version 9.5 to Version 9.7
From Version 9.1 to Version 9.5

You must migrate the control tables after the Q Capture and Q Apply servers are upgraded to Version 10.1. You can migrate the Version 10.1 Q Capture and Q Apply servers independently. Coexistence support in Version 10.1 (Linux, UNIX, Windows) describes the ability of the Version 10.1, Version 9.7, and Version 9.5 Q Replication and Event Publishing programs to work together so that you can upgrade your environment in stages.

Note: For multidirectional replication, the paired sets of Q Capture and Q Apply control tables must be migrated at the same time.

CCD target tables: After you migrate Q Replication to V10.1 Fix Pack 3, the Q Apply program fails with an ASN7707E errror message because two columns in the CCD table, IBMSNAP_INTENTSEQ and IBMSNAP_COMMITSEQ, are still 10 bytes in length although the Q Capture program sends 16-byte log sequence numbers (LSN) to store in the columns. The scripts for migrating the CCD table to the longer data lengths (asnqappluwv10.sql , asnqappluwv10fp.sql ) did not include SQL statements for migrating the column lengths in the CCD table. You can install a later fix pack or follow the instructions in this Technote.