6 Configuring Oracle GoldenGate for DB2 for i
Topics:
- What to Expect from this Procedure
- Getting Started with Oracle GoldenGate
- Creating the Oracle GoldenGate Instance
- Creating a GLOBALS File
- Creating a Data Definitions File
- Encrypting the Extract and Replicat Passwords
- Configuring Extract for Change Capture from DB2 for i
- Configuring Replicat for Change Delivery to DB2 for i
- Next Steps in the Deployment
- When to Start Replicating Transactional Changes
- Testing Your Configuration
Parent topic: Using Oracle GoldenGate for DB2 for i
What to Expect from this Procedure
These instructions show you how to configure a set of basic Oracle GoldenGate parameter (configuration) files, one for each process that replicates transactional data changes from a DB2 for i source to a DB2 for i target, or to a different database type. Your business requirements probably will require a more complex topology, but this procedure forms a basis for the rest of your configuration steps.
This chapter focuses on the basic parameters that are specific to DB2 for i.
By performing these steps, you can:
-
get the basic configuration files established.
-
build upon them later by adding more parameters as you make decisions about features or requirements that apply to your environment.
-
use copies of them to make additional parameter files faster than starting from scratch.
Parent topic: Configuring Oracle GoldenGate for DB2 for i
Getting Started with Oracle GoldenGate
Before proceeding with the configuration process, you should get familiar with the Oracle GoldenGate architecture, the command interface, and the methods for supplying input and instructions to the processes. See Administering Oracle GoldenGate for this information.
Parent topic: Configuring Oracle GoldenGate for DB2 for i
Creating the Oracle GoldenGate Instance
Each Oracle GoldenGate installation is rooted in the Manager process. This is the controller process that instantiates the Oracle GoldenGate processes, allocates port numbers, and performs file maintenance. Together, the Manager process and its child processes, and their related programs and files comprise an Oracle GoldenGate instance.
To run Oracle GoldenGate, a Manager process must be running on all systems that will be part of the Oracle GoldenGate environment. To run Manager, you first create a parameter file for it.
Parent topic: Configuring Oracle GoldenGate for DB2 for i
Creating a GLOBALS
File
The GLOBALS
parameter file contains parameters that affect all
processes within an Oracle GoldenGate instance. The GLOBALS
parameter NAMECCSID
is specific to DB2 for i and may be required if
the SQL catalog contains object names that are referenced by a different CCSID than
the system CCSID. The SQL catalog is created in the system CCSID and does not
indicate this difference when queried. Oracle GoldenGate makes queries to the
catalog and could retrieve the name incorrectly unless NAMECCSID
is
used to supply the correct CCSID value. For more information, see Reference for Oracle GoldenGate.
Parent topic: Configuring Oracle GoldenGate for DB2 for i
Creating a Data Definitions File
When replicating data from one table to another, an important consideration is whether the column structures (metadata) of the source and target tables are identical. Oracle GoldenGate looks up metadata for the following purposes:
-
On the source, to supply complete information about captured operations to the Replicat process.
-
On the target, to determine the structures of the target tables, so that the replicated data is correctly mapped and converted (if needed) by Replicat.
When source and target table definitions are dissimilar, Oracle GoldenGate must perform a conversion from one format to the other. To perform conversions, both sets of definitions must be known to Oracle GoldenGate. Oracle GoldenGate can query the local database to get one set of definitions, but it must rely on a data-definitions file to get definitions from the remote database. The data-definitions file contains information about the metadata of the data that is being replicated.
To create a definitions file, you configure and run the DEFGEN
utility and then transfer the definitions file to the target system. This file must
be in place on the target system before you start the Oracle GoldenGate processes
for the first time.
Parent topic: Configuring Oracle GoldenGate for DB2 for i
Encrypting the Extract and Replicat Passwords
It is strongly recommended that you encrypt the passwords of the user profiles that will be used for the primary and data pump Extracts, and for the Replicat process. Oracle GoldenGate must use Blowfish encryption on the DB2 for i platform. The standard Oracle GoldenGate encryption method of AES (Advanced Encryption Standard) is supported by the IBM i platform. To encrypt the password, see Working with Runtime Parameters in Administering Oracle GoldenGate. It also contains information about how to encrypt data within disk storage and across TCP/IP.
Note:
The Oracle GoldenGate credential store is not supported by the iSeries platform.
Parent topic: Configuring Oracle GoldenGate for DB2 for i
Configuring Extract for Change Capture from DB2 for i
Perform these steps on the source system to configure the primary Extract and the data pump Extract that support change capture and transport across the network.
Parent topic: Configuring Oracle GoldenGate for DB2 for i
Configuring the Primary Extract
These steps configure the primary Extract to capture transaction data from a source DB2 LUW and write the data to a local trail for temporary storage.
Parent topic: Configuring Extract for Change Capture from DB2 for i
Configuring the Data Pump
These steps configure the data pump that reads the local trail and sends the data across the network to a remote trail.
Parent topic: Configuring Extract for Change Capture from DB2 for i
Configuring Replicat for Change Delivery to DB2 for i
These steps configure Replicat to apply data to a DB2 for i target database, operating either on the target system or on a remote Windows or Linux system. To configure Replicat for change delivery to a different database type, such as an Oracle database, follow the directions in the Oracle GoldenGate Installation and Configuration guide for that database. There may be additional parameters and requirements for delivery to that database type.
Note:
There does not have to be a database on a Windows or Linux machine to support connection by ODBC by Replicat.
Parent topic: Configuring Oracle GoldenGate for DB2 for i
Creating a Checkpoint Table
Replicat maintains its checkpoints in a checkpoint table in the DB2 for i target database. Each checkpoint is written to the checkpoint table, that must be journaled, within the Replicat transaction. Because a checkpoint either succeeds or fails with the transaction, Replicat ensures that a transaction is only applied once, even if there is a failure of the process or the database.
A common method of create the checkpoint table with journaling is as follows:
For more information about creating a checkpoint table, see Administering Oracle GoldenGate.
Parent topic: Configuring Replicat for Change Delivery to DB2 for i
Configuring Replicat
These steps configure the Replicat process in a basic way without any special mapping or conversion of the data.
Parent topic: Configuring Replicat for Change Delivery to DB2 for i
Next Steps in the Deployment
Because of its flexibility, Oracle GoldenGate offers numerous features and options that must be considered before you start any processes. To further configure Oracle GoldenGate to suit your business needs, see the following:
-
For additional configuration guidelines to achieve specific replication topologies, see Administering Oracle GoldenGate. This guide also contains information about:
-
Oracle GoldenGate architecture
-
Oracle GoldenGate commands
-
Oracle GoldenGate initial load methods
-
Using customization features
-
Mapping columns that contain dissimilar data
-
Data filtering and manipulation
-
-
For syntax options and descriptions of Oracle GoldenGate GGSCI commands and Oracle GoldenGate parameters shown in this guide, see Reference for Oracle GoldenGate.
Parent topic: Configuring Oracle GoldenGate for DB2 for i
When to Start Replicating Transactional Changes
You must start replication when the source and target data is in a synchronized state, where the corresponding rows in the source and target tables contain identical data values. Unless you are starting with brand new source and target databases with no current user activity, you will need to activate change capture and apply processes to handle ongoing transactional changes while an initial load is being applied to the target. This process is known as initial synchronization, or also as instantiation. The initial load captures a point-in-time snapshot of the source data and applies it to the target, while Oracle GoldenGate maintains any changes that are made after that point.
See Instantiating Oracle GoldenGate with an Initial Load in Administering Oracle GoldenGate for instantiation options.
Parent topic: Configuring Oracle GoldenGate for DB2 for i
Starting Extract During Instantiation
When Extract starts for the first time to begin capturing data during the instantiation process, it captures all of the transaction data that it encounters after the specified start point, but none of the data that occurred before that point. To ensure that Extract does not start in the middle of ongoing transactions that would be discarded, set the tables that are to be captured to an inactive state. You can either put the system into a restricted state by using the ALCOBJ
command to lock the objects or libraries, or you can force all of the current transactions on those tables to stop at a certain point.
After initialization is complete, remember to unlock any objects that you locked. To do so, log off of the session that locked the objects or use the DLCOBJ
command from the OS/400 command line.
Parent topic: When to Start Replicating Transactional Changes
Changing the Position of Extract to a Later Time
You may at some point, over the life of an Extract run, need to set the position of
Extract in the data stream manually. To reposition Extract, use the ALTER
EXTRACT
command in GGSCI. To help you identify any given Extract read
position, the INFO EXTRACT
command shows the positions for each
journal in an Extract configuration, including the journal receiver information. See
Reference for Oracle GoldenGate to know
more.
Note:
Because the journals can have a transaction split among them, if a given journal is independently repositioned far into the past, the resulting latency from reprocessing the entries may cause the already-read journals to stall until the reading of the latent journal catches up.
Parent topic: When to Start Replicating Transactional Changes
Testing Your Configuration
It is important to test your configuration in a test environment before deploying it live on your production machines. This is especially important in an active-active or high availability configuration, where trusted source data may be touched by the replication processes. Testing enables you to find and resolve any configuration mistakes or data issues without the need to interrupt user activity for re-loads on the target or other troubleshooting activities.
Parent topic: Configuring Oracle GoldenGate for DB2 for i