IBM Support

Sample - Updating Netezza with Data from Q Replication

General Page

IBM Data Replication (IDR) has a Q Replication function called event publishing (EP). EP publishes Db2 changed data in a well-known format such as comma-separated values. This gives applications an alternative way to consume changed data. This post provides an example of how changed data can be moved from queues to files and then loaded into Netezza.

Moving Db2 changed data to Netezza

While the most common way to move Db2 changed data to Netezza is using the CDC Replication Engine for Netezza Technology, you can use Q Replication event publishing to move this data as well. Q Replication event publishing (EP) is a lesser-known feature of the IBM Data Replication (IDR) product that publishes Db2 changed data to queues and then to files which are then loaded into Netezza.

The Event Publishing Format

EP captures data from the DB2 transaction log and writes it to a Websphere MQ queue. It supports 2 formats:

  • A delimited format where transaction information - table row, column values, etc. - is separated by delimiters, most often commas.
  • An XML format where transaction information is enclosed in self-described tags in an XML document.

Sample Event Consumer to Update Netezza

A general sample event consumer is available at  Sample - Moving DB2 Changed Data from Q Replication to Files. The sample event consumer available here expands on the original sample event consumer program and uses the Db2 changed data from files to update Netezza. It is a Java application that consumes EP messages that are published in a delimited format and uses JDBC (Java Database Connectivity) to update a Netezza database. 

Final Note on Event Consumers

Queues are not the only way of publishing data. It can also be published to tables.

For example, CCD, or Consistent Change Data, tables hold changed data in a format easily consumed by applications through SQL. A popular use-case is the multi-tier distribution scenario where tier-1 is the production system, tier-2 is a mid-tier consolidation server with CCD tables populated with tier-1 changed data (no Capture process is running on tier-2) and tier-3 servers are regional servers where Apply processes pull the appropriate changed data from tier-2 CCD tables.

Event publishing combined with specialized event consumers delivers simple solutions for integration scenarios.

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSTRGZ","label":"InfoSphere Data Replication"},"Component":"","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF012","label":"IBM i"},{"code":"PF016","label":"Linux"},{"code":"PF051","label":"Linux on IBM Z Systems"},{"code":"PF033","label":"Windows"}],"Version":"All Versions","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
07 April 2020

UID

ibm11105185

Page Feedback