Q Replication and Event Publishing migration
To migrate a Q Replication or Event Publishing server to Version 10, the control tables at the server must first be at the Version 9.7 level.
The following topics provide detailed information about migrating from Version 9.7 to Version 10, from Version 9.5 to Version 9.7, and from Version 9.1 to Version 9.5.
- Migrating to Q Replication Version 11.1 (Linux, UNIX, Windows)
When you upgrade your source or target servers to DB2® Version 11.1 on Linux, UNIX, and Windows the control tables must be at architecture level 1021. You must migrate the control tables if they are not at this level. - Migrating to Q Replication ARCH_LEVEL 1021 on Linux, UNIX, and Windows
Migrating to Q Replication and Event Publishing ARCH_LEVEL 1021 on Linux, UNIX, and Windows requires you to upgrade to DB2 for Linux, UNIX, and Windows Version 10.5 Fix Pack 7 and then run SQL scripts that update the control tables. - Migrating to Version 10.2.1 with ARCH_LEVEL 1021 (z/OS)
When you install the Q Replication technology in InfoSphere® Data Replication for DB2 for z/OS® Version 10.2.1, you must migrate the Q Capture control tables to the 1021 architecture level to match the Q Capture code base and the Q Apply control tables to the 1021 architecture level to match the Q Apply code base. - Migrating to Version 10.1 with ARCH_LEVEL 1001 (z/OS)
When you install APAR PM75119 for Q Replication Version 10.1 on z/OS, you must migrate the control tables to the 1001 architecture level to match the code base. - Migrating to Version 10.5 (Linux, UNIX, Windows)
Q Replication and Event Publishing Version 10.5 on Linux, UNIX, and Windows does not require a control table migration from Version 10.1. - 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. - Coexistence support in Version 10
The Q Capture and Q Apply programs support interoperability between many of their versions, but some coexistence scenarios are not supported. - Migrating to replication and publishing Version 10.1 (z/OS)
Migration of the Q Capture or Q Apply control tables is required after you install InfoSphere Replication Server for z/OS, 10.1 or InfoSphere Data Event Publisher for z/OS, 10.1. - Coexistence support in Version 10.1 (z/OS) and Version 9.7 Fix Pack 3 (Linux, UNIX, Windows)
The Q Capture and Q Apply programs support full interoperability between Version 10.1 on z/OS, Version 9.7 Fix Pack 3 on Linux, UNIX, and Windows, Version 9.7, Version 9.5, and Version 9.1. - Migrating different replication and publishing environments to Version 10.1 (z/OS) and Version 9.7 Fix Pack 3 (Linux, UNIX, Windows)
The steps that are required to migrate to Version 10.1 (z/OS) and Version 9.7 Fix Pack 3 (Linux, UNIX, Windows) differ for unidirectional replication, bidirectional or peer-to-peer replication, and event publishing. - Optional: Migrating to replication and publishing Version 9.7 Fix Pack 5 (Linux, UNIX, Windows)
The optional migration to Version 9.7 Fix Pack 5 on Linux, UNIX, and Windows adds new indexes on two control tables to help improve performance. - Migrating to replication and publishing Version 9.7 Fix Pack 3 or 3a (Linux, UNIX, Windows)
Migrating your control tables to Version 9.7 Fix Pack 3 or 3a is required on Linux, UNIX, and Windows after you upgrade your DB2 instance to Version 9.7 Fix Pack 3 or 3a. - Migrating to replication and publishing Version 9.7 Fix Pack 2 (Linux, UNIX, Windows)
Migrating to replication and publishing Version 9.7 Fix Pack 2 involves running SQL scripts that add a new control table, add new columns to existing control tables, and change nickname column options for some federated targets. - Migrating to replication and publishing Version 9.7
Migrating to replication and publishing Version 9.7 from Version 9.5, or Version 9.1 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.