This chapter contains the requirements for the system and database resources that support Oracle GoldenGate.
This chapter contains the following topics:
Section 1.1, "Verifying Certification and System Requirements"
Section 1.6, "Supported Objects and Operations for DB2 on z/OS"
Section 1.7, "Non-Supported Objects and Operations for DB2 on z/OS"
Make sure that you are installing your product on a supported hardware or software configuration. For more information, see the certification document for your release on the Oracle Fusion Middleware Supported System Configurations page.
Oracle has tested and verified the performance of your product on all certified systems and environments; whenever new certifications occur, they are added to the proper certification document right away. New certifications can occur at any time, and for this reason the certification documents are kept outside of the documentation libraries and are available on Oracle Technology Network.
This section outlines the requirements to support Oracle GoldenGate on the local operating system.
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 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.
To support the Oracle GoldenGate edit and report commands under the TSO/E OMVS command, concatenate the following target libraries to the appropriate ISPF data definition names (ddnames):
Data set SYS1.SBPXPENU to ddname ISPPLIB
Data set SYS1.SBPXMENU to ddname ISPMLIB
Data set SYS1.SBPXTENU to ddname ISPTLIB
Data set SYS1.SBPXEXEC to ddname SYSEXEC or SYSPROC
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.
Oracle GoldenGate requires the following memory resources on the local system.
Allocate approximately 50-100 MB of virtual memory for each Oracle GoldenGate Extract process, depending upon the amount of uncommitted data per unit of work. Oracle GoldenGate stores transaction data on the source system until either a commit or rollback indicator is received. Alternately, you can use spill files to hold most of the data. You may need to monitor the usage of your z/OS page data sets that have extensive USS usage. The default size of the initial Extract memory heap might be too high for some z/OS systems, especially those running applications that primarily generate small transactions. To adjust the size, use the TRANSMEMORY parameter in the Extract parameter file.
The GGSCI program uses the International Components for Unicode (ICU) libraries and thus requires a virtual memory allocation of 48 MB.
When using TSO to access USS, give the TSO user enough memory allocation to start the Oracle GoldenGate GGSCI process. If you get the error message "CEE3536S Not enough storage was available for the WSA ," increase the TSO user memory or ask your TSO administrator to do it.
This section outlines the disk requirements needed to support Oracle GoldenGate.
Assign a zFS (zSeries file systems) or Hierarchical File System (HFS) volume. 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. For more information, see Section 2.3, "Understanding and Obtaining the Oracle GoldenGate Distribution."
To install Oracle GoldenGate into a cluster environment, install the Oracle GoldenGate binaries and files on a shared file system that is available to all cluster nodes.
DSN=[hfs dsn]
DISP=(NEW,CATLG,DELETE)
SPACE =
DCB=DSORG=PO,DSNTYPE=HFS
Automatically mount the new file at IPL with an update to the BPXPRM UNIX PARMLIB member. Make certain that the MOUNT FILESYSTEM parameter for HFS in the BPXPRM PARMLIB member is not set to NOSETUID . To mount the files:
MOUNT FILESYSTEM([hfs dsn]') TYPE(HFS) MODE(RDWR)
MOUNTPOINT('[/u/ggs]')
An additional 1 GB of disk space is required 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 for Windows and UNIX.
Oracle GoldenGate requires the following network resources.
Configure the system to use TCP/IP services, including DNS. Oracle GoldenGate supports IPv4 and IPv6 and can operate in a system that supports one or both of these protocols.
Configure the network with the host names or IP addresses of all systems that will be hosting Oracle GoldenGate processes and to which Oracle GoldenGate will be connecting. Host names are easier to use.
Oracle GoldenGate requires some unreserved and unrestricted TCP/IP ports, the number of which depends on the number and types of processes in your configuration. See Administering Oracle GoldenGate for Windows and UNIX for details on how to configure the Manager process to handle the required ports.
Keep a record of the ports that you assigned to Oracle GoldenGate. You will specify them with parameters when configuring the Manager process.
Configure your firewalls to accept connections through the Oracle GoldenGate ports.
The following additional features of the operating system must be available to support Oracle GoldenGate.
To use Oracle GoldenGate user exits, install the C/C++ Compiler, which creates the programs in the required shared object or DLL.
For best results, have the following tools on the system:
Gzip to decompress the Oracle GoldenGate installation files. Otherwise, you must unzip the installation on a PC by using a Windows-based product, and then FTP it to the z/OS machine.
RACF command processor or comparable security package. (This documentation shows recommendations and examples for RACF.)
Time Sharing Option Extensions (TSO/E) command processor, including authorized TSO/E commands.
For best results, apply HIPER maintenance on a regular basis, staying within one year of the current maintenance release, as recommended by IBM. The HIPER process identifies defects that could affect data availability or integrity. IBM provides Program Temporary Fixes (PTF) to correct defects found in DB2 and z/OS.
Table 1-1 shows the required operating system privileges for Oracle GoldenGate:
Table 1-1 Operating System Privileges
| User privilege | Manager | Extract | Replicat |
|---|---|---|---|
|
Resource Access Control Facility (RACF) account (or equivalent) with OMVS segmentFoot 1 |
X |
||
|
|
X |
X |
|
|
|
|||
|
|
X |
||
|
|
X |
X |
|
|
|
X |
X |
X |
Footnote 1 The user who starts the Manager process is typically the user by which other Oracle GoldenGate processes run.
Footnote 2 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 3 Non-data sharing only.
Footnote 4 In IBM DB2 10 for z/OS 1.2.6.
This section contains Oracle GoldenGate requirements that are specific to the DB2 database on 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');
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 1-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 1-2 Privileges Needed by Oracle GoldenGate for DB2 on z/OS
| User privilege | Extract | Replicat |
|---|---|---|
|
(does not apply to initial-load Extract) |
X |
|
|
|
X |
X |
|
|
X |
|
|
|
X |
|
|
|
X |
|
|
|
X |
|
|
Privileges required by |
X |
X |
Footnote 1 SELECT on source tables required only if tables contain LOB columns, or for an initial-load Extract, if used.
Footnote 2 Required if using ADD CHECKPOINTTABLE in GGSCI to use the database checkpoint feature.
Footnote 3 SQLEXEC enables stored procedures and queries to be executed by an Oracle GoldenGate process.
This section lists the DB2 data types that Oracle GoldenGate supports on the z/OS platform and any limitations of this support.
Oracle GoldenGatee does not perform character set conversion for columns that could contain multi-byte data. This includes GRAPHIC, VARGRAPHIC and DBCLOB data types, as well as CHAR, VARCHAR, and CLOB for tables defined with ENCODING_SCHEME of 'M' (multiple CCSID set or multiple encoding schemes) or 'U' (Unicode). Such data is only supported if the source and target systems are the same CCSID.
Oracle GoldenGate supports ASCII, EBCDIC, and Unicode data format. Oracle GoldenGate will convert between ASCII and EBCDIC data automatically. Unicode is never converted.
Oracle GoldenGate supports most DB2 data types except those listed in Section 1.5, "Non-Supported DB2 on z/OS Data Types".
The support of range and precision for floating-point numbers depends on the host machine. In general, the precision is accurate to 16 significant digits, but you should review the database documentation to determine the expected approximations. Oracle GoldenGate rounds or truncates values that exceed the supported precision.
Oracle GoldenGate does not support the filtering, column mapping, or manipulation of large objects greater than 4K in size. Full Oracle GoldenGate functionality can be used for objects that are 4K or smaller.
DECFLOAT is fully supported by Replicat. Extract does not capture DECFLOAT from the transaction log, but supports capture of it by fetching from the database.
This section lists DB2 data types that Oracle GoldenGate does not support on the z/OS platform. Data that is not supported may affect the integrity of the target data in relation to the source data.
XML
User-defined types
Negative dates
TIMESTAMP WITH TIMEZONE
This section lists the database objects and types of operations that Oracle GoldenGate supports.
Extraction and replication of DML operations on DB2 for z/OS tables that contain rows of up to 512KB in length. This size exceeds the maximum row size of DB2.
INSERT operations from the IBM LOAD utility are supported for change capture if the utility is run with LOG YES and SHRLEVEL CHANGE, and the source tables that are being loaded have DATA CAPTURE CHANGES enabled (required by Oracle GoldenGate) and are specified in the Oracle GoldenGate Extract configuration.Oracle GoldenGate also supports initial loads with the LOAD utility to instantiate target tables during initial synchronization. For more information, see Administering Oracle GoldenGate for Windows and UNIX.
Oracle GoldenGate supports the maximum number of columns per table that is supported by the database.
Oracle GoldenGate supports the maximum column size that is supported by the database.
Extraction and replication of data that is stored using DB2 data compression (CREATE TABLESPACE COMPRESS YES).
TRUNCATE TABLE is supported, but because this command issues row deletes to perform the truncate, they are shown in Oracle GoldenGate statistics as such, and not as a truncate operation. To replicate a TRUNCATE , Replicat uses a DELETE without a WHERE clause.
TRUNCATES are always captured from a DB2 for z/OS source, but can be ignored by Replicat if the IGNORETRUNCATES parameter is used in the Replicat parameter file.
Extraction or replication of DDL operations
Clone tables
Data manipulation, including compression, that is performed within user-supplied DB2 exit routines, such as:
Date and time routines
Edit routines (CREATE TABLE EDITPROC )
Validation routines (CREATE TABLE VALIDPROC )
AES encryption in Oracle GoldenGate security features
The Multi-Journal feature does not support multi-journal sync of a transaction across multiple journals.