X

Welcome to All Things Data Integration: Announcements, Insights, Best Practices, Tips & Tricks, and Trend Related...

How To Setup Oracle GoldenGate When Performing the DB2 11.1 Upgrade

After the announcement of DB2 11.1 support in Oracle GoldenGate for DB2 z/OS ,a lot of questions was received on how to setup Oracle GoldenGate when performing the DB2 11.1 upgrade. This blog provides some instructions and explanations. 

DB2 11.1 increases the log record sequence numbers from 6 bytes to 10 bytes. The log reading API changed significantly to support the new log record format.  Oracle GoldenGate provides support for DB2 11.1 with a version specific build.  In other words, starting with Oracle GoldenGate 12.1.2.1.4, two downloadable builds will be provided to support DB2 z/OS: 

  • GoldenGate for DB2 10 and earlier versions
  • GoldenGate for DB2 11
If upgrading to DB2 11.1 in a data sharing configuration and you’ll be upgrading the subsystems in the group gradually (i.e. you’ll have a mixed DB2 11.1 & DB2 v10.1/9.1 group for some period of time), we first recommend that you upgrade the existing GoldenGate being used to the GoldenGate version that you plan to use once you’ve upgraded to DB2 11.1.  At the time of writing this document, the earliest version of GoldenGate that supports DB2 11.1 is 12.1.2.1.4.  

The diagram below depicts the GoldenGate and data sharing configuration prior to upgrading the first subsystem to DB2 11.1.

Picture
Please make sure you are not using the data sharing group name i.e. ADDO in the extract connection parameter. For example if the data sharing group name is ADDO, and the subsystem SSIDs of the group are ADD1 and ADD2..., please use the SSID name instead. When you use the data sharing group name, GoldenGate will connect to any of the subsystems to access log files from all of the subsystems in the data sharing group. However, during the upgrade process, we need to make sure the GoldenGate extract is connected to a specific subsystem of the group that will not be upgraded to DB2 v11.1 initially. For example,

SOURCEDB ADD1 userid uuuuuu, password ppppppp


To quickly modify a GoldenGate extract connection to another subsystem in the data sharing group, it is common practice to use an include file to define the connection parameter.  For example, the following “extract-conn.inc” file denoted in the “INCLUDE” parameter would contain the connection parameter above:

INCLUDE extract-conn.inc

In this example, you can keep the extract connected to ADD1 while upgrading the other members of the data sharing group to DB2 11.1. Data from all members in the data sharing group will be captured by GoldenGate. 
Picture
As soon as you upgrade one member of the data sharing group to DB2 11.1, you can choose to use the new GoldenGate for DB2 z/OS 11 build and connect the extract to that subsystem and capture log records from all the other subsystems in the data sharing group as illustrated below:
Picture
The DB2 IFI allows a GoldenGate extract to access log files for all DB2 subsystems that are a part of the DB2 data sharing group no matter which LPAR these subsystems are running in.  GoldenGate can capture from all members of a data sharing group even if there are different DB2 subsystem versions.  To clarify this further:

  • GoldenGate can connect to a DB2 11.1 subsystem and successfully capture log records from DB2 10.1 subsystem(s) that are also a part of the DB2 data sharing group.
  • In like manner, GoldenGate can also connect to a DB2 10.1 subsystem and successfully capture log records from DB2 11.1 subsystem(s) that are a part of the DB2 data sharing group.

Please refer to KM 1060540.1 if you need more information about the Oracle GoldenGate support for DB2 z/OS data sharing group.

If you have further question or suggestions,  please feel free to reach me at @@jinyu512

(Thanks my colleague Mark Geisler, Richard Johnson and Greg Wood for reviewing this doc.)

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.