8 Installing with DB2 z/OS Databases

Learn about the requirements and how to install Oracle GoldenGate with a DB2 z/OS database.

Topics:

8.1 System Services

The following system services must be enabled on the host system.

  • Activate UNIX System Services (USS) in full function mode rather than in minimum mode. You can use the DB2 z/OS UNIX Configuration Wizard for this purpose. Refer to the IBM UNIX System Services Planning manual for more information. The UNIX customization includes the following:

    • Make the Language Environment run-time library (RTL) available to Oracle GoldenGate and other C programs by including it in the link list or Link Pack Area (LPA), or by adding it to the STEPLIB environment variable. RTL consists of data sets SCEERUN and SCEERUN2. If you are using STEPLIB , define the SCEERUN data sets to LLA to make loading the run-time modules faster. See the UNIX System Services Planning documentation for more information.

  • Install Recoverable Resource Manager Services (RRS) for the best performance. Depending on the attachment type, the user by which Oracle GoldenGate runs might need one of the following permissions on the DSNR resource class:

    • If using RRSAF, assign RACF ACCESS(READ) to the RRSAF resource. IBM recommends using RRSAF because it has several advantages over CAF, including support for two-phase commit, thread reuse, and control over accounting intervals.

    • If using CAF, assign RACF ACCESS(READ) to the BATCH environment. If using CAF, it is possible for Oracle GoldenGate to hold locks on the system catalog until it receives a transaction commit.

  • Oracle GoldenGate supports Sysplex data sharing.

8.2 Memory Requirements

Oracle GoldenGate requires the following memory resources on the local system.

On the remote system

The amount of memory that is required for Oracle GoldenGate depends on the amount of data being processed, the number of Oracle GoldenGate processes running, the amount of RAM available to Oracle GoldenGate, and the amount of disk space that is available to Oracle GoldenGate for storing pages of RAM temporarily on disk when the operating system needs to free up RAM (typically when a low watermark is reached). This temporary storage of RAM to disk is commonly known as swapping or paging. Depending on the platform, the term swap space can be a swap partition, a swap file, or a shared memory segment (IBM i platforms).

Modern servers have sufficient RAM combined with sufficient swap space and memory management systems to run Oracle GoldenGate. However, increasing the amount of RAM available to Oracle GoldenGate may significantly improve its performance, as well as that of the system in general.

Typical Oracle GoldenGate installations provide RAM in multiples of gigabytes to prevent excessive swapping of RAM pages to disk. The more contention there is for RAM the more swap space that is used.

Excessive swapping to disk causes performance issues for the Extract process in particular, because it must store data from each open transaction until a commit record is received. If Oracle GoldenGate runs on the same system as the database, the amount of RAM that is available becomes critical to the performance of both.

RAM and swap usage are controlled by the operating system, not the Oracle GoldenGate processes. The Oracle GoldenGate cache manager takes advantage of the memory management functions of the operating system to ensure that the Oracle GoldenGate processes work in a sustained and efficient manner. In most cases, users need not change the default Oracle GoldenGate memory management configuration.

For more information about evaluating Oracle GoldenGate memory requirements, see the CACHEMGR parameter in the Reference for Oracle GoldenGate.

On the DB2 host system

Allocate approximately 10-50 MB of virtual memory for each Oracle GoldenGate log reader, oggreadx, that is invoked depending on the size of the log buffer. There is one invocation per Extract process on the remote system. To adjust the maximum log buffer size, use the TRANLOGOPTIONS BUFSIZE parameter in the Extract parameter file.

(Only applicable if you are installing stored procedures.) When using TSO to access USS, give the TSO user enough memory allocation to start the Oracle GoldenGate GGSCI process. If the CEE3536S Not enough storage was available for the WSA error message occurs, increase the TSO user memory or ask your TSO administrator to do it.

8.3 Disk Requirements for DB2 z/OS

This section outlines the disk requirements needed to support Oracle GoldenGate on DB2 z/OS.

On the remote system

Assign the following free disk space:

  • To determine the size of the Oracle GoldenGate download file, view the Size column before downloading your selected build from Oracle Software Delivery Cloud. The value shown is the size of the files in compressed form. The size of the expanded Oracle GoldenGate installation directory will be significantly larger on disk.

  • Allow at least an additional 1 GB of disk space on any system that hosts Oracle GoldenGate trails, which are files that contain the working data. You may need more or less than this amount, because the space that is consumed by the trails depends on the volume of data that will be processed. See the guidelines for sizing trails in Administering Oracle GoldenGate.

  • By default, Oracle GoldenGate maintains data that it swaps to disk in the dirtmp sub-directory of the Oracle GoldenGate installation directory. The cache manager assumes that all of the free space on the file system is available. This directory can fill up quickly if there is a large transaction volume with large transaction sizes. To prevent I/O contention and possible disk-related Extract failures, dedicate a disk to this directory. You can assign a name and size to this directory with the CACHEDIRECTORY option of the CACHEMGR parameter. The CACHESIZE option of CACHEMGR sets a soft limit for the amount of virtual memory (cache size) that is available for caching transaction data. See Reference for Oracle GoldenGate for the default values of these options and detailed explanations, in case system adjustments need to be made.

On the DB2 host system

(Only applicable if you are installing stored procedures.) Assign a zFS (zSeries file systems) or hierarchical file system volume. To determine the size of the Oracle GoldenGate download file, examine the size of zOSPrograms.zip on the remote DB2 system after extracting the installation image.

8.4 Operating System Privileges for DB2 z/OS

The remote host requires privileges to use the chmod +rw command on the subdirectories in the Oracle GoldenGate product directory.

Table 8-1 shows the other required operating system privileges for Oracle GoldenGate:

Table 8-1 Operating System Privileges

DB2 z/OS User Privilege Extract Stored Procedures Replicat

CONNECT to the remote DB2 subsystemFoot 1

X

X

X

ACCESS(READ ) to the bootstrap data set (BSDS)

 

XFoot 2

 

ACCESS(READ) to resource BPX.FILEATTR.APF in CLASS(FACILITY)

 

X

 

ACCESS(READ) to resource BPX.JOBNAME in CLASS(FACILITY)Foot 3

X

X

X

Footnote 1

Requires access to either the CAF or the RRSAF protected access profile in the DSNR RACF resource class, depending upon the MVSATTACHTYPE value in the ODBC initialization file.

Footnote 2

Non-data sharing only.

Footnote 3

In IBM DB2 10 for z/OS 1.13 and later.

8.5 Database Configuration for DB2 z/OS

Configure the following database components to support Oracle GoldenGate.

  • Install a DB2 ODBC driver. The Oracle GoldenGate Extract and Replicat processes use ODBC (Open Database Connectivity) to connect to the DB2 subsystem. For information about ODBC, see the DB2 for z/OS ODBC Guide and Reference documentation.

  • Install and configure the DB2 ODBC dynamic load library.

  • Grant Oracle GoldenGate EXECUTE privilege on the plan that is specified in the ODBC initialization file (the default is DSNACLI).

  • You might need to insert the name of the local DB2 subsystem into the SYSIBM.LOCATIONS table, which contains the remote DB2 server locations. Use a statement similar to the following (the example uses the name DB2A).

    INSERT INTO SYSIBM.LOCATIONS (LOCATION, PORT) VALUES ('DB2A', '446');
    

8.6 Database User for Oracle GoldenGate Processes

Oracle GoldenGate requires a database user account. Create this account and assign privileges according to the following guidelines.

  • By default, the user who starts the Manager process becomes the default DB2 primary authorization ID for all of the Oracle GoldenGate processes that any users start in that Oracle GoldenGate instance. You can assign a different user to any process by means of JCL or UNIX variables.

  • To monitor Oracle GoldenGate processing accurately, do not permit other applications or processes to operate as the Oracle GoldenGate user.

  • Assign the DB2 privileges listed in Table 8-2 to the user by which Extract and Replicat will be running (default is the user who starts Manager). These are in addition to any permissions that DB2 ODBC requires. All Extract privileges apply to initial-load and log-based Extract processes, except where noted.

Table 8-2 Privileges Needed by Oracle GoldenGate for DB2 z/OS

User privilege Extract Replicat

MONITOR2

(does not apply to initial-load Extract)

X

 

SELECT ON the following SYSIBM tables:

SYSTABLES

SYSCOLUMNS

SYSTABLEPART

SYSKEYS

SYSINDEXES

SYSCOLAUTH

SYSDATABASE

SYSFOREIGNKEYS

SYSPARMS

SYSRELS

SYSROUTINES

SYSSYNONYMS

SYSTABAUTH

SYSAUXRELS

X

X

SELECT on source tablesFoot 4

X

 

INSERT, UPDATE, DELETE on target tables

 

X

CREATE TABLEFoot 5

 

X

EXECUTE on ODBC plan (default is DSNACLI)

X

 

Privileges required by SQLEXEC procedures or queries that you will be using.Foot 6

X

X

Footnote 4

SELECT on source tables required only if tables contain LOB columns, or for an initial-load Extract, if used.

Footnote 5

Required if using ADD CHECKPOINTTABLE in GGSCI to use the database checkpoint feature.

Footnote 6

SQLEXEC enables stored procedures and queries to be executed by an Oracle GoldenGate process.

8.7 Choosing an Installation Operating System

Oracle GoldenGate for DB2 for z/OS operates remotely on zLinux, AIX or Intel Linux systems. To capture data, a small component must be installed on the DB2 z/OS system that contains the DB2 instance that will allow Oracle GoldenGate to read the DB2 log data.

To install Oracle GoldenGate on a remote zLinux, AIX or Linux system, you have the following options for connecting to DB2 on the z/OS system:

  • DB2 Connect v10.5 or greater

  • IBM Data Server Driver for ODBC and CLI v10.5 or greater

  • IBM Data Server Client v10.5 or greater

  • IBM Data Server Runtime Client v10.5 or greater

Consider the following:

  • Extract uses Open Database Connectivity (ODBC) to connect to the DB2 subsystem on the z/OS system. If one of the other drivers is not already installed, the IBM Data Server Driver for ODBC and CLI is the most lightweight driver and is recommended for most configurations, although the other drivers are suitable also.

  • To capture DB2 log data, the log reader component must be installed in a Library (PDSE) on the z/OS system. Load Libraries (PDS) are not supported. The library must be authorized program facility (APF) helps your installation protect the system. APF-authorized programs can access system facility (APF) authorized. The log read component is called through SQL from the remote system and since it is APF authorized, an authorized Workload Manager (WLM) environment must also be used to run these programs since the default DB2 supplied WLM environment is not able to run authorized workload.

  • No special requirements beyond what capture already has are necessary for Oracle GoldenGate delivery. Because this Oracle GoldenGate release is a fully-remote distribution, the former Oracle GoldenGate DB2 Remote product is no longer shipped separately. However, Windows is not supported in Oracle GoldenGate for DB2 z/OS in this release. If you still require delivery to z/OS from Windows, then Oracle GoldenGate DB2 Remote 12.2 is still available.

  • UNIX System Services (USS) is no longer required (as in prior releases) except for a few installation procedures.

  • Windows only: To apply data to a DB2 target from Windows, Oracle GoldenGate DB2 Remote v12.2 must be used. Capture is not support in this scenario.

  • Install Oracle GoldenGate DB2 Remote on a remote system for remote delivery to the DB2 target system. In this configuration, Replicat connects to the target DB2 database by using the ODBC API that is supplied in DB2 Connect . This configuration requires DB2 LUW to be installed on the remote system.

    Note:

    All of the Oracle GoldenGate functionality that is supported for DB2 for z/OS is supported by DB2Connect. In addition, ASCII character data is converted to EBCDIC automatically by DB2 Connect.

  • Although it is possible to install Oracle GoldenGate on zLinux, AIX, and Intel based Linux, the best performance is seen with a system that has the lowest network latency to the z/OS system that you use. Although it is possible to run over a wide area network, the performance suffers due to the increased network latency. Oracle recommends using a zLinux partition on the same physical hardware as the z/OS system that is running DB2 using Hipersockets or a VLAN between the partitions. Otherwise, systems connected with OSA adapters in the same machine room, would be the next best choice. Alternatively, the fastest Ethernet connection between the systems that is available would be acceptable.

Using the Remote Delivery to the DB2 z/OS using DB2Connect

  1. For the intermediary system, select any platform that Oracle GoldenGate supports for the DB2 for LUW database. This is the system on which Oracle GoldenGate is installed.

  2. Install and run DB2 for LUW on the selected remote system so that the Replicat process can use the supplied DB2 Connect driver.

  3. Catalog the DB2 target node in the DB2 for LUW database on the remote system by using the following DB2 command:

    catalog tcpip node db2_node_name remote DNS_name server DB2_port-number
    
  4. Add the target DB2 database to the DB2 for LUW catalog on the intermediary system by using the following DB2 command:

    catalog db database_name as database_alias at node db_node_name 
    

See the IBM DB2 LUW documentation for more information about these commands.

8.8 Installing on DB2 z/OS

Install Oracle GoldenGate in UNIX System Services on your DB2 z/OS system, see Installing on all Platforms.

8.9 Installing Oracle GoldenGate Extract Components on DB2 z/OS

Follow these steps to install the components needed for extract Oracle GoldenGate for DB2 z/OS on a z/OS system:
The Oracle GoldenGate z/OS objects require a minimum hardware platform of z10, a minimum OS release of 1.12, and a minimum DB2 release of 10.1.
  1. A library (PDSE) must exist on the z/OS system and it must be in the authorized libraries list. This library is the location where the Oracle GoldenGate objects will reside.
  2. A WLM environment must exist and be APF authorized that references the PDSE from the preceding step. Oracle recommends that NUMTCB for the WLM environment be 10-40 for stored procedures. This depends on the maximum number of Extracts that are running concurrently against the database and on how much throughput each requires. If you want flexibility in selecting NUMTCB, you specify it in the startup JCL for the WLM, but not in the creation panel.
  3. You can set up security for the WLM application environments and for creating stored procedures by completing the following:
    1. (Optional) Specify which WLM-established address spaces can run stored procedures. If you do not complete this step, any WLM-established address space can run stored procedures.
    2. Grant access to users to create procedures in specific WLM address spaces.
    3. Grant access to users to create procedures in specific schemas. Use the GRANT statement with the CREATIN option for the appropriate schema.
    4. Grant access to users to create packages for procedures in specific collections. Use the GRANT statement with the CREATE option for the appropriate collection. 
    5. Grant access to refresh the WLM environments to the appropriate people.
  4. Ensure that the ID that is used to run the JCL startup procedure for the WLM application environment has permission to use RRSAF. Each time one of the DB2 WLM address spaces is started, it uses RRSAF to attach to DB2. See the DB2 11 for z/OS Installation and Migration Guide
  5. From the Linux or UNIX installation of Oracle GoldenGate for DB2 z/OS there is a ZIP file called zOSPrograms.zip. Copy zOSPrograms.zip in binary mode to your z/OS system into an HFS directory.
  6. On your z/OS system in USS or OMVS, change directories to the directory containing zOSPrograms.zip.
  7. Restore the zOSPrograms.tar file with the unzip zOSPrograms.zip command.
  8. Restore the objects with names with the prefixes ogg[ir]b[0-9], oggib, and oggrb in the tar -xovf zOSPrograms.tar directory.
  9. Note:

    In this command, the copy target is double-quote forward-slash forward-slash single-quote authorized PDSE name single-quote double quote. The -X is an uppercase capital X not a lowercase x.

    Copy the objects to the authorized PDSE. Use the cp –X ogg[ir][ab][0-9]* “//’authorized_PDSE_name’” where authorized_PDSE_name is the name of the APF authorized PDSE intended for the Oracle GoldenGate objects.
  10. Using your SQL tool of choice, you must create the SQL procedures so that Oracle GoldenGate can call the Extract process. The Oracle GoldenGate stored procedures should have permission granted to only those users that are used for replication.

    There is an example SQL script provided in the Oracle GoldenGate install directory that contain the SQL statements to setup the stored procedures on the DB2 for z/OS instance. The demo_db2_setupb_os390.sql script is for v11.1 and can be run from any SQL tool on any platform that can connect to your DB2 for z/OS instance. This script should be run on the v11.1 instance you are using with your Extract.

    The following two lines should be edited before running the scripts:

    • The OUT BUFFER BLOB line must be modified to be at least a large as the largest TRANLOGOPTIONS BUFSIZE value that is being used in your Extracts. Oracle does not recommended that you make the BLOB size any larger than necessary.

    • The WLM ENVIRONMENT line must be modified to use the correct name for the WLM environment that you are using.

Note:

The oggifi0001 schema name is configurable using the TRANLOGOPTIONS REMOTESCHEMA schemaname parameter. The procedure names are not configurable. The external name must match the program name of the object stored in the PDSE and remember to change the WLM environment to match the name of the WLM environment setup for the Oracle GoldenGate stored procedures.

Note:

The out buffer BLOB size should be sized so that it is not smaller than the value of TRANLOGOPTIONS BUFSIZE. You may set the size of the buffer BLOB to be equal to the TRANLOGOPTIONS BUFSIZE value to limit memory resources used on the z/OS system. The exact value of the buffer depends heavily on the workload being processed by the Extract so heavier loads may require a larger buffer to enable Extract to be able to keep up with the application.