Oracle® Fusion MiddlewareInstalling and Configuring Oracle GoldenGatefor DB2 LUW

12c (12.2.0.1)E66358-02November 2017

Oracle Fusion Middleware Installing and Configuring Oracle GoldenGate for DB2 LUW, 12c (12.2.0.1)

E66358-02

Copyright © 2013, 2017, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing restrictions onuse and disclosure and are protected by intellectual property laws. Except as expressly permitted in yourlicense agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify,license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means.Reverse engineering, disassembly, or decompilation of this software, unless required by law forinteroperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. Ifyou find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it onbehalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software,any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are"commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of theprograms, including any operating system, integrated software, any programs installed on the hardware,and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications.It is not developed or intended for use in any inherently dangerous applications, including applications thatmay create a risk of personal injury. If you use this software or hardware in dangerous applications, then youshall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure itssafe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of thissoftware or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks oftheir respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks areused under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron,the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced MicroDevices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products,and services from third parties. Oracle Corporation and its affiliates are not responsible for and expresslydisclaim all warranties of any kind with respect to third-party content, products, and services unless otherwiseset forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not beresponsible for any loss, costs, or damages incurred due to your access to or use of third-party content,products, or services, except as set forth in an applicable agreement between you and Oracle.

Contents

Preface

Audience vi

Documentation Accessibility vi

Related Information vi

Conventions vii

1 System Requirements and Preinstallation Instructions

1.1 Verifying Certification and System Requirements 1-1

1.2 Operating System Requirements 1-1

1.2.1 Memory Requirements 1-1

1.2.2 Disk Requirements 1-2

1.2.3 Network 1-2

1.2.4 Operating System Privileges 1-3

1.2.5 Console 1-3

1.2.6 Other Programs 1-4

1.3 Database Requirements 1-4

1.3.1 Database Configuration 1-4

1.3.2 Database User for Oracle GoldenGate Processes 1-4

1.4 Supported DB2 LUW Data Types 1-5

1.5 Non-Supported DB2 LUW Data Types 1-6

1.6 Supported Objects and Operations for DB2 LUW 1-6

1.7 Non-Supported Objects and Operations for DB2 LUW 1-7

1.8 Supported Object Names 1-8

2 Installing Oracle GoldenGate

2.1 Installation Overview 2-1

2.2 Choosing an Installation System for DB2 2-1

2.2.1 Choosing and Configuring a System for Remote Capture or Delivery 2-2

2.3 Understanding and Obtaining the Oracle GoldenGate Distribution 2-3

2.4 Setting Library Paths for Dynamic Builds on UNIX 2-3

2.5 Preparing to Install Oracle GoldenGate within a Cluster 2-4

iii

2.5.1 Deciding Where to Install Oracle GoldenGate Binaries and Files in theCluster 2-4

2.6 Installing Oracle GoldenGate on Linux and UNIX 2-5

2.6.1 Installing the Oracle GoldenGate Files 2-5

2.7 Installing Oracle GoldenGate on Windows 2-5

2.7.1 Installing Oracle GoldenGate into a Windows Cluster 2-6

2.7.2 Installing the Oracle GoldenGate Files 2-6

2.7.3 Specifying a Custom Manager Name 2-6

2.7.4 Installing Manager as a Windows Service 2-7

2.8 Integrating Oracle GoldenGate into a Cluster 2-8

2.8.1 General Requirements in a Cluster 2-8

2.8.2 Adding Oracle GoldenGate as a Windows Cluster Resource 2-9

3 Preparing the System for Oracle GoldenGate

3.1 Configuring the Transaction Logs for Oracle GoldenGate 3-1

3.1.1 Retaining the Transaction Logs 3-1

3.1.2 Specifying the Archive Path 3-2

3.2 Preparing Tables for Processing 3-2

3.2.1 Disabling Triggers and Cascade Constraints 3-2

3.2.2 Assigning Row Identifiers 3-3

3.2.2.1 How Oracle GoldenGate Determines the Kind of Row Identifier toUse 3-3

3.2.2.2 Using KEYCOLS to Specify a Custom Key 3-3

3.2.3 Preventing Key Changes 3-3

3.2.4 Enabling Change Capture 3-4

3.2.5 Maintaining Materialized Query Tables 3-4

3.3 Setting the Session Character Set 3-5

3.4 Preparing for Initial Extraction 3-5

3.5 Specifying the DB2 LUW Database in Parameter Files 3-6

4 Configuring Oracle GoldenGate for DB2 LUW

4.1 What to Expect from these Instructions 4-1

4.2 Where to Get More Information 4-1

4.3 Configuring the Primary Extract 4-2

4.4 Configuring the Data Pump Extract 4-3

4.5 Configuring Replicat 4-4

4.5.1 Creating a Temporal Table 4-4

4.5.1.1 Support for Temporal Tables 4-5

4.5.1.2 Replicating with Temporal Tables 4-5

4.5.1.3 Converting 4-6

iv

4.5.2 Creating a Checkpoint Table 4-10

4.5.3 Configuring the Replicat Parameter File 4-10

4.6 Next Steps in the Deployment 4-11

4.7 When to Start Replicating Transactional Changes 4-12

4.8 Testing Your Configuration 4-12

5 Uninstalling Oracle GoldenGate

5.1 Stopping Processes 5-1

5.2 Removing the Oracle GoldenGate Database Setup 5-1

5.3 Removing Oracle GoldenGate Windows Components 5-2

5.4 Manually Removing the Oracle GoldenGate Files 5-3

A Oracle GoldenGate Installed Components

A.1 Oracle GoldenGate Programs and Utilities A-1

A.2 Oracle GoldenGate Subdirectories A-2

A.3 Other Oracle GoldenGate Files A-4

A.4 Oracle GoldenGate Checkpoint Table A-8

Index

v

Preface

With the Oracle GoldenGate for DB2 LUW databases, you can replicate data to andfrom supported DB2 LUW versions or between a DB2 LUW database and a databaseof another type. Oracle GoldenGate for DB2 LUW supports data filtering, mapping,and transformation unless noted otherwise in this documentation.

This documentation is meant to be a step by step guide in establishing a basic OracleGoldenGate configuration that is tailored to the DB2 LUW environment. It should befollowed in a linear fashion so that you benefit from important information in previoussections. It is not meant to be used as a reference document. Where needed, it pointsyou to other documentation where you can find additional information to expand theconfiguration to suit your needs.

AudienceThis guide is intended for installers, database administrators, and systemadministrators who are installing, configuring and running Oracle GoldenGate.

Documentation AccessibilityFor information about Oracle's commitment to accessibility, visit the OracleAccessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Accessible Access to Oracle Support

Oracle customers who have purchased support have access to electronic supportthrough My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Related InformationThe Oracle GoldenGate Product Documentation Libraries are found at

Oracle GoldenGate

Oracle GoldenGate Application Adapters

Oracle GoldenGate for Big Data

Oracle GoldenGate Plug-in for EMCC

Oracle GoldenGate Monitor

Oracle GoldenGate for HP NonStop (Guardian)

Preface

vi

Oracle GoldenGate Veridata

Oracle GoldenGate Studio

Additional Oracle GoldenGate information, including best practices, articles, andsolutions, is found at:

Oracle GoldenGate A-Team Chronicles

ConventionsThe following text conventions are used in this document:

Convention Meaning

boldface Boldface type indicates graphical user interface elements associatedwith an action, such as "From the File menu, select Save." Boldfacealso is used for terms defined in text or in the glossary.

italicitalic

Italic type indicates placeholder variables for which you supplyparticular values, such as in the parameter statement: TABLEtable_name. Italic type also is used for book titles and emphasis.

monospace

MONOSPACE

Monospace type indicates code components such as user exits andscripts; the names of files and database objects; URL paths; and inputand output text that appears on the screen. Uppercase monospacetype is generally used to represent the names of Oracle GoldenGateparameters, commands, and user-configurable functions, as well asSQL commands and keywords.

UPPERCASE Uppercase in the regular text font indicates the name of a utility unlessthe name is intended to be a specific case.

{ } Braces within syntax enclose a set of options that are separated bypipe symbols, one of which must be selected, for example: {option1 |option2 | option3}.

[ ] Brackets within syntax indicate an optional element. For example in thissyntax, the SAVE clause is optional: CLEANUP REPLICAT group_name [,SAVE count]. Multiple options within an optional element are separatedby a pipe symbol, for example: [option1 | option2].

Preface

vii

1System Requirements and PreinstallationInstructions

This chapter contains the requirements for the system and database resources thatsupport Oracle GoldenGate.This chapter includes the following sections:

• Verifying Certification and System Requirements

• Operating System Requirements

• Database Requirements

• Supported DB2 LUW Data Types

• Non-Supported DB2 LUW Data Types

• Supported Objects and Operations for DB2 LUW

• Non-Supported Objects and Operations for DB2 LUW

• Supported Object Names

1.1 Verifying Certification and System RequirementsMake sure that you are installing your product on a supported hardware or softwareconfiguration. For more information, see the certification document for your release onthe Oracle Fusion Middleware Supported System Configurations page.

Oracle has tested and verified the performance of your product on all certified systemsand environments; whenever new certifications occur, they are added to the propercertification document right away. New certifications can occur at any time, and for thisreason the certification documents are kept outside of the documentation libraries andare available on Oracle Technology Network.

1.2 Operating System RequirementsThis section describes operating system requirements.

1.2.1 Memory RequirementsThe amount of memory that is required for Oracle GoldenGate depends on the amountof data being processed, the number of Oracle GoldenGate processes running, theamount of RAM available to Oracle GoldenGate, and the amount of disk space that isavailable to Oracle GoldenGate for storing pages of RAM temporarily on disk when theoperating 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(herein referred to as swapping). Depending on the platform, the term swap space canbe a swap partition, a swap file, a page file (Windows) or a shared memory segment(IBM i platforms).

1-1

Modern servers have sufficient RAM combined with sufficient swap space andmemory management systems to run Oracle GoldenGate. However, increasing theamount of RAM available to Oracle GoldenGate may significantly improve itsperformance, as well as that of the system in general.

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

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

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

For more information about evaluating Oracle GoldenGate memory requirements, seethe CACHEMGR parameter in Reference for Oracle GoldenGate for Windows and UNIX.

1.2.2 Disk RequirementsAssign the following free disk space:

• To determine the size of the Oracle GoldenGate download file, view the Sizecolumn before downloading your selected build from Oracle Software DeliveryCloud. The value shown is the size of the files in compressed form. The size of theexpanded Oracle GoldenGate installation directory will be significantly larger ondisk.

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

• By default, Oracle GoldenGate maintains data that it swaps to disk in the dirtmpsub-directory of the Oracle GoldenGate installation directory. The cache managerassumes that all of the free space on the file system is available. This directorycan 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 adisk to this directory. You can assign a name and size to this directory with theCACHEDIRECTORY option of the CACHEMGR parameter. The CACHESIZE option of CACHEMGRsets a soft limit for the amount of virtual memory (cache size) that is available forcaching transaction data. See Reference for Oracle GoldenGate for Windows andUNIX for the default values of these options and detailed explanations, in casesystem adjustments need to be made.

1.2.3 NetworkThe following network resources must be available to support Oracle GoldenGate.

Chapter 1Operating System Requirements

1-2

• Configure the system to use TCP/IP services, including DNS. Oracle GoldenGatesupports IPv4 and IPv6 and can operate in a system that supports one or both ofthese protocols.

• Configure the network with the host names or IP addresses of all systems that willbe hosting Oracle GoldenGate processes and to which Oracle GoldenGate will beconnecting. Host names are easier to use.

• Oracle GoldenGate requires some unreserved and unrestricted TCP/IP ports, thenumber of which depends on the number and types of processes in yourconfiguration. See the Administering Oracle GoldenGate for Windows and UNIXfor 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 willspecify them with parameters when configuring the Manager process.

• Configure your firewalls to accept connections through the Oracle GoldenGateports.

1.2.4 Operating System PrivilegesThe following are the privileges in the operating system that are required to installOracle GoldenGate and to run the processes.

• To install on Windows, the person who installs Oracle GoldenGate must log in asAdministrator.

• To install on Windows, the person who installs Oracle GoldenGate must log in asAdministrator.

• To install on UNIX, the person who installs Oracle GoldenGate must have readand write privileges on the Oracle GoldenGate installation directory.

• The Oracle GoldenGate Extract, Replicat, and Manager processes must operateas an operating system user that has privileges to read, write, and delete files andsubdirectories in the Oracle GoldenGate directory. In addition, the Managerprocess requires privileges to control the other Oracle GoldenGate processes.

• Dedicate the Extract, Replicat, and Manager operating system users to OracleGoldenGate.

1.2.5 ConsoleThe operating system and the command console must have the same character sets.Mismatches occur on Microsoft Windows systems, where the operating system is setto one character set, but the DOS command prompt uses a different, older DOScharacter set. Oracle GoldenGate uses the character set of the operating system tosend information to GGSCI command output; therefore a non-matching consolecharacter set causes characters not to display correctly. You can set the character setof the console before opening a GGSCI session by using the following DOScommand:

chcp character_set

If the characters do not display correctly after setting the code page, try changing theconsole font to Lucida Console, which has an extended character set.

Chapter 1Operating System Requirements

1-3

1.2.6 Other ProgramsThe following are additional considerations in support of Oracle GoldenGate.

• Before installing Oracle GoldenGate on a Windows system, install and configurethe Microsoft Visual C ++ 2010 SP1 Redistributable Package. Make certain it isthe SP1 version of this package, and make certain to get the correct bit version foryour server. This package installs runtime components of Visual C++ Libraries.For more information, and to download this package, go to http://www.microsoft.com.

• Oracle has not certified any of its products on VMware virtualized environments.Oracle Support will assist customers running Oracle products on VMware in thefollowing manner: Oracle will only provide support for issues that either are knownto occur on the native OS, or can be demonstrated not to be as a result of runningon VMware.

1.3 Database RequirementsThis section describes database requirements.

1.3.1 Database Configuration• The Oracle GoldenGate Extract process calls the DB2READLOG function in the

Administrative API to read the transaction log files of a DB2 LUW sourcedatabase. In addition to DB2READLOG, Extract uses a small number of other APIroutines to check the source database configuration on startup.

• The Oracle GoldenGate Replicat process uses the DB2 CLI interface on a DB2LUW target database. For instructions on installing this interface, see the DB2documentation.

• The database can reside on a different server from the one where OracleGoldenGate is installed, so long as the database is defined locally. For example,the following enables you to use database mydb locally with data that is on abc123:

catalog tcpip node abc123 remote abc123.us.mycompany.com server 00000catalog db mydb as abc123 at node abc123 AUTHENTICATION server

1.3.2 Database User for Oracle GoldenGate Processes• Create a database user that is dedicated to Oracle GoldenGate. It can be the

same user for all of the Oracle GoldenGate processes that must connect to adatabase:

– Extract (source database)

– Replicat (target database)

– DEFGEN (source or target database)

• To preserve the security of your data, and to monitor Oracle GoldenGateprocessing accurately, do not permit other users, applications, or processes to logon as, or operate as, the Oracle GoldenGate database user. It is recommendedthat you store the login credentials in an Oracle GoldenGate credential store. Thecredential store makes use of local secure storage for the login names and

Chapter 1Database Requirements

1-4

passwords, and permits you to specify only an alias in the Oracle GoldenGateparameter files. For more information about this option, as well as alternativesecurity options, see Administering Oracle GoldenGate for Windows and UNIX.

• Assign system administrator (SYSADM) or database administrator (DBADM) authority tothe database user under which Extract runs. To give the Extract user DBADMauthority, a user with SYSADM authority can issue the following grant statement.

GRANT DBADM ON DATABASE TO USER user

This authority can also be granted from the User and Group Objects folder in theDB2 Control Center. The database tab for the user that is assigned to an OracleGoldenGate process should have the Database Administrative Authority boxchecked.

Note:

If the Extract user does not have the required authority, Extract will log thefollowing 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]

• Grant at least the following privileges to the database user under which Replicatruns:

– Local CONNECT to the target database

– SELECT on the system catalog views

– SELECT, INSERT, UPDATE, and DELETE on the target tables

1.4 Supported DB2 LUW Data TypesOracle GoldenGate supports all DB2 LUW data types, except those listed in Non-Supported DB2 LUW Data Types.

Limitations of Support

• Oracle GoldenGate supports multi-byte character data types and multi-byte datastored in character columns. Multi-byte data is only supported in a like-to-likeconfiguration. Transformation, filtering, and other types of manipulation are notsupported for multi-byte character data.

• BLOB and CLOB columns must have a LOGGED clause in their definitions.

• GRAPHIC and VARGRAPHIC columns must be in a database where the character set isUTF16. Any other character set causes the Oracle GoldenGate to abend.

• The support of range and precision for floating-point numbers depends on the hostmachine. In general, the precision is accurate to 16 significant digits, but youshould review the database documentation to determine the expectedapproximations. Oracle GoldenGate rounds or truncates values that exceed thesupported precision.

Chapter 1Supported DB2 LUW Data Types

1-5

• Extract fully supports the capture and apply of TIMESTAMP(0) through TIMESTAMP(9).Extract also captures TIMESTAMP(7) through TIMESTAMP(12), but it truncates the datato nanoseconds (maximum of nine digits of fractional time) and issues a warningto the error log. Replicat truncates timestamp data from other sources tonanoseconds when applying it to TIMESTAMP(7) through TIMESTAMP(12) in a DB2LUW target.

• Oracle GoldenGate supports timestamp data from 0001/01/03:00:00:00 to9999/12/31:23:59:59. If a timestamp is converted from GMT to local time, theselimits also apply to the resulting timestamp. Depending on the timezone,conversion may add or subtract hours, which can cause the timestamp to exceedthe lower or upper supported limit.

• Oracle GoldenGate does not support the filtering, column mapping, ormanipulation of large objects that are larger than 4K. Full Oracle GoldenGatefunctionality can be used for objects that are 4K or smaller.

• Replication of XML columns between source and target databases with the samecharacter set is supported. If the source and target database character sets aredifferent, then XML replication may fail with a database error because somecharacters may not be recognized (or valid) in the target database character set.

1.5 Non-Supported DB2 LUW Data Types• XMLType

• DECFLOAT

• User-defined types

• Negative dates

1.6 Supported Objects and Operations for DB2 LUW• Oracle GoldenGate supports the maximum number of columns and column size

per table that is supported by the database.

• TRUNCATE TABLE for DB2 LUW version 9.7 and later.

• Multi Dimensional Clustered Tables (MDC) for DB2 LUW 9.5 and later.

• Materialized Query Tables. Oracle GoldenGate does not replicate the MQT itself,but only the base tables. The target database automatically maintains the contentof the MQT based on the changes that are applied to the base tables by Replicat.

• Tables with ROW COMPRESSION. In DB2 LUW version 10.1 and later, COMPRESS YESSTATIC is supported and COMPRESS YES ADAPTIVE are supported. To support COMPRESSYES in DB2 LUW versions 9.7 and earlier, the TRANLOGOPTIONS parameter with theALLOWTABLECOMPRESSION option must be used, and the compressed table cannotcontain LOBs.

• Extended row size feature is enabled by default. It is supported with a workaroundusing FETCHCOLS. For any column values that are VARCHAR or VARGRAPHIC data typesand are stored out of row in the database, you must fetch these extended rows byspecifying these columns using the FETCHCOLS option in the TABLE parameter in theextract parameter file. With this option set, when the column values are out of rowthen Oracle GoldenGate will fetch its value. If the value is out of and FETCHCOLS isnot specified then Extract will abend to prevent any data loss. If you do not want touse this feature, set the extended_row_size parameter to DISABLE.

Chapter 1Non-Supported DB2 LUW Data Types

1-6

• Temporal tables with DB2 LUW 10.1 FixPack 2 and greater are supported. This isthe default for Replicat.

• Limitations on Automatic Heartbeat Table support are as follows:

– Oracle GoldenGate heartbeat parameters frequency and purge frequency areaccepted in seconds and days. However, the DB2 LUW task scheduleraccepts its schedule only in cron format so the Oracle GoldenGate input valueto cron format may result in some loss of accuracy. For example:

ADD HEARTBEATTABLE, FREQUENCY 150, PURGE_FREQUENCY 20

This example sets the FREQUENCY to 150 seconds, which is converted to theclosest minute value of 2 minutes, so the heartbeat table is updated every 120seconds instead of every 150 seconds. Setting PURGE_FREQUENCY to 20 meansthat the history table is purged at midnight on every 20th day.

– The following are steps are necessary for the heartbeat scheduled tasks torun:

1. Set the DB2_ATS_ENABLE registry variable to db2set DB2_ATS_ENABLE=YES.

2. Create the SYSTOOLSPACE tablespace if it does not already exist:

CREATE TABLESPACE SYSTOOLSPACE IN IBMCATGROUP MANAGED BY AUTOMATIC STORAGE EXTENTSIZE 4

3. Ensure instance owner has Database administration authority (DBADM):

GRANT DBADM ON DATABASE TO instance_owner_name

1.7 Non-Supported Objects and Operations for DB2 LUW• Schema, table or column names that have trailing spaces.

• Multiple instances of a database

• Datalinks

• Extraction or replication of DDL (data definition language) operations

• Generated columns (GENERATE ALWAYS clause).

• Row size support. This feature is enabled by default in DB2 LUW 10.5 and later,but must be disabled to support Oracle GoldenGate.

• Tables with VALUE COMPRESSION

Note:

To include tables with non-supported types of table compression in the OracleGoldenGate configuration, deactivate the non-supported compression andthen reorganize the tables; otherwise, exclude them from the OracleGoldenGate configuration.

Chapter 1Non-Supported Objects and Operations for DB2 LUW

1-7

1.8 Supported Object NamesFor a list of characters that are supported in object names, see Administering OracleGoldenGate for Windows and UNIX.

Chapter 1Supported Object Names

1-8

2Installing Oracle GoldenGate

This chapter describes how to install Oracle GoldenGate and contains the followingsections:These instructions are for installing Oracle GoldenGate for the first time. Additionally,they are for downloading the base release of a new version of Oracle GoldenGate.

To download and install subsequent patches to the base release, go to the Patchesand Updates tab of My Oracle Support at:

http://support.oracle.com

To upgrade Oracle GoldenGate from one version to another, follow the upgradeinstructions in Upgrading Oracle GoldenGate for Windows and UNIX.

Topics:

2.1 Installation OverviewThese instructions are for installing Oracle GoldenGate for the first time. Additionally,they are for downloading the base release of a new version of Oracle GoldenGate.

To download and install subsequent patches to the base release, go to the Patchesand Updates tab of My Oracle Support at:

http://support.oracle.com

To upgrade Oracle GoldenGate from one version to another, follow the upgradeinstructions at:

Overview of Upgrading Oracle GoldenGateUpgrading Oracle GoldenGate for Windowsand UNIX

2.2 Choosing an Installation System for DB2To install Oracle GoldenGate for DB2 LUW, you can use either of the followingconfigurations:

• Install Oracle GoldenGate on the DB2 database server. See one of the following:

– Installing Oracle GoldenGate on Linux and UNIX

– Installing Oracle GoldenGate on Windows

• Install Oracle GoldenGate on another server, and configure Oracle GoldenGate toconnect remotely to the database server through DB2 Connect. All of the OracleGoldenGate functionality that is supported for DB2 LUW is supported in thisconfiguration. To use this option, proceed to Choosing and Configuring a Systemfor Remote Capture or Delivery.

2-1

2.2.1 Choosing and Configuring a System for Remote Capture orDelivery

In a remote installation, you install Oracle GoldenGate on a server that is remote fromthe source or target database server. This server can be any Linux, UNIX, or Windowsplatform that Oracle GoldenGate supports for the DB2 for LUW database. The OracleGoldenGate build must match the version of DB2 LUW that is running on theinstallation server.

Note:

Remote capture is not supported if your database is running on a Big Endian(AIX) server and the Oracle GoldenGate capture is running on a Little Endian(Linux) server.

In this configuration, the location of the database is transparent to Extract andReplicat. Extract can read the DB2 logs on a source DB2 LUW database server, andReplicat can apply data to a target DB2 LUW server.

To Configure Remote Capture or Delivery:

1. Install and run DB2 for LUW on the remote server that has DB2 Connect.

2. Catalog the remote server in the DB2 source or target database by using thefollowing DB2 command.

catalog tcpip node db2_node_name remote remote_DNS_name

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

catalog tcpip node db2_node_name remote remote_DNS_name server remote_port_number

4. Add the DB2 source or target database to the DB2 catalog on the remote serverby using the following DB2 command:

catalog db database_name as database_alias at node db_node_name

Note:

Refer to the IBM DB2 LUW documentation for more information about thesecommands.

5. Download and install the Oracle GoldenGate build that is appropriate for the DB2LUW database on the remote server.

Chapter 2Choosing an Installation System for DB2

2-2

2.3 Understanding and Obtaining the Oracle GoldenGateDistribution

For complete information about how to obtain Oracle Fusion Middleware software, see "Understanding and Obtaining Product Distributions" in Planning an Installation ofOracle Fusion Middleware.

For more information about locating and downloading Oracle Fusion Middlewareproducts, see the Oracle Fusion Middleware Download, Installation, and ConfigurationReadme Files on OTN.

To obtain Oracle GoldenGate follow these steps:

1. Go to the Oracle Technology Network: http://www.oracle.com/technetwork/middleware/fusion-middleware/downloads/index.html

2. Find the Oracle GoldenGate 12c (12.x) release that you want to install.

3. Download the ZIP file appropriate for your system.

2.4 Setting Library Paths for Dynamic Builds on UNIXOracle GoldenGate uses shared libraries. When you install Oracle GoldenGate on aUNIX system, the following must be true before you run GGSCI or any other OracleGoldenGate process.

If you will be running an Oracle GoldenGate program from outside the OracleGoldenGate installation directory on a UNIX system:

• (Optional) Add the Oracle GoldenGate installation directory to the PATHenvironment variable.

• (Required) Add the Oracle GoldenGate installation directory to the shared-librariesenvironment variable.

For example, given an Oracle GoldenGate installation directory of /users/ogg, thesecond command in the following example requires these variables to be set:

Command Requires GG libraries in environment variable?

$ users/ogg > ./ggsci No

$ users > ./ogg/ggsci Yes

To Set the Variables in Korn Shell

PATH=installation_directory:$PATHexport PATHshared_libraries_variable=absolute_path_of_installation_directory:$shared_libraries_variableexport shared_libraries_variable

To Set the Variables in Bourne Shell

export PATH=installation_directory:$PATHexport

Chapter 2Understanding and Obtaining the Oracle GoldenGate Distribution

2-3

shared_libraries_variable=absolute_path_of_installation_directory:$shared_libraries_variable

To Set the Variables in C Shell

setenv PATH installation_directory:$PATHsetenv shared_libraries_variable absolute_path_of_installation_directory:$shared_libraries_variable

Where shared_libraries_variable is one of the variables shown in Table 2-1:

Table 2-1 UNIX/Linux Library Path Variables Per Platform

Platform Environment variable

IBM AIX LIBPATH

HP-UX SHLIB_PATH

Sun Solaris

LINUX

LD_LIBRARY_PATH

The following is an example of how to set the path in Bourne shell:

export LD_LIBRARY_PATH=/ggs/11.0:$LD_LIBRARY_PATH

Note:

To view the libraries that are required by an Oracle GoldenGate process, usethe ldd goldengate_process shell command before starting the process. Thiscommand also shows an error message for any that are missing.

2.5 Preparing to Install Oracle GoldenGate within a ClusterThis topic covers the installation requirements that apply when Oracle GoldenGate willbe installed in a cluster environment. Oracle GoldenGate can be used with any cluster-management solution that is Oracle-certified.

2.5.1 Deciding Where to Install Oracle GoldenGate Binaries and Filesin the Cluster

You will need to install at least some Oracle GoldenGate objects on shared storage.Select cluster-aware shared storage that is independent of, but available to, all nodesof the cluster.

The best practice is the install Oracle GoldenGate entirely on shared storage. Thisallows you to start the Oracle GoldenGate processes from any of the nodes withouthaving to make changes to the parameter files. If the active node fails, the processescan be started quickly on another node, using the processing checkpoints that arepreserved in the installation directory.

If you decide to install the Oracle GoldenGate binaries and files on each node, ratherthan on shared storage, the following must be true:

Chapter 2Preparing to Install Oracle GoldenGate within a Cluster

2-4

• The Oracle GoldenGate installation must have the same location path on everynode

• At minimum, install the following directories on the shared storage to supportOracle GoldenGate recovery requirements. On UNIX or Linux, you can createsymbolic links to them from the installation directory on each node.

– br

– dirchk

– dirdat

– dirtmp

These directories are among those created when you issue CREATE SUBDIRS duringinstallation.

• The parameter files in the dirprm directory, if not placed on the shared drive, mustbe identical on all nodes. To resolve environment settings that must be differentfrom one node to the other, you can set environment settings so they are inheritedfrom the local Manager process or reference a node-specific Oracle GoldenGatemacro file. Because this scenario can be difficult to enforce, the inherent concernscan be avoided by storing the parameter files on the shared drive.

See also "Integrating Oracle GoldenGate into a Cluster " after you install OracleGoldenGate.

2.6 Installing Oracle GoldenGate on Linux and UNIXFollow these steps to install Oracle GoldenGate for Oracle on a Linux or UNIX system.

2.6.1 Installing the Oracle GoldenGate FilesTo install the Oracle GoldenGate files:

1. Extract the Oracle GoldenGate installation file to the system and directory whereyou want to install Oracle GoldenGate.

2. Run the command shell.

3. Change directories to the new Oracle GoldenGate directory.

4. From the Oracle GoldenGate directory, run the GGSCI program.

GGSCI

5. In GGSCI, issue the following command to create the Oracle GoldenGate workingdirectories.

CREATE SUBDIRS

6. Issue the following command to exit GGSCI.

EXIT

2.7 Installing Oracle GoldenGate on WindowsFollow these steps to install Oracle GoldenGate for Oracle on a Windows system.

Chapter 2Installing Oracle GoldenGate on Linux and UNIX

2-5

2.7.1 Installing Oracle GoldenGate into a Windows Cluster1. Log into one of the nodes in the cluster.

2. Choose a drive for the Oracle GoldenGate installation location. This drive must bea resource within the same cluster group that contains the database instance.

3. Ensure that this cluster group is owned by the cluster node that you are logginginto.

4. Install Oracle GoldenGate according to "Installing the Oracle GoldenGate Files ".

2.7.2 Installing the Oracle GoldenGate FilesTo install the Oracle GoldenGate files:

1. Unzip the downloaded file(s) by using WinZip or an equivalent compressionproduct.

2. Move the files in binary mode to a folder on the drive where you want to installOracle GoldenGate. Do not install Oracle GoldenGate into a folder that containsspaces in its name, even if the path is in quotes. For example:

C:\"Oracle GoldenGate" is not valid.

C:\Oracle_GoldenGate is valid.

3. From the Oracle GoldenGate folder, run the GGSCI program.

4. In GGSCI, issue the following command to create the Oracle GoldenGate workingdirectories.

CREATE SUBDIRS

5. Issue the following command to exit GGSCI.

EXIT

2.7.3 Specifying a Custom Manager NameYou must specify a custom name for the Manager process if either of the following istrue:

• You want to use a name for Manager other than the default of GGSMGR.

• There will be multiple Manager processes running as Windows services on thissystem. Each Manager on a system must have a unique name. Before proceedingfurther, note the names of any local Manager services.

To specify a custom manager name:

1. From the directory that contains the Manager program, run GGSCI.

2. Issue the following command.

EDIT PARAMS ./GLOBALS

Chapter 2Installing Oracle GoldenGate on Windows

2-6

Note:

The ./ portion of this command must be used, because the GLOBALS file mustreside at the root of the Oracle GoldenGate installation file.

3. In the file, add the following line, where name is a one-word name for the Managerservice.

MGRSERVNAME name

4. Save the file. The file is saved automatically with the name GLOBALS, but without afile extension. Do not move this file. It is used during installation of the Windowsservice and during data processing.

2.7.4 Installing Manager as a Windows ServiceBy default, Manager is not installed as a service and can be run by a local or domainaccount. However, when run this way, Manager will stop when the user logs out.When you install Manager as a service, you can operate it independently of userconnections, and you can configure it to start manually or at system start-up.

Installing Manager as a service is required on a Windows Cluster, but optionalotherwise.

To install Manager as a Windows service:

1. (Recommended) Log on as the system administrator.

2. Click Start, then Run, and then type cmd in the Run dialog box.

3. From the directory that contains the Manager program that you are installing as aservice, run the INSTALL utility with the following syntax:

install option [...]

Where option is one of the following:

Table 2-2 INSTALL Utility Options

Option Description

ADDEVENTS Adds Oracle GoldenGate events to the Windows EventManager.

ADDSERVICE Adds Manager as a service with the name that is specifiedwith the MGRSERVNAME parameter in the GLOBALS file, if oneexists, or by the default of GGSMGR. ADDSERVICE configures theservice to run as the Local System account, the standard formost Windows applications because the service can be runindependently of user logins and password changes. To runManager as a specific account, use the USER and PASSWORDoptions.1

The service is installed to start at system boot time (seeAUTOSTART). To start it after installation, either reboot thesystem or start the service manually from the Services appletof the Control Panel.

Chapter 2Installing Oracle GoldenGate on Windows

2-7

Table 2-2 (Cont.) INSTALL Utility Options

Option Description

AUTOSTART Sets the service that is created with ADDSERVICE to start atsystem boot time. This is the default unless MANUALSTART isused.

MANUALSTART Sets the service that is created with ADDSERVICE to startmanually through GGSCI, a script, or the Services applet ofthe Control Panel. The default is AUTOSTART.

USER name Specifies a domain user account that executes Manager. Forthe name, include the domain name, a backward slash, andthe user name, for example HEADQT\GGSMGR .

By default, the Manager service is installed to use the LocalSystem account.

PASSWORD password Specifies the password for the user that is specified withUSER.

1 A user account can be changed by selecting the Properties action from the Services applet of theWindows Control Panel.

4. If Windows User Account Control (UAC) is enabled, you are prompted to allow ordeny the program access to the computer. Select Allow to enable the INSTALLutility to run.

The INSTALL utility installs the Manager service with a local system account runningwith administrator privileges. No further UAC prompts will be encountered whenrunning Manager if installed as a service.

Note:

If Manager is not installed as a service, Oracle GoldenGate users will receivea UAC prompt to confirm the elevation of privileges for Manager when it isstarted from the GGSCI command prompt. Running other Oracle GoldenGateprograms also returns a prompt.

2.8 Integrating Oracle GoldenGate into a ClusterIf you installed Oracle GoldenGate in a cluster, take the following steps to integrateOracle GoldenGate within the cluster solution.

2.8.1 General Requirements in a Cluster1. Register the Oracle GoldenGate Manager process (and only Manager) as a

cluster-managed resource as you would any other application. Manager must bethe only Oracle GoldenGate process that the cluster-management software startsand stops, because it is the parent process that manages all other processes.

2. If the cluster uses a virtual IP address, you may need to obtain an available fixedIP address for the Manager process. The VIP must be an available IP address onthe public subnet and cannot be determined through DHCP. In the parameter filesof the Extract data pumps, specify the VIP of the remote Manager as the input

Chapter 2Integrating Oracle GoldenGate into a Cluster

2-8

value of the RMTHOST parameter. Other Oracle GoldenGate products that accessManager also should use the VIP.

3. When you configure Manager, add the AUTOSTART and AUTORESTART parameters sothat Manager starts the replication processes automatically. You can, whenneeded, control Extract, Replicat, and other Oracle GoldenGate processes fromwithin the Oracle GoldenGate user interfaces.

4. Mount the shared drive on one node only. This prevents processes from beingstarted on another node. Use the same mount point on all nodes.

5. Configure Oracle GoldenGate as directed in this documentation.

2.8.2 Adding Oracle GoldenGate as a Windows Cluster ResourceWhen installing Oracle GoldenGate in a Windows cluster, follow these instructions toestablish Oracle GoldenGate as a cluster resource and configure the Manager servicecorrectly on all nodes.

• In the cluster administrator, add the Manager process to the group that containsthe database instance to which Oracle GoldenGate will connect.

• Make sure all nodes on which Oracle GoldenGate will run are selected as possibleowners of the resource.

• Make certain the Manager Windows service has the following dependencies(configurable from the Services control panel):

– The database resource

– The disk resource that contains the Oracle GoldenGate directory

– The disk resource that contains the database transaction log files

– The disk resource that contains the database transaction log backup files

Chapter 2Integrating Oracle GoldenGate into a Cluster

2-9

3Preparing the System for OracleGoldenGate

This chapter describes how to prepare the system for Oracle GoldenGate.This chapter contains the following topics:

• Configuring the Transaction Logs for Oracle GoldenGate

• Preparing Tables for Processing

• Setting the Session Character Set

• Preparing for Initial Extraction

• Specifying the DB2 LUW Database in Parameter Files

3.1 Configuring the Transaction Logs for Oracle GoldenGateTo capture DML operations, Oracle GoldenGate reads the DB2 for LUW online logs bydefault, but will read the archived logs if an online log is not available. To ensure thecontinuity and integrity of Oracle GoldenGate processing, configure the logs asfollows.

3.1.1 Retaining the Transaction LogsConfigure the database to retain the transaction logs for roll forward recovery byenabling one of the following parameter sets, depending on the database version.

• DB2 LUW 9.5 and later:

Set the LOGARCHMETH parameters as follows:

– Set LOGARCHMETH1 to LOGRETAIN.

– Set LOGARCHMETH2 to OFF.

Alternatively, you can use any other LOGARCHMETH options, so long as forwardrecovery is enabled. For example, the following is valid:

– Set LOGARCHMETH1 to DISK.

– Set LOGARCHMETH2 to TSM.

To Determine Log Retention Parameters:

1. Connect to the database.

db2 connect to database user username using password

2. Get the database name.

db2 list db directory

3. Get the database configuration for the database.

db2 get db cfg for database

3-1

The fields to view are:

Log retain for recovery status = RECOVERY User exit for logging status = YES

To Set Log Retention Parameters:

1. Issue one of the following commands.

To enable USEREXIT:

db2 update db cfg for database using USEREXIT ON

If not using USEREXIT, use this command:

db2 update db cfg for database using LOGRETAIN RECOVERY

To set LOGARCHMETH:

db2 update db cfg for database using LOGARCHMETH1 LOGRETAIN db2 update db cfg for database using LOGARCHMETH2 OFF

2. Make a full backup of the database by issuing the following command.

db2 backup db database to device

3. Place the backup in a directory to which DB2 LUW has access rights. Contact yoursystems administrator if you get the following message:

SQL2061N An attempt to access media "device" is denied.

3.1.2 Specifying the Archive PathSet the DB2 OVERFLOWLOGPATH parameter to the archive log directory. The node attachesautomatically to the path variable that you specify.

db2 connect to databasedb2 update db cfg using overflowlogpath "path"

Exclude the node itself from the path. For example, if the full path to the archive logdirectory is /sdb2logarch/oltpods1/archive/OLTPODS1/NODE0000, the OVERFLOWLOGPATHvalue should be specified as /sdb2logarch/oltpods1/archive/OLTPODS1.

3.2 Preparing Tables for ProcessingThe following table attributes must be addressed in an Oracle GoldenGateenvironment.

3.2.1 Disabling Triggers and Cascade ConstraintsDisable triggers, cascade delete constraints, and cascade update constraints on thetarget tables, or alter them to ignore changes made by the Oracle GoldenGatedatabase user. Oracle GoldenGate replicates DML that results from a trigger orcascade constraint. If the same trigger or constraint gets activated on the target table,it becomes redundant because of the replicated version, and the database returns anerror. Consider the following example, where the source tables are emp_src andsalary_src and the target tables are emp_targ and salary_targ.

1. A delete is issued for emp_src.

Chapter 3Preparing Tables for Processing

3-2

2. It cascades a delete to salary_src.

3. Oracle GoldenGate sends both deletes to the target.

4. The parent delete arrives first and is applied to emp_targ.

5. The parent delete cascades a delete to salary_targ.

6. The cascaded delete from salary_src is applied to salary_targ.

7. The row cannot be located because it was already deleted in step 5.

3.2.2 Assigning Row IdentifiersOracle GoldenGate requires some form of unique row identifier on the source andtarget tables to locate the correct target rows for replicated updates and deletes.

3.2.2.1 How Oracle GoldenGate Determines the Kind of Row Identifier to UseUnless a KEYCOLS clause is used in the TABLE or MAP statement, Oracle GoldenGateselects a row identifier to use in the following order of priority:

1. Primary key

2. First unique key alphanumerically that does not contain a timestamp or non-materialized computed column.

3. If none of the preceding key types exist (even though there might be other types ofkeys defined on the table) Oracle GoldenGate constructs a pseudo key of allcolumns that the database allows to be used in a unique key, excluding those thatare not supported by Oracle GoldenGate in a key or those that are excluded fromthe Oracle GoldenGate configuration.

Note:

If there are other, non-usable keys on a table or if there are no keys at all onthe table, Oracle GoldenGate logs an appropriate message to the report file.Constructing a key from all of the columns impedes the performance of OracleGoldenGate on the source system. On the target, this key causes Replicat touse a larger, less efficient WHERE clause.

3.2.2.2 Using KEYCOLS to Specify a Custom KeyIf a table does not have one of the preceding types of row identifiers, or if you preferthose identifiers not to be used, you can define a substitute key if the table hascolumns that always contain unique values. You define this substitute key by includinga KEYCOLS clause within the Extract TABLE parameter and the Replicat MAP parameter.The specified key will override any existing primary or unique key that OracleGoldenGate finds. For more information, see the Reference for Oracle GoldenGate forWindows and UNIX.

3.2.3 Preventing Key ChangesDo not add columns to a key after Oracle GoldenGate starts extracting data from thetable. This rule applies to a primary key, a unique key, a KEYCOLS key, or an all-column

Chapter 3Preparing Tables for Processing

3-3

key. DB2 LUW does not supply a before image for columns that are added to a table.If any columns in a key are updated on the source, Oracle GoldenGate needs a beforeimage to compare with the current values in the target table when it replicates theupdate.

3.2.4 Enabling Change CaptureConfigure DB2 to log data changes in the expanded format that is supplied by the DATACAPTURE CHANGES feature of the CREATE TABLE and ALTER TABLE commands. This formatprovides Oracle GoldenGate with the entire before and after images of rows that arechanged by update statements. You can use GGSCI to issue the ALTER TABLEcommand as follows.

To Enable Change Capture from GGSCI:

1. From the Oracle GoldenGate directory, run GGSCI.

2. Log on to DB2 from GGSCI as a user that has ALTER TABLE privileges. Specify thedata source name with SOURCEDB and specify the user login with USERID andPASSWORD. See Reference for Oracle GoldenGate for Windows and UNIX forencryption options if needed.

DBLOGIN SOURCEDB dsn, USERID user[, PASSWORD password]

3. Issue the following command. where owner.table is the fully qualified name of thetable. You can use a wildcard to specify multiple table names. Only the asterisk (*)wildcard is supported for DB2 LUW.

ADD TRANDATA owner.table

ADD TRANDATA issues the following command, which includes logging the beforeimage of LONGVAR columns:

ALTER TABLE name DATA CAPTURE CHANGES INCLUDE LONGVAR COLUMNS;

Example 3-1 To Exclude LONGVAR Logging:

To omit the INCLUDE LONGVAR COLUMNS clause from the ALTER TABLE command, use ADDTRANDATA with the EXCLUDELONG option.

ADD TRANDATA owner.table, EXCLUDELONG

Note:

If LONGVAR columns are excluded from logging, the Oracle GoldenGate featuresthat require before images, such as the GETUPDATEBEFORES, NOCOMPRESSUPDATES,and NOCOMPRESSDELETES parameters, might return errors if tables contain thosecolumns. For a workaround, see the REQUIRELONGDATACAPTURECHANGES |NOREQUIRELONGDATACAPTURECHANGES options of the TRANLOGOPTIONS parameter.

3.2.5 Maintaining Materialized Query TablesTo maintain parity between source and target materialized query tables (MQT), youreplicate the base tables, but not the MQTs. The target database maintains the MQTsbased on the changes that Replicat applies to the base tables.

Chapter 3Preparing Tables for Processing

3-4

The following are the rules for configuring these tables:

• Include the base tables in your TABLE and MAP statements.

• Do not include MQTs in the TABLE and MAP statements.

• Wildcards can be used in TABLE and MAP statements, even though they mightresolve MQT names along with regular table names. Oracle GoldenGateautomatically excludes MQTs from wildcarded table lists. However, any MQT thatis explicitly listed in an Extract TABLE statement by name will cause Extract toabend.

3.3 Setting the Session Character SetTo support the conversion of character sets between the source and target databases,make certain that the session character set is the same as the database character set.You can set the session character set with the DB2CODEPAGE environment variable.

3.4 Preparing for Initial ExtractionDuring the initialization of the Oracle GoldenGate environment, you will be doing aninitial data synchronization and starting the Oracle GoldenGate processes for the firsttime. In conjunction with those procedures, you will be creating process groups. Tocreate an Extract group, an initial start position must be established in the transactionlog. This initial read position will be on a transaction boundary that is based on one ofthe following:

• the end of the transaction file

• a specific LSN value

The start point is specified with the BEGIN option of the ADD EXTRACT command.

When Extract starts for the first time, it captures all of the transaction data that itencounters after the specified start point, but none of the data that occurred beforethat point. This can cause partial transactions to be captured if open transactions spanthe start point.

To ensure initial transactional consistency:

To avoid the capture of partial transactions, initialize the Extract process at a point intime when the database is in a quiesced state. DB2 provides a QUIESCE command forsuch a purpose. This is the only way to ensure transactional consistency.

Note:

After Extract is past the initialization, subsequent restarts of Extract will notextract partial transactions, because the process uses recovery checkpoints tomark its last read position.

To view open transactions:

IBM provides a utility called db2pd for monitoring DB2 databases and instances. Youcan use it to view information about open transactions and to determine if any of them

Chapter 3Setting the Session Character Set

3-5

span the start point. However, because DB2 LUW log records lack timestamps, itmight not be possible to make an accurate assessment. If possible, quiesce thedatabase prior to initialization of Oracle GoldenGate.

For more information on initializing the Oracle GoldenGate environment, see Administering Oracle GoldenGate for Windows and UNIX.

3.5 Specifying the DB2 LUW Database in Parameter FilesFor an Oracle GoldenGate process to connect to the correct DB2 LUW database, youmust specify the name (not an alias) of the DB2 LUW database with the followingparameters:

• Specify the DB2 source database with the Extract parameter SOURCEDB.

• Specify the DB2 target database name with the Replicat parameter TARGETDB.

For more information about these parameters, see the Reference for OracleGoldenGate for Windows and UNIX.

Chapter 3Specifying the DB2 LUW Database in Parameter Files

3-6

4Configuring Oracle GoldenGate for DB2LUW

This chapter provides an overview of the basic steps required to configure OracleGoldenGate for a DB2 LUW source and target database.This chapter contains the following topics:

• What to Expect from these Instructions

• Where to Get More Information

• Configuring the Primary Extract

• Configuring the Data Pump Extract

• Configuring Replicat

• Next Steps in the Deployment

• When to Start Replicating Transactional Changes

• Testing Your Configuration

4.1 What to Expect from these InstructionsThese instructions show you how to configure basic parameter (configuration) files forthe following processes:

• A primary Extract (captures transaction data from the data source)

• A data-pump Extract (propagates the data from local storage to the target system)

• A Replicat (applies replicated data to the target database)

Your business requirements probably will require a more complex topology, but thisprocedure forms a basis for the rest of your configuration steps.

By performing these steps, you can:

• Get the basic configuration files established.

• Build upon them later by adding more parameters as you make decisions aboutfeatures or requirements that apply to your environment.

• Use copies of them to make the creation of additional parameter files faster thanstarting from scratch.

4.2 Where to Get More InformationSee Administering Oracle GoldenGate for Windows and UNIX for more informationabout:

• The processes and files that you are configuring

• Detailed configuration information

4-1

• Security options

• Data-integration options (filtering, mapping, conversion)

• Instructions for configuring complex topologies

• Steps to perform initial instantiation of the replication environment

• Administrative topics

4.3 Configuring the Primary ExtractThese steps configure the primary Extract to capture transaction data from a sourceDB2 LUW database and write the data to a local trail for temporary storage.

1. In GGSCI on the source system, create the Extract parameter file.

EDIT PARAMS name

Where: name is the name of the primary Extract.

2. Enter the Extract parameters in the order shown, starting a new line for eachparameter statement. See Table 4-1 for more information and parameterdescriptions.

Basic parameters for the primary Extract

EXTRACT financeSOURCEDB mysource, USERIDALIAS myalias LOGALLSUPCOLSENCRYPTTRAIL AES192EXTTRAIL /ggs/dirdat/ltTABLE hr.*;

Table 4-1 Basic Parameters for Primary Extract

Parameter Description

EXTRACT group group is the name of the Extract group. For more information, see Referencefor Oracle GoldenGate for Windows and UNIX.

SOURCEDB database, USERIDALIAS alias

Specifies the real name of the source DB2 LUW database (not an alias), plusthe alias of the database login credential of the user that is assigned toExtract. This credential must exist in the Oracle GoldenGate credential store.For more information, see Database User for Oracle GoldenGate Processes.

ENCRYPTTRAIL algorithm Encrypts the local trail. For more information about Oracle GoldenGate trailencryption options, see Administering Oracle GoldenGate for Windows andUNIX.

EXTTRAIL pathname Specifies the path name of the local trail to which the primary Extract writescaptured data for temporary storage.

Chapter 4Configuring the Primary Extract

4-2

Table 4-1 (Cont.) Basic Parameters for Primary Extract

Parameter Description

TABLE schema.object; Specifies the database object for which to capture data.

• TABLE is a required keyword.• schema is the schema name or a wildcarded set of schemas.• object is the table name, or a wildcarded set of tables.See Administering Oracle GoldenGate for Windows and UNIX for informationabout how to specify object names with and without wildcards. Note that onlythe asterisk (*) wildcard is supported for DB2 LUW. The question mark (?)wildcard is not supported for this database.

Terminate the parameter statement with a semi-colon.

To exclude tables from a wildcard specification, use the TABLEEXCLUDEparameter. See Reference for Oracle GoldenGate for Windows and UNIX formore information about usage and syntax.

For more information and for additional TABLE options that control datafiltering, mapping, and manipulation, see Reference for Oracle GoldenGatefor Windows and UNIX.

3. Enter any optional Extract parameters that are recommended for yourconfiguration. You can edit this file at any point before starting processing by usingthe EDIT PARAMS command in GGSCI. For a list of parameters and links to theirdetailed reference, see Reference for Oracle GoldenGate for Windows and UNIX.

4. Save and close the file.

4.4 Configuring the Data Pump ExtractThese steps configure the data pump that reads the local trail and sends the dataacross the network to a remote trail on the target. The data pump is optional, butrecommended.

1. In GGSCI on the source system, create the data-pump parameter file.

EDIT PARAMS name

Where name is the name of the data-pump Extract.

2. Enter the data-pump Extract parameters in the order shown, starting a new line foreach parameter statement. Your input variables will be different. See Table 4-2 fordescriptions.

Basic parameters for the data-pump Extract group:

EXTRACT extpumpSOURCEDB mypump, USERIDALIAS myaliasRMTHOST fin1, MGRPORT 7809 ENCRYPT AES192, KEYNAME securekey2RMTTRAIL /ggs/dirdat/rtTABLE hr.*;

Table 4-2 Basic Parameters for a Data-pump Extract

Parameter Description

EXTRACT group group is the name of the data pump Extract. For more information, see Reference forOracle GoldenGate for Windows and UNIX.

Chapter 4Configuring the Data Pump Extract

4-3

Table 4-2 (Cont.) Basic Parameters for a Data-pump Extract

Parameter Description

SOURCEDB database, USERIDALIAS alias

Specifies the real name of the source DB2 LUW database (not an alias), plus the aliasof the database login credential of the user that is assigned to Extract. This credentialmust exist in the Oracle GoldenGate credential store. For more information, see Database User for Oracle GoldenGate Processes.

RMTHOST hostname, MGRPORT portnumber,[, ENCRYPT algorithm KEYNAME keyname]

• RMTHOST specifies the name or IP address of the target system.• MGRPORT specifies the port number where Manager is running on the target.• ENCRYPT specifies optional encryption of data across TCP/IP.For additional options and encryption details, see Reference for Oracle GoldenGatefor Windows and UNIX.

RMTTRAIL pathname Specifies the path name of the remote trail. For more information, see Reference forOracle GoldenGate for Windows and UNIX.

TABLE schema.object; Specifies a table or sequence, or multiple objects specified with a wildcard. In mostcases, this listing will be the same as that in the primary Extract parameter file.

• TABLE is a required keyword.• schema is the schema name or a wildcarded set of schemas.• object is the name of a table or a wildcarded set of tables.See Administering Oracle GoldenGate for Windows and UNIX for information abouthow to specify object names with and without wildcards. Note that only the asterisk (*)wildcard is supported for DB2 LUW. The question mark (?) wildcard is not supportedfor this database.

Terminate the parameter statement with a semi-colon.

To exclude tables from a wildcard specification, use the TABLEEXCLUDE parameter.See Reference for Oracle GoldenGate for Windows and UNIX for more informationabout usage and syntax.

For more information and for additional TABLE options that control data filtering,mapping, and manipulation, see Reference for Oracle GoldenGate for Windows andUNIX.

3. Enter any optional Extract parameters that are recommended for yourconfiguration. You can edit this file at any point before starting processing by usingthe EDIT PARAMS command in GGSCI. For a list of parameters and links to theirdetailed reference, see Reference for Oracle GoldenGate for Windows and UNIX.

4. Save and close the file.

4.5 Configuring ReplicatThese steps configure a Replicat process on a DB2 LUW target system. If you areconfiguring Replicat for a database of a different type, see the installation andconfiguration documentation for that database.

4.5.1 Creating a Temporal TableA temporal table is a table that maintains the history of its data and the time periodwhen its data are valid. Temporal tables are used in Oracle GoldenGate to keep trackof all the old rows that are deleted or updated in the table. Temporal tables are alsoused to maintain the business validity of its rows and data. For example, OracleGoldenGate keeps track of the time period during which a row is valid. There are threetypes of temporal tables, system-period, application-period, and bitemporal table.

Chapter 4Configuring Replicat

4-4

4.5.1.1 Support for Temporal Tables• Replication between system-period temporal tables and application-period

temporal tables is not supported.

• Replication from a non-temporal table to a temporal table is not supported.

• Replication of temporal tables with the INSERTALLRECORDS parameter is notsupported.

• Bidirectional replication is supported only with the default replication.

• CDR in bidirectional replication is not supported.

• CDR in application-period temporal tables is supported.

4.5.1.2 Replicating with Temporal TablesYou can choose one of the following methods to replicate a system-period or abitemporal temporal table as follows:

• You can replicate a temporal table to another temporal table only; this is thedefault behavior. Oracle GoldenGate will not replicate the SYSTEM_TIME period andtransaction id columns because these are automatically generated columns at theapply side. The database manager populates the columns in the target temporaltable using the system clock time and with the default values. You can preservethe original values these columns then use any of the following:

– Add extra timestamp columns in the target temporal table and map thecolumns accordingly. The extra columns are automatically added to theassociated history table.

– Use a non-temporal table at the apply side and map the columnsappropriately. In this scenario, you will not be able to maintain the historytable.

– In a heterogeneous configuration where the source is DB2 LUW and the targetis a different database, you can either ignore the automatically generatedcolumns or use an appropriate column conversion function to convert thecolumns value in the format that target database supports and map them totarget columns accordingly.

Or

• You can replicate a temporal table, with the associated history table, to a temporaland history table respectively then you must specify the replicate parameter,DBOPTIONS SUPPRESSTEMPORALUPDATES. You must specify both the temporal table andhistory table to be captured in the Extract parameter file. Oracle GoldenGatereplicates the SYSTEM_TIME period and transactions id columns value. You mustensure that the database instance has the execute permission to run the storedprocedure at the apply side.

Oracle GoldenGate cannot detect and resolve conflicts while using default replicationas SYSTEM_TIME period and transactionstart id columns remains auto generated.These columns cannot be specified in set and where clause. If you use theSUPPRESSTEMPORALUPDATES parameter, then Oracle GoldenGate supports CDR.

Chapter 4Configuring Replicat

4-5

4.5.1.3 ConvertingYou can convert an already existing table into a temporal table, which changes thestructure of the table. This section describes how the structure of the tables changes.The following sample existing table is converted into all three temporal tables types inthe examples in this section:.

Table policy_info(Policy_id char[4] not null primary key,Coverage int not null )And the tables contains the following initial rows POLICY_ID COVERAGE ------------- ----------- ABC 12000 DEF 13000 ERT 14000

Example 1 Converting an existing table into System-period temporal table.You convert the sample existing table into a system-period temporal table by addingSYSTEM_PERIOD, transaction id columns, and SYSTEM_TIME period as in the following:

ALTER TABLE policy_info ADD COLUMN sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN;ALTER TABLE policy_info ADD COLUMN sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END;ALTER TABLE policy_info ADD COLUMN ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID;ALTER TABLE policy_info ADD PERIOD SYSTEM_TIME(sys_start, sys_end);

Then you create a history table for the new temporal table using one of the followingtwo methods:

• CREATE TABLE hist_policy_info( policy_id CHAR(4) NOT NULL,coverage INT NOT NULL,sys_start TIMESTAMP(12) NOT NULL ,sys_end TIMESTAMP(12) NOT NULL,ts_id TIMESTAMP(12) NOT NULL ); ALTER TABLE hist_policy_info ADD RESTRICT ON DROP;

• CREATE TABLE hist_policy_info LIKE policy_info with RESTRICT ON DROP;

The RESTRICT ON DROP clause will not allow the history table to get dropped whiledropping system-period temporal table. Otherwise the history table gets implicitlydropped while dropping its associated temporal table. You can create a historytable without RESTRICT ON DROP. A history table cannot be explicitly dropped.

You should not use the GENERATED ALWAYS clause while creating a history table. Theprimary key of the system-period temporal table also does not apply here as therecould be many updates for a particular row in the base table, which triggers manyinserts into the history table for the same set of primary keys. Apart from these,

Chapter 4Configuring Replicat

4-6

the structure of a history table should be exactly same as its associated system-period temporal table. The history table must have the same number and order ofcolumns as system-period temporal table. History table columns cannot explicitlybe added, dropped, or changed. You must associate a system-period temporaltable with its history table with the following statement:

ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_info.

The GENERATED ALWAYS columns of the table are the ones that are always populatedby the database manager so you do not have any control over these columns.The database manager populates these columns based on the system time.

The extra added SYSTEM_PERIOD and transaction id columns will have defaultvalues for already existing rows as in the following:

POLICY_ID COVERAGE SYS_START SYS_END TS_ID--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------ABC 12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000DEF 13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000ERT 14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

The associated history table is populated with the before images once you startupdating the temporal table.

Example 2 Converting an existing table into application-period temporal table.You can convert the sample existing table into application-period temporal table byadding time columns and a BUSINESS_TIME period as in the following:

ALTER TABLE policy_info ADD COLUMN bus_start DATE NOT NULL DEFAULT '10/10/2001'"ALTER TABLE policy_info ADD COLUMN bus_end DATE NOT NULL DEFAULT '10/10/2002'ALTER TABLE policy_info ADD PERIOD BUSINESS_TIME(bus_start, bus_end)

While adding time columns, you need to make sure that while entering businessvalidity time values of the existing time columns, the bus_start column always hasvalue lesser than bus_end because these columns specify the business validity of therows.The new application-period temporal table will look similar to:

POLICY_ID COVERAGE BUS_START BUS_END--------- ----------- ---------- -------------------------------ERT 14000 10/10/2001 10/10/2002DEF 13000 10/10/2001 10/10/2002ABC 12000 10/10/2001 10/10/2002

Example 3 Converting an existing table into bitemporal table.You can convert the sample existing table into bitemporal table by addingSYSTEM_PERIOD, time columns along with the SYSTEM_TIME and BUSINESS_TIME period asin the following:

ALTER TABLE policy_info ADD COLUMN sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN;ALTER TABLE policy_info

Chapter 4Configuring Replicat

4-7

ADD COLUMN sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END;ALTER TABLE policy_info ADD COLUMN ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID;ALTER TABLE policy_info ADD PERIOD SYSTEM_TIME(sys_start, sys_end); ALTER TABLE policy_info ADD COLUMN bus_start DATE NOT NULL DEFAULT '10/10/2001'"ALTER TABLE policy_info ADD COLUMN bus_end DATE NOT NULL DEFAULT '10/10/2002'ALTER TABLE policy_info ADD PERIOD BUSINESS_TIME(bus_start, bus_end)

While adding the time columns, you must make sure that while entering businessvalidity time values of already existing time columns, the bus_start column always hasvalue lesser than bus_end because these columns specify the business validity of therows.Then you create a history table for the new temporal table using one of the followingtwo methods:

• CREATE TABLE hist_policy_info( policy_id CHAR(4) NOT NULL,coverage INT NOT NULL,sys_start TIMESTAMP(12) NOT NULL ,sys_end TIMESTAMP(12) NOT NULL,ts_id TIMESTAMP(12) NOT NULL ); ALTER TABLE hist_policy_info ADD RESTRICT ON DROP;CREATE TABLE hist_policy_info LIKE policy_info with RESTRICT ON DROP;

• The RESTRICT ON DROP clause will not allow the history table to get dropped whiledropping system-period temporal table. Otherwise the history table gets implicitlydropped while dropping its associated temporal table. You can create a historytable without RESTRICT ON DROP. A history table cannot be explicitly dropped.

You should not use the GENERATED ALWAYS clause while creating a history table. Theprimary key of the system-period temporal table also does not apply here as therecould be many updates for a particular row in the base table, which triggers manyinserts into the history table for the same set of primary keys. Apart from these,the structure of a history table should be exactly same as its associated system-period temporal table. The history table must have the same number and order ofcolumns as system-period temporal table. History table columns cannot explicitlybe added, dropped, or changed. You must associate a system-period temporaltable with its history table with the following statement:

ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_info.

The GENERATED ALWAYS columns of the table are the ones that are always populatedby the database manager so you do not have any control over these columns.The database manager populates these columns based on the system time.

The extra added SYSTEM_PERIOD and transaction id columns will have defaultvalues for already existing rows as in the following:

POLICY_ID COVERAGE SYS_START SYS_END TS_ID--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------

Chapter 4Configuring Replicat

4-8

ABC 12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000DEF 13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000ERT 14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

The associated history table is populated with the before images once you startupdating the temporal table.

The extra added SYSTEM_TIME period, transaction id and time columns will have defaultvalues for already existing rows as in the following:

POLICY_ID COVERAGE SYS_START SYS_END TS_ID BUS_START BUS_END--------- ----------- -------------------------------- -------------------------------- -------------------------------- ---------- -------------------------------------ABC 12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002DEF 13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002ERT 14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002

The history table is populated with the before images once user starts updating thetemporal table.

Example 4 Replication in Heterogeneous Environment.In heterogeneous configuration in which you do not have temporal tables at the applyside, you can only replicate the system-period and bitemporal tables though not theassociated history tables. While performing replication in this situation, you must takecare of the SYSTEM_PERIOD and transaction id columns value. These columns will havesome values that the target database might not support. You should first use the mapconversion functions to convert these values into the format that the target databasesupports, and then map the columns accordingly.For example, MySQL has a DATETIME range from 1000-01-01 00:00:00.000000 to9999-12-31 23:59:59.999999. You cannot replicate a timestamp value of0001-01-01-00.00.00.000000000000 to MySQL. To replicate such values, you mustconvert this value into the MySQL DATETIME value 1000-01-01 00:00:00.000000, andthen map the columns. If you have the following row in the policy_info system-periodtable:

POLICY_ID COVERAGE SYS_START SYS_END TS_ID--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------ABC 12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

To replicate the row into MySQL, you would use the colmap() function:

Chapter 4Configuring Replicat

4-9

map source_schema.policy_info, target target_schema.policy_info colmap(policy_id=policy_id, coverage=coverage, sys_start= @IF( ( @NUMSTR( @STREXT(sys_start,1,4))) > 1000, sys_start, '1000-01-01 00.00.00.000000'), sys_end=sys_end, ts_id= @IF( ( @NUMSTR( @STREXT(ts_id,1,4))) > 1000, ts_id, '1000-01-01 00.00.00.000000'));

4.5.2 Creating a Checkpoint TableThe checkpoint table is a required component of Replicat.

Replicat maintains its recovery checkpoints in the checkpoint table, which is stored inthe target database. Checkpoints are written to the checkpoint table within the Replicattransaction. 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 theprocess or the database.

To configure a checkpoint table, see Administering Oracle GoldenGate for Windowsand UNIX.

4.5.3 Configuring the Replicat Parameter FileThese steps configure the Replicat process. This process applies replicated data to aDB2 LUW target database.

1. In GGSCI on the target system, create the Replicat parameter file.

EDIT PARAMS name

Where: name is the name of the Replicat group.

2. Enter the Replicat parameters in the order shown, starting a new line for eachparameter statement. See Table 4-3 for descriptions.

Basic parameters for the Replicat group:

REPLICAT financerTARGETDB mytarget, USERIDALIAS myaliasASSUMETARGETDEFSMAP hr.*, TARGET hr2.*;

Table 4-3 Basic Parameters for Replicat

Parameter Description

REPLICAT group group is the name of the Replicat group.

TARGETDB database, USERIDALIAS alias

Specifies the real name of the target DB2 LUW database (not analias), plus the alias of the database login credential of the userthat is assigned to Replicat. This credential must exist in theOracle GoldenGate credential store. For more information, see Database User for Oracle GoldenGate Processes.

Chapter 4Configuring Replicat

4-10

Table 4-3 (Cont.) Basic Parameters for Replicat

Parameter Description

ASSUMETARGETDEFS Specifies how to interpret data definitions. ASSUMETARGETDEFSassumes the source and target tables have identical definitions.(This procedure assume identical definitions.)

Use the alternative SOURCEDEFS if the source and target tableshave different definitions, and create a source data-definitions filewith the DEFGEN utility. For more information about datadefinitions, see Administering Oracle GoldenGate for Windowsand UNIX.

MAP schema.object, TARGET schema.object;

Specifies the relationship between a source table or multipleobjects, and the corresponding target object or objects.

• MAP specifies the source portion of the MAP statement and is arequired keyword. Specify the source objects in this clause.

• TARGET specifies the target portion of the MAP statement andis a required keyword. Specify the target objects to which youare mapping the source objects.

• schema is the schema name or a wildcarded set of schemas.• object is the name of a table or a wildcarded set of objects.Terminate this parameter statement with a semi-colon.

Note that only the asterisk (*) wildcard is supported for DB2 LUW.The question mark (?) wildcard is not supported for thisdatabase.To exclude objects from a wildcard specification, usethe MAPEXCLUDE parameter.

For more information and for additional options that control datafiltering, mapping, and manipulation, see MAP in Reference forOracle GoldenGate for Windows and UNIX.

3. Enter any optional Replicat parameters that are recommended for yourconfiguration. You can edit this file at any point before starting processing by usingthe EDIT PARAMS command in GGSCI. For a list of parameters and links to theirdetailed reference, see Reference for Oracle GoldenGate for Windows and UNIX.

4. Save and close the file.

4.6 Next Steps in the DeploymentBecause of its flexibility, Oracle GoldenGate offers numerous features and options thatmust be considered before you start any processes. To further configure OracleGoldenGate to suit your business needs, see the following:

• For additional configuration guidelines to achieve specific replication topologies,see Administering Oracle GoldenGate for Windows and UNIX. This guide alsocontains information about:

– Oracle GoldenGate architecture

– Oracle GoldenGate commands

– Oracle GoldenGate initial load methods

– Configuring security

– Using customization features

– Mapping columns that contain dissimilar data

Chapter 4Next Steps in the Deployment

4-11

– Data filtering and manipulation

• For syntax options and descriptions of Oracle GoldenGate GGSCI commands andOracle GoldenGate parameters shown in this guide, see Reference for OracleGoldenGate for Windows and UNIX.

4.7 When to Start Replicating Transactional ChangesYou 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 datavalues. Unless you are starting with brand new source and target databases with nocurrent user activity, you will need to activate change capture and apply processes tohandle ongoing transactional changes while an initial load is being applied to thetarget. This process is known as initial synchronization, or also as instantiation. Theinitial load captures a point-in-time snapshot of the source data and applies it to thetarget, while Oracle GoldenGate maintains any changes that are made after that point.

See Administering Oracle GoldenGate for Windows and UNIX for instantiation options.

4.8 Testing Your ConfigurationIt is important to test your configuration in a test environment before deploying it liveon your production machines. This is especially important in an active-active or highavailability configuration, where trusted source data may be touched by the replicationprocesses. Testing enables you to find and resolve any configuration mistakes or dataissues without the need to interrupt user activity for re-loads on the target or othertroubleshooting activities.

Chapter 4When to Start Replicating Transactional Changes

4-12

5Uninstalling Oracle GoldenGate

This chapter describes how to uninstall Oracle GoldenGate.This chapter contains the following sections:

• Stopping Processes

• Removing the Oracle GoldenGate Database Setup

• Removing Oracle GoldenGate Windows Components

• Manually Removing the Oracle GoldenGate Files

5.1 Stopping ProcessesThis procedure stops the Extract and Replication processes. Leave Manager runninguntil directed to stop it.

On all Systems:

1. Run the command shell.

2. Log on as the system administrator or as a user with permission to issue OracleGoldenGate commands and delete files and directories from the operating system.

3. Change directories to the Oracle GoldenGate installation directory.

4. Run GGSCI.

5. Stop all Oracle GoldenGate processes.

STOP ER *

6. Stop the Manager process.

STOP MANAGER

5.2 Removing the Oracle GoldenGate Database SetupFollow these instructions to remove Oracle GoldenGate objects and attribute settingsthat are configured within the database.

On a Source System:

1. Log on as the system administrator or as a user with permission to issue OracleGoldenGate commands and delete files and directories from the operating system.

2. Run GGSCI from the Oracle GoldenGate directory.

3. Stop all Oracle GoldenGate processes.

STOP ER *

4. Stop the Manager process.

STOP MANAGER

5-1

5. In GGSCI, log into the database with the DBLOGIN command.

DBLOGIN SOURCEDB database, USERIDALIAS alias

6. In GGSCI, alter the tables that were in the Oracle GoldenGate configuration toDATA CAPTURE NONE.

DELETE TRANDATA schema.table [NOSCHEDULINGCOLS | ALLCOLS]

On a Target System:

1. Stop Replicat.

STOP REPLICAT group

2. Log into the database with the DBLOGIN command.

DBLOGIN SOURCEDB database, USERIDALIAS alias

3. Delete the Replicat group.

DELETE REPLICAT group

4. Delete the Replicat checkpoint table.

DELETE CHECKPOINTTABLE schema.table

5.3 Removing Oracle GoldenGate Windows Components(Valid for Windows installations) This procedure does the following:

• Removes Oracle GoldenGate as a Windows cluster resource from a source ortarget Windows system.

• Stops Oracle GoldenGate events from being reported to the Windows EventManager.

• Removes the Manager service.

Perform these steps on source and target systems.

1. Log on as the system administrator or as a user with permission to issue OracleGoldenGate commands and to delete files and directories from the operatingsystem.

2. Run GGSCI and make certain that all Extract and Replicat processes are stopped.Stop any that are running.

STATUS ER *STOP ER *

3. (Cluster) Use the Cluster Administrator tool to take the Manager resource offline.

4. (Cluster) Right click the resource and select Delete to remove it.

5. Click Start then Run, and then type cmd in the Run dialog box to open thecommand console.

6. Change directories to the Oracle GoldenGate installation directory.

7. Run the INSTALL utility with the following syntax.

install deleteevents deleteservice

8. (Cluster) Move the cluster group to the next node in the cluster, and repeat fromstep 5.

Chapter 5Removing Oracle GoldenGate Windows Components

5-2

5.4 Manually Removing the Oracle GoldenGate FilesPerform these steps on all systems to remove the Oracle GoldenGate installationdirectory.

1. In GGSCI, verify that all processes are stopped. Stop any that are running.

STATUS MANAGERSTATUS ER *STOP MANAGERSTOP ER *

2. Exit GGSCI.

EXIT

3. Remove the Oracle GoldenGate installation directory.

Chapter 5Manually Removing the Oracle GoldenGate Files

5-3

AOracle GoldenGate Installed Components

This appendix describes the programs, directories, and other components created orused by the Oracle GoldenGate software in the Oracle GoldenGate installationdirectory. Additional files not listed here might be installed on certain platforms. Fileslisted here might not be installed on every platform.This appendix contains the following sections:

• Oracle GoldenGate Programs and Utilities

• Oracle GoldenGate Subdirectories

• Other Oracle GoldenGate Files

• Oracle GoldenGate Checkpoint Table

A.1 Oracle GoldenGate Programs and UtilitiesThis section describes programs installed in the root Oracle GoldenGate installationdirectory.

Note:

Some programs may not exist in all installations. For example, if only captureor delivery is supported by Oracle GoldenGatee for your platform, the extractor replicat program will not be installed, respectively. Likewise, special filesmight be installed to support a specific database.

Table A-1 Oracle GoldenGate Installed Programs and Utilities

Program Description

convchk Converts checkpoint files to a newer version.

convprm Converts parameter files that do not use SQL-92 rules for quotednames and literals to updated parameter files that use SQL-92rules. SQL-92 format for quoted object names and literals wasintroduced as the default with version 12c of Oracle GoldenGate.

defgen Generates data definitions and is referenced by OracleGoldenGate processes when source and target tables havedissimilar definitions.

emsclnt Sends event messages created by Collector and Replicat onWindows or UNIX systems to EMS on NonStop systems.

extract Performs capture from database tables or transaction logs orreceives transaction data from a vendor access module.

ggmxinstall Oracle GoldenGate installation script for the SQL/MX database.

A-1

Table A-1 (Cont.) Oracle GoldenGate Installed Programs and Utilities

Program Description

ggcmd Associated program of GGSCI. Launches and monitors externalapplications, such as the JAGENT of Oracle GoldenGateMonitor. Integrates those applications into the GGSCIenvironment.

ggsci User interface to Oracle GoldenGate for issuing commands andmanaging parameter files.

ggsmgr.jcl

ggsmgr.proc

ggsmgrst.jcl

ggsmgrst.proc

Start the Oracle GoldenGate Manager process from a batch jobor the operator console on a z/OS system. Installed to supportDB2 z/OS databases.

install Installs Oracle GoldenGate as a Windows service and providesother Windows-based service options.

keygen Generates data-encryption keys.

logdump A utility for viewing and saving information stored in extract trailsor files.

mgr (Manager) Control process for resource management, controland monitoring of Oracle GoldenGate processes, reporting, androuting of requests through the GGSCI interface.

oggerr Manages Oracle GoldenGate error messages.

replicat Applies data to target database tables.

reverse A utility that reverses the order of transactional operations, sothat Replicat can be used to back out changes from targettables, restoring them to a previous state.

server The Collector process, an Extract TCP/IP server collector thatwrites data to remote trails.

vamserv Started by Extract to read the TMF audit trails generated byTMF-enabled applications. Installed to support the NonStopSQL/MX database.

A.2 Oracle GoldenGate SubdirectoriesThis Section describes the subdirectories of the Oracle GoldenGate installationdirectory and their contents.

Note:

Some directories may not exist in all installations.

Table A-2 Oracle GoldenGate Installed Subdirectories

Directory Description

br Contains the checkpoint files for the bounded recover feature.

Appendix AOracle GoldenGate Subdirectories

A-2

Table A-2 (Cont.) Oracle GoldenGate Installed Subdirectories

Directory Description

cfg Contains the property and XML files that are used to configureOracle GoldenGate Monitor.

dirdb Contains the data store that is used to persist information that isgathered from an Oracle GoldenGate instance for use by theOracle GoldenGate Monitor application or within OracleEnterprise Manager.

dirchk Contains the checkpoint files created by Extract and Replicatprocesses, which store current read and write positions tosupport data accuracy and fault tolerance. Written in internalOracle GoldenGate format.

File name format is group_name+sequence_number.ext wheresequence_number is a sequential number appended to aged filesand ext is either cpe for Extract checkpoint files or cpr forReplicat checkpoint files.

Do not edit these files.

Examples:

ext1.cpe

rep1.cpr

dircrd Contains credential store files.

dirdat The default location for Oracle GoldenGate trail files and extractfiles that are created by Extract processes to store extracteddata for further processing by the Replicat process or anotherapplication or utility. Written in internal Oracle GoldenGateformat.

File name format is a user-defined two-character prefix followedby either a six-digit sequence number (trail files) or the user-defined name of the associated Extract process group (extractfiles).

Do not edit these files.

Examples:

rt000001

finance

dirdef The default location for data definitions files created by theDEFGEN utility to contain source or target data definitions used ina heterogeneous synchronization environment. Written inexternal ASCII. File name format is a user-defined namespecified in the DEFGEN parameter file.

These files may be edited to add definitions for newly createdtables. If you are unsure of how to edit a definitions file, contactOracle GoldenGate technical support.

Example:

defs.dat

dirdmp Contains trace, or dump, files that support the internal activitylogging mechanism.

dirjar Contains the Java executable files that support OracleGoldenGate Monitor.

Appendix AOracle GoldenGate Subdirectories

A-3

Table A-2 (Cont.) Oracle GoldenGate Installed Subdirectories

Directory Description

dirpcs Default location for status files. File name format isgroup.extension where group is the name of the group andextension is either pce (Extract), pcr (Replicat), or pcm(Manager).

These files are only created while a process is running. The fileshows the program name, the process name, the port number,and the process ID.

Do not edit these files.

Examples:

mgr.pcm

ext.pce

dirprm The default location for Oracle GoldenGate parameter filescreated by Oracle GoldenGate users to store run-timeparameters for Oracle GoldenGate process groups or utilities.Written in external ASCII format. File name format is groupname/user-defined name.prm or mgr.prm .

These files may be edited to change Oracle GoldenGateparameter values after stopping the process. They can be editeddirectly from a text editor or by using the EDIT PARAMS commandin GGSCI.

Examples:

defgen.prm

finance.prm

dirrec Not used by Oracle GoldenGate.

dirrpt The default location for process report files created by Extract,Replicat, and Manager processes to report statistical informationrelating to a processing run. Written in external ASCII format.

File name format is group name+sequence number.rpt wheresequence number is a sequential number appended to aged files.

Do not edit these files.

Examples:

fin2.rpt

mgr4.rpt

dirsql Used by the triggen utility to store SQL scripts before triggenwas deprecated. Currently used to store training scripts and anyuser-created SQL scripts that support Oracle GoldenGate.

dirtmp The default location for storing transaction data when the sizeexceeds the memory size that is allocated for the cachemanager. Do not edit these files.

dirwlt Contains Oracle GoldenGate wallet files.

UserExitExamples Contains sample files to help with the creation of user exits.

A.3 Other Oracle GoldenGate FilesThis section describes other files, templates, and objects created or installed in theroot Oracle GoldenGate installation directory.

Appendix AOther Oracle GoldenGate Files

A-4

Note:

Some files may not be installed in your environment, depending on thedatabase and OS platform.

Table A-3 Other Oracle GoldenGate Installed Files

Component Description

bcpfmt.tpl Template for use with Replicat when creating a run file for theMicrosoft BCP/DTS bulk-load utility.

bcrypt.txt Blowfish encryption software license agreement.

cagent.dll Contains the Windows dynamic link library for the OracleGoldenGate Monitor C sub-agent.

category.dll Windows dynamic link library used by the INSTALL utility.

chkpt_db_create.sqlScript that creates a checkpoint table in the local database. Adifferent script is installed for each database type.

db2cntl.tpl Template for use with Replicat when creating a control file for theIBM LOADUTIL bulk-load utility.

ddl_cleartrace.sql Script that removes the DDL trace file. (Oracle installations)

ddl_ddl2file.sql Script that saves DDL from the marker table to a file.

ddl_disable.sql Script that disables the Oracle GoldenGate DDL trigger. (Oracleinstallations)

ddl_enable.sql Script that enables the Oracle GoldenGate DDL trigger. (Oracleinstallations)

ddl_filter.sql Script that supports filtering of DDL by Oracle GoldenGate. Thisscript runs programmatically; do not run it manually.

ddl_nopurgeRecyclebin.sql

Empty script file for use by Oracle GoldenGate support staff.

ddl_ora11.sql

ddl_ora12.sql

Scripts that run programmatically as part of Oracle GoldenGateDDL support; do not run these scripts.

ddl_pin.sql Script that pins DDL tracing, the DDL package, and the DDLtrigger for performance improvements. (Oracle installations)

ddl_purgeRecyclebin.sql Script that purges the Oracle recyclebin in support of the DDLreplication feature.

ddl_remove.sql Script that removes the DDL extraction trigger and package.(Oracle installations)

ddl_session.sql

ddl_session1.sql

Supports the installation of the Oracle DDL objects. This scriptruns programmatically; do not run it manually.

ddl_setup.sql Script that installs the Oracle GoldenGate DDL extraction andreplication objects. (Oracle installations)

ddl_status.sql Script that verifies whether or not each object created by theOracle GoldenGate DDL support feature exists and isfunctioning properly. (Oracle installations)

Appendix AOther Oracle GoldenGate Files

A-5

Table A-3 (Cont.) Other Oracle GoldenGate Installed Files

Component Description

ddl_staymetadata_off.sql

ddl_staymetadata_on.sql

Scripts that control whether the Oracle DDL trigger collectsmetadata. This script runs programmatically; do not run itmanually.

ddl_trace_off.sql

ddl_trace_on.sql

Scripts that control whether DDL tracing is on or off.

ddl_tracelevel.sql Script that sets the level of tracing for the DDL support feature.(Oracle installations)

debug files Debug text files that may be present if tracing was turned on.

demo_db_scriptname.sql

demo_more_db_scriptname.sql

Scripts that create and populate demonstration tables for usewith tutorials and basic testing.

.dmp files Dump files created by Oracle GoldenGate processes for tracingpurposes.

ENCKEYS User-created file that stores encryption keys. Written in externalASCII format.

exitdemo.c User exit example.

exitdemo_utf16.c User exit example that demonstrates how to use UTF16encoded data in the callback structures for informationexchanged between the user exit and the process.

freeBSD.txt License agreement for FreeBSD.

ggmessage.dat Data file that contains error, informational, and warningmessages that are returned by the Oracle GoldenGateprocesses. The version of this file is checked upon processstartup and must be identical to that of the process in order forthe process to operate.

ggserr.log File that logs processing events, messages, errors, andwarnings generated by Oracle GoldenGate.

ggsmsg.dll Windows dynamic link library used by the install program.

GLOBALS User-created file that stores parameters applying to the OracleGoldenGate instance as a whole.

help.txt Help file for the GGSCI command interface.

icudtxx.dll

icuinxx.dll

icuucxx.dll

Windows shared libraries for International Components forUnicode, where xx is the currently used version.

jagent.bat Windows batch file for the Java Agent for Oracle GoldenGateMonitor.

jagent.log

jagentjni.log

Log files for the Oracle GoldenGate Monitor Agent.

jagent.sh UNIX shell script for the Java Agent for Oracle GoldenGateMonitor

LGPL.txt Lesser General Public License statement. Applies to freelibraries from the Free Software Foundation.

Appendix AOther Oracle GoldenGate Files

A-6

Table A-3 (Cont.) Other Oracle GoldenGate Installed Files

Component Description

libodbc.so ODBC file for Ingres 2.6 on Unix.

libodbc.txt License agreement for libodbc.so.

libxml2.dll Windows dynamic link library containing the XML library for theOracle GoldenGate XML procedures.

libxml2.txt License agreement for libxml2.dll .

marker.hist File created by Replicat if markers were passed from a NonStopsource system.

marker_remove.sql Script that removes the DDL marker table. (Oracle installations)

marker_setup.sql Script that installs the Oracle GoldenGate DDL marker table.(Oracle installations)

marker_status.sql Script that confirms successful installation of the DDL markertable. (Oracle installations)

notices.txt Third-party software license file.

odbcinst.ini Ingres 2.6 on Unix ODBC configuration file.

params.sql Script that contains configurable parameters for DDL support.(Oracle installations)

pthread-win32.txt License agreement for pthread-VC.dll .

pthread-VC.dll POSIX threads library for Microsoft Windows.

prvtclkm.plb Supports the replication of Oracle encrypted data.

pw_agent_util.bat

pw_agent_util.sh

Script files that support the Oracle GoldenGate Monitor Agent.

role_setup.sql Script that creates the database role necessary for OracleGoldenGate DDL support. (Oracle installations)

sampleodbc.ini Sample ODBC file for Ingres 2.6 on UNIX.

sqlldr.tpl Template for use with Replicat when creating a control file for theOracle SQL*Loader bulk-load utility.

start.prm

stop.prm

z/OS paramlib members to start and stop the Manager process.

startmgr

stopmgr

z/OS Unix System Services scripts to start the Manager processfrom GGSCI.

startmgrcom

stopmgrcom

z/OS system input command for the Manager process.

tcperrs File containing user-defined instructions for responding toTCP/IP errors.

usrdecs.h Include file for user exit API.

xerces-c_2_8.dll Apache XML parser library.

zlib.txt License agreement for zlib compression library.

Appendix AOther Oracle GoldenGate Files

A-7

A.4 Oracle GoldenGate Checkpoint TableWhen database checkpoints are being used, Oracle GoldenGate creates a checkpointtable with a user-defined name in the database upon execution of the ADDCHECKPOINTTABLE command, or a user can create the table by using thechkpt_db_create.sql script (where db is an abbreviation of the type of database that thescript supports). For a description of this table, see Administering Oracle GoldenGatefor Windows and UNIX.

Appendix AOracle GoldenGate Checkpoint Table

A-8

Index

Ccluster

installing on, 2-6, 2-9cluster, running in, 2-4

Iinstalling on

Linux and UNIX, 2-4

installing on (continued)

LLinux, installing on, 2-4

UUNIX, installing on, 2-4

Index-1