This post is the answer to one of the FAQs found in License Tips for IBM Data Replication.
You may have seen a recent announcement on ibm.com
that says IBM would no longer be marketing it's older data replication products in 2013. That includes InfoSphere CDC. Why?
And what happens to the CDC technology?
Over the years, IBM provided its data replication technologies
through a lot of different products. For example, IBM used to offer two major
data replication products at the same time -
InfoSphere CDC and InfoSphere Replication Server. That was a little
even to some IBM people. To simplify the situation, IBM consolidated all it's replication technologies into a single product called IBM InfoSphere Data Replication
(IIDR). Once IIDR was available, the older products no longer needed to be sold to new customers. That's why the end of marketing was announced. However, the replication technologies - CDC, Q Replication, and SQL Replication - are still alive and well. You can
continue to use them as you always
have. Of course, you may have two related questions:
- Are the older products still being supported?
- How do you move from your old InfoSphere CDC product to IIDR?
If you have any questions, feel free to post them in the comments section of this blog.
If you're looking for an excellent way to replicate changed data from a wide range of databases into a Netezza appliance, you can do so through InfoSphere Data Replication
. The latest release provides an Apply program that is both native to Netezza and optimized for Netezza targets. This Apply is built from Data Replication's CDC technology and is also compatible with the CDC technology found in InfoSphere Change Data Capture and InfoSphere Classic Change Data Capture for z/OS
. This means you can replicate data to Netezza from source databases ranging from Oracle, DB2, and others on UNIX or Windows to DB2* and IMS on the mainframe. Ordering information can be found in the Data Replication announcement letter on ibm.com
* Data Replication's CDC Apply program cannot be used to feed changed data to the IBM DB2 Analytics Accelerator (IDAA).
In response to: Best Practice - Target Considerations
Regarding Oracle triggers on the target tables, would these fire
during a standard refresh? We want them to fire off during normal
continuous replication from DB2 to Oracle..
Most are triggers on insert so I am concerned during the refresh
which we do whenever we change the table structure to match the
The following items need to be considered and taken into account when you are planning a replication architecture.
§Target table triggers
–Often if the target is a mirror image of the source, you may have triggers on target tables that if fired will have an affect on other tables that InfoSphere CDC is replicating into (CDC would have mirrored the source trigger effect and will get duplicate actions). To alleviate this, you should disable the trigger on the target table.
§Referential integrity constraints with DELETE CASCADE flag on target tables
–Similar to trigger, having cascade deletes set on the target will cause replication to try and delete a record (based on the delete that CDC would have replicated from the source log) that the database may have already deleted (or visa-versa). The following strategy can be deployed to deal with cascaded deletes:
Disable the RI constraints on target prior to starting replication
Please note that re-enabling these constraints may take some time during cut-over if you need to fail over to the target
Strategy: test how long re-enabling the RI constraints takes. If re-enabling all RI constraints takes too long and would impact your RTO (Recovery Time Objective), investigate whether it is possible to leave the RI constraints enabled and just change the CASCADE DELETE flag at cut-over time.
In 2011, IBM released three new data replication products:
One question that comes up is whether the two IMS replication products are compatible with either the new Data Replication product or the existing InfoSphere CDC products. The answer is yes - the IMS products are compatible with both new and existing products that contain the CDC technology. IMore specifically, they can provide IMS changed data to any data replication solution that you can build with IBM's CDC technology. For example, you can create unidirectional (one-way) subscriptions that feed IMS changed data to any database that can be targeted by CDC:
Two notes about this picture:
- IBM recommends you use the CDC technology in IIDR if you do not own InfoSphere CDC.
- The target DB2 can be DB2 for z/OS, DB2 LUW, or DB2 for System i.
You could also feed IMS changed data into other business software such as ETL, IBM's DataStage, and ESBs:
In other words, the new IMS data replication products extend the reach of IBM's CDC technology by adding IMS as a source for log-based capture of changed data. If you have technical questions, see the Classic CDC section of the Information Center
Modified on by Glenn Steffler
IIDR 184.108.40.206-44 for all engines can be found on Fix Central.
IIDR 220.127.116.11-44 for DB2 LUW
* Modify Purescale transaction ordering logic from VTS based ordering to one based on LFS and LSN.
Note: Deployments of IIDR for DB2 LUW on PureScale should avoid DDL changes during the upgrade steps. Otherwise this will require completing the DDL procedure prior to upgrading to this version of IIDR CDC for DB2 LUW.
IIDR 18.104.22.168-44 for Event Server
JR56064 WHEN REFRESHING/MIRRORING DATA TO A EVENT SERVER MQ TARGET, THE XML MESSAGE DATA SHOULD CONTAIN A TAG FOR THE TABLE NAME.
IIDR 22.214.171.124-44 for Netezza
JR55991 NETEZZA: ERROR RETURNED WHEN MAPPING A TABLE IN A MULTI-SCHEMA DATABASE.
IIDR 126.96.36.199-44 for Oracle
JR56199 UNABLE TO INSERT DELETE OPERATION ON TARGET ORACLE AUDIT TABLE( INVALID PARM BINDING), WHEN LOB DATATYPE IS USED.
JR56205 "CURRENT TIMESTAMP" & "CONSTANTS" ARE NOT BEING POPULATED IN AUDIT MAPPING TYPE FOR THE 'CLRPFM' AND 'STRJRNPF' COMMANDS.
JR56265 UPDATES ARE NOT GETTING REPLICATED PROPERLY FOR PARTITION COMPRESSED TABLE
IIDR 188.8.131.52-44 for Sybase
JR56044 SYBASE DB LOGS ERROR WHEN DMGETSUBSCRIPTIONSTATUS IS EXECUTED
Modified on by Glenn Steffler
for all engines
* Installer updates to address security vulnerability on Windows, see security bulletin http://www-01.ibm.com/support/docview.wss?uid=swg21984310
JR55891 JOURNAL CONTROL FIELDS ARE NOT BEING CORRECTLY POPULATED IN A LIVE AUDIT MAPPING FOR THE 'CLRPFM' AND 'STRJRNPF' COMMANDS.
IIDR 184.108.40.206-43 for DB2 LUW
* Now supports DB2 v11.1
IIDR / CDC 220.127.116.11 platform support matrix:
IIDR 18.104.22.168-42 for all engines can be found on Fix Central.
JR55791 REFRESH TABLES USING JOURNAL CONTROL FIELD @CNTRRN FAILS WHEN CDC FOR DB2 FOR IBM I IS SOURCE
IIDR 22.214.171.124-42 for Oracle
JR55951 ORACLE MERGE STATEMENT HANDLING WHEN A MERGE INCLUDES UPDATE WITH DELETE
IIDR 126.96.36.199-40 for all engines can be found on Fix Central.
JR55889 FILE HANDLE LEAK WHEN REPLICATING CLOB DATA THAT IS READ FROM DB AND REQUIRES ENCODING CONVERSION.
Modified on by GlenSakuth
There are many deployment models available for InfoSphere Data Replication's CDC technology of which DataStage integration is a popular one. The deployment option selected will significantly affect the complexity, performance, and reliability of the implementation. If possible, the best solution is always to use CDC direct replication (i.e. do not add DataStage to the mix).
CDC integration with DataStage is the right solution for replication when:
- You need to target a database that CDC doesn't directly support and is not appropriate for CDC FlexRep
- Complex transformations are required that could not be handled natively with CDC, such as complex table look-ups
- When integrating with MDM
Cons of replicating from CDC to DataStage to an eventual target database:
- Performance going through DataStage (no matter which integration option is chosen) will be significantly slower than applying via a CDC target directly to the database
- The exception to this rule is when targeting Teradata, if you use DataStage flatfile integration, the throughput will be higher than CDC direct to Teradata
- Adding DataStage into the replication stream introduces additional points of failure
- Having a resilient CDC installation is more complex if DataStage is also involved
- When integrating with DataStage, there are two independent GUIs for configuration, and two places required to monitor the replication stream
- There is significant development effort developing DataStage jobs for each additional table added to replication
- Incorrect DataStage job design can negatively affect transactional integrity and cause data corruption
- The maximum number of tables per CDC subscription is lower if targeting DataStage
- The CDC External Refresh does not work when targeting DataStage. A separate process would have to be put in place to de-dup duplicate records produced during the "in-doubt" period of a refresh (the captured changes that occurred while the source date was being refreshed).
IIDR 188.8.131.52-39 for all engines can be found on Fix Central.
JR55631 UPDATE FAILURE WHEN "MINIMIZE NETWORK LOAD" ENABLED
JR55714 EXPLICIT ENCODING CONVERSION DOESN'T WORK WITH CDC FOR DB2 FOR IBM I
JR55795 DIFFERENTIAL REFRESH FAILS WITH 'NO ROWS WERE FOUND'
IIDR 184.108.40.206-39 for Event Server
JR55517 INCORRECT VALUES IN EVENT MESSAGE FOR RECORDS RECEIVED AND APPLIED AT THE END OF REFRESH
Management Console and Access Server 220.127.116.11-5398
* Added the ability to export Access Server audit logs from CHCCLP
* Improved handling to prevent assigning a user to multiple datastores where the datastores point to the same host and port.
JR55743 UNKNOWN ERROR THROWN WHEN GETTING LOG EVENTS FOR CORRUPTED DMCAUDITLOG FILE
Modified on by MikeJory
IIDR 18.104.22.168-36 for Oracle
JR55509 UPDATES ARE NOT GETTING REPLICATED PROPERLY IN CASE OF PARTITION COMPRESSED TABLE.
JR55216 COMMAND DMMARKTABLECAPTUREPOINT WORKS ONLY FOR ONE SUBSCRIPTION
IIDR 22.214.171.124-32 for DataStage
* Improved socket exception handling for Hadoop
IIDR 126.96.36.199-32 for DB2 LUW
JR55525 REPLICATION OF A TABLE FAILS FROM ISERIES TO IIDR 188.8.131.52 DB2 LUW WHEN TABLE CONTAINS OVERRIDDEN COLUMNS
IIDR 184.108.40.206-32 for Oracle
JR55286 ADAPTIVE APPLY MAPPING OF CDC RESULTS IN ADDITIONAL UPDATE OPERATIONS WHEN REPLICATION KEYS ARE SET TO AUTO-DETECT
IIDR 220.127.116.11-32 for Sybase
JR55497 NUMERIC OVERFLOW ERROR WHILE CREATING SUBSCRIPTION WHEN USING SYBASE SDK 16.0.
IIDR 18.104.22.168-32 for Teradata
JR55550 REFRESH FAILS WHEN TABLE MAPPING INCLUDES TIME(0) COLUMN
IIDR for DB2/i 11.3.3 Interim Fix 8 can be found on Fix Central
* Provides a method to override the apply job's code page.