4 Installing Oracle GoldenGate for DB2 for i Databases

Learn how to install Oracle GoldenGate for DB2 for i databases.

Oracle GoldenGate for DB2 for i runs directly on a DB2 for i source system to capture data from the transaction journals for replication to a target system. To apply data to a target DB2 for i, Oracle GoldenGate can run directly on the DB2 for i target system or on a remote Windows or Linux system. If installed on a remote system, Replicat delivers the data by means of an ODBC connection, and no Oracle GoldenGate software is installed on the DB2 for i target.

Note:

The DB2 for i platform uses one or more journals to keep a record of transaction change data. For consistency of terminology in the supporting administrative and reference Oracle GoldenGate documentation, the terms log or transaction log may be used interchangeably with the term journal where the use of the term journal is not explicitly required.

Topics:

Disk Requirements

This section outlines the disk requirements for Oracle GoldenGate.

  • 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 sufficient disk space for virtual memory. The default set by the Oracle GoldenGate cache manager is 64 GB on 64-bit systems. See Memory Requirements for additional information about memory management.

  • 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.

Memory Requirements

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 main storage (RAM, or physical memory) available to Oracle GoldenGate, and the amount of auxiliary storage (disk space, available as shared memory segments) that is available to Oracle GoldenGate for caching transaction data that exceeds available physical memory.

The amount of main storage that is used by Oracle GoldenGate is 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.

On the DB2 for i platform, to provide enough shared memory segments to the Oracle GoldenGate cache manager, the recommended setting for the PASE_MAXSHR64 environment variable is a value of 513 (128GB) or higher. If you use the DB2 for i native Oracle GoldenGate commands, PASE_MAXSHR64 is set to provide 128GB of shared memory segments to the cache manager automatically. If not using the DB2 for i native commands, you can set this environment variable before starting the DB2 for i PASE session. For more information about evaluating Oracle GoldenGate memory requirements, see the CACHEMGR parameter in Reference for Oracle GoldenGate.

Note:

If PASE_MAXSHR64 is not set, you may encounter a warning message stating that the virtual memory is less than the recommended amount. Unless you have very large long-running transactions or a very large number of concurrent transactions, you may ignore this message.

Oracle GoldenGate Security Privileges

This section outlines the security privileges that Oracle GoldenGate requires on a source DB2 for i system and on a Windows or Linux target system.

Oracle GoldenGate Security Privileges

The person who installs Oracle GoldenGate must have read and write privileges on the Oracle GoldenGate installation directory, because steps will be performed to create some sub-folders and run some programs. On a Windows systen, the person who installs Oracle GoldenGate must log in as Administrator.

Manager, Replicat, and Collector (program name is server) are active. Manager controls the other processes and interacts with Collector to receive incoming data, while Replicat applies data to the target DB2 for i database through ODBC.

Oracle GoldenGate processes must be assigned a user account that is dedicated to Oracle GoldenGate and cannot be used by any other program. One user account can be used by all of the Oracle GoldenGate processes. This account must have privileges to read, write, and delete files and directories within the Oracle GoldenGate installation directory.

If the Extract user profile does not have the required authority, Extract will log the following errors and stop.

[SC=-1224:SQL1224N A database agent could not be started to service a request, or was terminated as a result of a database system shutdown or a force command.SQL STATE 55032: The CONNECT statement is invalid, because the database manager was stopped after this application was started]

The user profile must be specified with the USERID parameter when you configure the parameter files and in the DBLOGIN command prior to issuing any GGSCI commands that interact with the database.

Oracle GoldenGate Security Privileges on a DB2 for i Source System

The person who installs Oracle GoldenGate must have read and write privileges on the Oracle GoldenGate installation directory, because steps will be performed to create some sub-folders and run some programs. This person also must have authority to the RSTOBJ command, plus the ability to create a library if desired. For ease of installation, it is recommended that the user installing the product has *ALLOBJ authority

On an DB2 for i source system, the Manager and Extract processes are active. The DEFGEN utility also may be active if you are replicating data to a dissimilar target system. On an DB2 for i target system, the Replicat process is active unless you install Replicat on a remote Windows or Linux system. All processes run on both systems in a bidirectional configuration.

The Oracle GoldenGate processes must be assigned a user profile account that is dedicated to Oracle GoldenGate and cannot be used by any other program. One user profile can be used by all of the Oracle GoldenGate processes. This profile need only be granted permission to the objects that Oracle GoldenGate will be operating upon. If specific change data is not to be seen by Oracle GoldenGate, do not include it in any of the journals that the Oracle GoldenGate user profile is allowed to access. All Oracle GoldenGate processes must have privileges to read, write, and delete files and directories within the Oracle GoldenGate installation directory.

The Manager process must have privileges to control all other Oracle GoldenGate processes (DB2 for i *JOBCTL authority).

Assign *USE authority to all objects on the system that the Extract user profile must have access to. Assign *CHANGE authority to all objects on the system that the Replicat user profile must have access to. This can be accomplished by either granting *ALLOBJ authority to the user, or by setting the individual authority to the objects (FILE, LIBRARY and JOURNAL objects) that the user must access. This includes the objects in the QSYS2 library where the SQL catalog resides. These authorities must be granted through the native DB2 for i interface through a 5250 terminal session or through the DB2 for i Operations Navigator product available from IBM.

The Extract and Replicat database user profiles must be specified with the USERID parameter when you configure the parameter files and in the DBLOGIN command prior to issuing any GGSCI commands that interact with the database.

General Requirements

  • Portable Application Solution Environment (PASE) must be installed on the system.

  • OpenSSH is recommended to be installed on the system. OpenSSH is part of the IBM Portable Utilities licensed program and allows SSH terminal access to the system in the same manner as other Linux system.

  • The IBM DB2 for i Program temporary fixes (PTFs) that are required by release for Oracle GoldenGate are detailed in the following tables:

    IBM i6.1 Group PTF Level Name Notes

    SF99610

    13058

    Cumulative PTF

    Other required PTF: 5761SS1, SI51061

    Check with command: DSPPTF LICPGM(5761SS1) SELECT(SI51061)

    SF99601

    30

    DB2 for i

    .

    SF99609

    153

    Group HIPER

    .

    SF99354

    15

    TCP/IP

    .

    SF99562

    24

    JAVA

    Java agent requires product 5761JV1 option 12 (Java SE 6 64-bit)

    IBM i7.1 Group PTF Level Name Notes

    SF99710

    15142

    Cumulative PTF

    Other required PTF: 5770SS1, SI51060

    Check with command: DSPPTF LICPGM(5770SS1) SELECT(SI51060)

    SF99707 11 Technology refresh

    .

    SF99701

    26

    DB2 for i

    .

    SF99709

    99

    Group HIPER

    .

    SF99367

    7

    TCP/IP

    .

    SF99572

    12

    JAVA

    Java agent requires product 5761JV1 option 12 (Java SE 6 64-bit)

    IBM i7.2 Group PTF Level Name Notes

    SF99720

    16127

    Cumulative PTF

    Other required PTF: 5761SS1, SI51061Check with command: DSPPTF LICPGM(5761SS1) SELECT(SI51061)

    SF99717

    4

    Technology refresh

    .

    SF99702

    12

    DB2 for i

    .

    SF99719 67 Group HIPER

    .

    SF99767

    2

    TCP/IP

    .

    SF99716

    9

    JAVA

    Java agent requires product 5761JV1 option 12 (Java SE 6 64-bit)

    These required PTFs are the levels at which Oracle GoldenGate has been tested against for the 12c releases. In order to check the group PTF levels, you must use the WRKPTFGRP command from a 5250 terminal session and check for the specific PTFs with the commands shown in the preceding tables. The specific extra PTFs must be at least temporarily applied.

Installing for DB2 for i

Follow these steps to install Oracle GoldenGate for a DB2 for i system.

Note:

The user profile running the install must have authority to the RSTOBJ command.

  1. On the system where Oracle GoldenGate is to be installed, create a directory for Oracle GoldenGate.
    - MKDIR DIR('/GoldenGate')
    
  2. You can create a library for Oracle GoldenGate on the installation system, or you can create it through the installation script that you will run later in these steps.
    - CRTLIB LIB(goldengate) TEXT('Oracle GoldenGate Product Library') ASP(1)
  3. Unzip the downloaded file on your system.
  4. FTP the resulting tar file from that system to the folder that you created on the DB2 for i installation system.
    ftp IBMi_IP_address 
    .
    User (system:(none)):userid 
    . 
    331 Enter password. 
    . Password: password . 
    230 userid logged on. . 
    ftp> bin 
    . 
    ftp> cd goldengate 
    . 
    ftp> put install_file 
    . 
    ftp> quit 
    
  5. (If you created a library) From a 5250 terminal session, change your current library to the Oracle GoldenGate library.
    CHGCURLIB Oracle_GoldenGate_ library
  6. Run a QP2TERM terminal session.
    - CALL QP2TERM
    
  7. Extract the installation objects from the tar file.
    tar -xf tar_file 
    
  8. In the Oracle GoldenGate directory, run the shell script ggos400install.
    ggos400install -l goldengate

    The default is to install the required objects into the current library (set in the preceding steps), but you can create a library by using the -c option. Additional options are available.

    Note:

    There must be a separate Oracle GoldenGate library for each Oracle GoldenGate directory. The install script checks for this condition and will prevent installation to the same library that another installation is using. The reason for this is to prevent mismatches between the Oracle GoldenGate installation and the OGGPRCJRN *SRVPGM object.

    Syntax:

    ./ggos400install [-h] [-f] [-u userid] [[-a aspname] | [-n aspnum]] [-c|-l library name]
     

    Options:

    • -h shows this usage help.

    • -f forces a change to a new installation library. This argument only affects an existing installation.

    • -u userid specifies the userid that will own the installation.

    • -a aspname specifies the name of the ASP where objects will be restored. If no aspname is provided, the system asp is assumed. This option cannot be used with -n.

    • -n aspnum specifies the number of the user asp where the objects will be restored. This option cannot be used with -a.

    • -c library specifies the name of the library where the objects will be restored. The library will be created.

    • -l library specifies the name of the library where the objects will be restored. The library must exist. If a library is not specified for a new installation, the installer will attempt to use the current library of the user that is running the installer. If a library is not specified for an existing installation, the installer will attempt to use the library that is set in the oggprcjrn.srvpgm link.

    Note:

    If Oracle GoldenGate is reinstalled, you must run ggos400install again. On a reinstall, ggos400install will recognize the prior configuration, so no arguments are needed. If the oggprcjrn.srvpgm link is changed or removed, ggos400install must be run again with the Oracle GoldenGate installation library specified by the link.

  9. Exit QP2TERM.
    - F3

    Note:

    On an DB2 for i system, it is not necessary to create any working directories in the Oracle GoldenGate installation directory. The ggos400install script performs this task.

  10. Install Oracle GoldenGate on the DB2 for i database server, see Installing for all Platforms.