Oracle® GoldenGate

Oracle Installation and Setup Guide

Release 11.2.1

E35957-01

August 2012

Oracle GoldenGate for Oracle Installation and Setup Guide, Release 11.2.1

E35957-01

Copyright © 2010, 2011, 2012, Oracle and/or its affiliates. All rightsreserved.

This software and related documentation are provided under a licenseagreement containing restrictions on

use and disclosure and are protected by intellectual property laws. Exceptas expressly permitted in your

license agreement or allowed by law, you may not use, copy, reproduce,translate, broadcast, modify,

license, transmit, distribute, exhibit, perform, publish, or display anypart, in any form, or by any means.

Reverse engineering, disassembly, or decompilation of this software,unless required by law for

interoperability, is prohibited.

The information contained herein is subject to change without notice andis not warranted to be error-free. If

you find any errors, please report them to us in writing.

If this software or related documentation is delivered to the U.S.Government or anyone licensing it on

behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and relateddocumentation and technical data

delivered to U.S. Government customers are "commercial computersoftware" or "commercial technical

data" pursuant to the applicable Federal Acquisition Regulation andagency-specific supplemental

regulations. As such, the use, duplication, disclosure, modification, andadaptation shall be subject to the

restrictions and license terms set forth in the applicable Governmentcontract, and, to the extent applicable

by the terms of the Government contract, the additional rights set forthin FAR 52.227-19, Commercial

Computer Software License (December 2007). Oracle USA, Inc., 500 OracleParkway, Redwood City, CA

94065.

This software is developed for general use in a variety of informationmanagement applications. It is not

developed or intended for use in any inherently dangerous applications, includingapplications which may

create a risk of personal injury. If you use this software in dangerousapplications, then you shall be

responsible to take all appropriate fail-safe, backup, redundancy, andother measures to ensure the safe use

of this software. Oracle Corporation and its affiliates disclaim anyliability for any damages caused by use of

this software in dangerous applications.

Oracle is a registered trademark of Oracle Corporation and/or itsaffiliates. Other names may be trademarks

of their respective owners.

This software and documentation may provide access to or information oncontent, products, and services

from third parties. Oracle Corporation and its affiliates are notresponsible for and expressly disclaim all

warranties of any kind with respect to third-party content, products, andservices. Oracle Corporation and

its affiliates will not be responsible for any loss, costs, or damagesincurred due to your access to or use of

third-party content, products, or services.

iii

Contents

Preface ................................................................................................................................................................xi

Audience......................................................................................................................................................xi

Documentation Accessibility.....................................................................................................................xi

Related Documents ...................................................................................................................................xii

Conventions...............................................................................................................................................xii

1 System requirements and preinstallationinstructions

Supported Platforms...............................................................................................................................1-1

Operating system requirements ............................................................................................................1-1

Memoryrequirements......................................................................................................................1-1

Diskrequirements.............................................................................................................................1-2

Temporary diskrequirements..........................................................................................................1-2

Network..............................................................................................................................................1-2

Operating system privileges.............................................................................................................1-3

Itanium requirements........................................................................................................................1-3

Console ...............................................................................................................................................1-3

Other programs.................................................................................................................................1-4

Database configuration ...........................................................................................................................1-4

Summary of supported Oracle data types andobjects per capture mode..................................... 1-5

Details of support for Oracle data types..............................................................................................1-7

Numeric datatypes...........................................................................................................................1-7

Character data types..........................................................................................................................1-7

Multi-byte character types ................................................................................................................1-7

Binary datatypes...............................................................................................................................1-8

Date and timestamp data types.......................................................................................................1-8

Large object datatypes......................................................................................................................1-8

XML data types.................................................................................................................................1-9

User defined or abstracttypes.......................................................................................................1-11

Non-supported Oracle data types................................................................................................1-12

Details of support for Oracle objects andoperations in DML..................................................... 1-12

Tables, views, and materializedviews.........................................................................................1-12

Sequences ........................................................................................................................................1-15

Non-supported objects and operations in Oracle DML............................................................ 1-15

Details of support for objects and operationsin Oracle DDL ..................................................... 1-16

Supported objects and operations in OracleDDL...................................................................... 1-16

iv

Non-supported objects and operations in OracleDDL............................................................. 1-17

Supported and non-supported object names...................................................................................1-18

2 Installing Oracle GoldenGate

Installation overview..............................................................................................................................2-1

Downloading Oracle GoldenGate ........................................................................................................2-1

Setting ORACLE_HOME and ORACLE_SID....................................................................................2-2

Specifying Oracle variables on UNIX and Linux systems........................................................... 2-2

Specifying Oracle variables on Windowssystems........................................................................2-3

Setting library paths for dynamic builds onUNIX...........................................................................2-3

Preparing to install Oracle GoldenGate withina cluster.................................................................2-5

Installing as the Oracleuser..............................................................................................................2-5

Supported Oracle clusterstorage.....................................................................................................2-5

Deciding where to install Oracle GoldenGate binaries and files in thecluster ........................ 2-6

Installing Oracle GoldenGate on Linux andUNIX...........................................................................2-6

Installing Oracle GoldenGate on Windows .......................................................................................2-7

Installing Oracle GoldenGate into a Windows Cluster................................................................ 2-7

Installing the Oracle GoldenGate files............................................................................................2-7

Specifying a custom Managername................................................................................................2-7

Installing Manager as a Windows service......................................................................................2-8

Integrating Oracle GoldenGate into a cluster ....................................................................................2-9

General requirements in acluster....................................................................................................2-9

Adding Oracle GoldenGate as a Windows cluster resource.................................................... 2-10

Installing support for Oracle sequences...........................................................................................2-10

3 Installing Oracle GoldenGate DDL supportfor an Oracle database

Overview of the DDL objects ................................................................................................................3-1

Installing the DDL objects .....................................................................................................................3-2

4 Configuring Oracle GoldenGate on Oraclesource and target databases

What to expect from this procedure......................................................................................................4-1

Creating and editing parameter files....................................................................................................4-1

Overview of basic steps to configure OracleGoldenGate...............................................................4-2

Choosing names for processes and files ..............................................................................................4-2

Choosing group names.....................................................................................................................4-2

Choosing filenames..........................................................................................................................4-3

Deciding which capture method to use ...............................................................................................4-3

About classiccapture........................................................................................................................4-3

About integratedcapture..................................................................................................................4-4

Combining capturemodes................................................................................................................4-5

Assigning a database user for OracleGoldenGate............................................................................4-6

Creating the Oracle GoldenGate instance...........................................................................................4-9

Configuring Extract for change capture............................................................................................4-10

Configuring the primary Extract (classic or integrated mode)................................................ 4-10

Configuring the data pump...........................................................................................................4-12

Configuring Replicat for change delivery........................................................................................4-14

v

Creating a checkpoint table...........................................................................................................4-14

Configuring Replicat.....................................................................................................................4-15

Tuning recommendations for integrated capture...........................................................................4-16

Configuring additional process groups forbest performance ..................................................... 4-17

Next steps in the deployment .............................................................................................................4-18

When to start replicating transactionalchanges .............................................................................4-18

Testing your configuration..................................................................................................................4-19

5 Preparing the database for OracleGoldenGate

Preparing integrity constraints in source andtarget tables ............................................................. 5-1

Disabling triggers and referential cascade constraints on targettables..................................... 5-1

Deferring constraint checking on target tables ..............................................................................5-2

Ensuring row uniqueness in source and targettables.................................................................. 5-3

Configuring logging properties.............................................................................................................5-4

EnablingFORCELOGGING.............................................................................................................5-4

Enabling schema-level supplemental logging ...............................................................................5-5

Enabling table-level supplementallogging....................................................................................5-5

Limiting row changes in tables that do nothave a unique row identifier ................................... 5-6

Supporting the conversion of character sets .......................................................................................5-6

Setting NLS_LANG with SETENV..................................................................................................5-7

Viewing globalization settings.........................................................................................................5-7

Getting more information about globalizationsupport............................................................... 5-7

Setting fetch options...............................................................................................................................5-7

Handling special data types ...................................................................................................................5-9

Multibyte character types.................................................................................................................5-9

Oracle Spatial objects.........................................................................................................................5-9

TIMESTAMP...................................................................................................................................5-10

Large Objects(LOB)........................................................................................................................5-11

XML..................................................................................................................................................5-11

User defined types..........................................................................................................................5-12

Handling other database properties ..................................................................................................5-12

Using Oracle GoldenGate with Oracle Exadata..............................................................................5-12

Migrating to OracleExadata..........................................................................................................5-13

Replicating to Exadata with EHCC enabled...............................................................................5-14

6 Additional configuration steps when usingclassic capture

Configuring Oracle TDE data in classiccapture mode..................................................................... 6-1

Overview of TDE support in classic capture.................................................................................6-1

Requirements for capturing TDE in classic capture mode.......................................................... 6-2

Required database patches...............................................................................................................6-2

Configuring TDEsupport.................................................................................................................6-2

Recommendations for maintaining data security afterdecryption............................................ 6-4

Performing DDL while TDE capture is active...............................................................................6-5

Updating the Oracle shared secret in the parameterfile.............................................................. 6-5

Using Oracle GoldenGate in an Oracle RACenvironment............................................................. 6-6

Capturing from an Oracle ASM instance when inclassic capture mode...................................... 6-7

vi

Accessing the transaction logs in ASM...........................................................................................6-7

Ensuring ASM connectivity..............................................................................................................6-8

Ensuring data availability......................................................................................................................6-8

Log retention requirements per Extract recovery mode.............................................................. 6-9

Log retentionoptions........................................................................................................................6-9

Determining how much data toretain.........................................................................................6-11

Purging log archives.......................................................................................................................6-11

Specifying the archive location.....................................................................................................6-11

Mounting logs that are stored on other platforms..................................................................... 6-11

Configuring Oracle GoldenGate to read onlythe archived logs................................................. 6-12

Limitations and requirements of ALOmode..............................................................................6-12

Configuring Extract for ALOmode..............................................................................................6-12

Avoiding log-read bottlenecks ...........................................................................................................6-13

7 Configuring DDL synchronization for anOracle database

Overview of DDL synchronization ......................................................................................................7-1

Limitations of Oracle GoldenGate DDL support ..............................................................................7-1

DDL statement length.......................................................................................................................7-1

Supportedtopologies........................................................................................................................7-2

Filtering, mapping, and transformation.........................................................................................7-2

Renames..............................................................................................................................................7-2

Interactions between fetches from a table andDDL..................................................................... 7-2

Comments in SQL ..............................................................................................................................7-3

Compilationerrors............................................................................................................................7-3

Interval partitioning..........................................................................................................................7-3

Configuration guidelines for DDL support ........................................................................................7-4

Database privileges............................................................................................................................7-4

Parallel processing.............................................................................................................................7-4

DDL and DML in data pumps.........................................................................................................7-4

Objectnames......................................................................................................................................7-4

Data definitions.................................................................................................................................7-5

Truncates ............................................................................................................................................7-5

Initialsynchronization......................................................................................................................7-5

Data continuity after CREATE or RENAME.................................................................................7-5

Understanding DDL scopes ...................................................................................................................7-6

Mappedscope....................................................................................................................................7-6

Unmappedscope...............................................................................................................................7-8

Other scope........................................................................................................................................7-8

Correctly identifying unqualified objectnames in DDL................................................................. 7-9

Enabling DDL support ............................................................................................................................7-9

Filtering DDL replication ....................................................................................................................7-10

Filtering with PL/SQL code ..........................................................................................................7-10

Adding and dropping filter rules.................................................................................................7-12

Filtering with the DDL parameter................................................................................................7-14

Combining DDL parameteroptions.............................................................................................7-20

Special filter cases ................................................................................................................................7-20

DDL EXCLUDEALL......................................................................................................................7-20

vii

Implicit DDL...................................................................................................................................7-21

How Oracle GoldenGate handles derived objectnames ..............................................................7-21

MAP exists for base object, but not derived object.................................................................... 7-22

MAP exists for base and derived objects .....................................................................................7-22

MAP exists for derived object, but not base object.................................................................... 7-23

New tables as derived objects .......................................................................................................7-23

Disabling the mapping of derivedobjects...................................................................................7-24

Using DDL string substitution...........................................................................................................7-25

Controlling the propagation of DDL that isexecuted by Replicat.............................................. 7-26

Propagating DDL in an active-active (bi-directional) configurations..................................... 7-26

Propagating DDL in a cascading configuration......................................................................... 7-28

Adding supplemental log groups automatically ............................................................................7-28

Removing comments from replicated DDL .....................................................................................7-29

Replicating an IDENTIFIED BY password......................................................................................7-29

How DDL is evaluated for processing ..............................................................................................7-29

Handling DDL processing errors .......................................................................................................7-31

Handling DDL trigger errors ..............................................................................................................7-31

Viewing DDL report information......................................................................................................7-32

Extract DDLreporting....................................................................................................................7-32

Replicat DDLreporting..................................................................................................................7-33

Statistics in the process reports.....................................................................................................7-34

Viewing metadata in the DDL history table....................................................................................7-34

Tracing DDL processing ......................................................................................................................7-34

Tracing the DDL trigger.......................................................................................................................7-34

8 Instantiating and starting OracleGoldenGate replication

Overview of basic Oracle GoldenGateinstantiation steps..............................................................8-1

Satisfying prerequisites for instantiation............................................................................................8-1

Configure change capture and delivery.........................................................................................8-1

Add collision handling......................................................................................................................8-1

Disable DDLprocessing....................................................................................................................8-2

Prepare the targettables....................................................................................................................8-2

Making the instantiation procedure moreefficient ..........................................................................8-2

Share parameters between process groups....................................................................................8-2

Use parallelprocesses.......................................................................................................................8-3

Configuring the initial load ...................................................................................................................8-3

To load with a database utility.........................................................................................................8-3

To direct bulk load toSQL*Loader..................................................................................................8-3

To load from an input file to SQL*Loader......................................................................................8-6

Registering Extract with the mining database....................................................................................8-8

Adding change-capture and change-deliveryprocesses...................................................................8-9

Set the RMAN archive log deletion policy.....................................................................................8-9

Add the primary Extract...................................................................................................................8-9

Add the localtrail...........................................................................................................................8-10

Add the data pump Extract group...............................................................................................8-10

Add the remote trail.......................................................................................................................8-11

Add the Replicatgroup..................................................................................................................8-11

viii

Performing the target instantiation ...................................................................................................8-11

To perform instantiation with a databaseutility........................................................................8-11

To perform instantiation with direct bulk load toSQL*Loader............................................... 8-13

To perform instantiation from an input fileto SQL*Loader........................................................ 8-14

Monitoring processing after the instantiation.................................................................................8-15

Backing up the Oracle GoldenGate environment ..........................................................................8-15

9 Controlling processes

When to start processes ...........................................................................................................................9-1

Starting processes after instantiation iscomplete .............................................................................9-1

10 Managing the Oracle DDL replicationenvironment

Enabling and disabling the DDL trigger..........................................................................................10-1

Maintaining the DDL marker table...................................................................................................10-1

Deleting the DDL marker table..........................................................................................................10-2

Maintaining the DDL history table ...................................................................................................10-2

Deleting the DDL history table ..........................................................................................................10-2

Purging the DDL trace file ..................................................................................................................10-3

Applying database patches and upgrades whenDDL support is enabled ............................... 10-3

Applying Oracle GoldenGate patches andupgrades when DDL support is enabled............ 10-3

Restoring an existing DDL environment to aclean state .............................................................. 10-4

Removing the DDL objects from the system...................................................................................10-6

11 Uninstalling Oracle GoldenGate

Stopping processes ...............................................................................................................................11-1

Removing the DDL environment.......................................................................................................11-1

Removing database objects .................................................................................................................11-2

(Windows) Removing Oracle GoldenGate Windowscomponents.............................................11-3

Removing the Oracle GoldenGate files............................................................................................11-3

A Configuring a downstream mining databasefor integrated capture

Evaluating capture options for a downstreamdeployment............................................................A-1

Preparing the Source Database for DownstreamDeployment......................................................A-1

Creating the source useraccount....................................................................................................A-2

Configuring redo transport from a source to the downstream miningdatabase.................... A-2

Preparing the downstream mining database .....................................................................................A-4

Creating the downstream mining user account........................................................................... A-4

Configuring the mining database to archive local redo log files.............................................. A-4

Preparing a downstream mining database for real-time capture.............................................. A-5

B Example configuration of downstream miningdatabase for integrated

capture

Example 1: Capturing from one source databasein real-time mode............................................ B-1

Prepare the mining database to archive its local redo.................................................................B-1

ix

Prepare the mining database to archive redo received in standby redo logsfrom the source

database B-2

Prepare the source database to send redo to the miningdatabase............................................ B-2

Set up integrated capture (ext1) onDBMSCAP............................................................................B-2

Example 2: Capturing from multiple sources inarchive-log-only mode .................................... B-3

Prepare the mining database to archive its localredo................................................................. B-3

Prepare the mining database to archive redo from the source database.................................. B-4

Prepare the first source database to send redo to the miningdatabase.................................... B-4

Prepare the second source database to send redo to the mining database.............................. B-4

Set up Extracts at the downstream mining database..................................................................B-5

Example 3: Capturing from multiple sourceswith mixed real-time

and archive-log-only mode....................................................................................................................B-6

Prepare the mining database to archive its localredo................................................................. B-6

Prepare the mining database to accept redo from the source databases.................................. B-7

Prepare the first source database to send redo to the miningdatabase.................................... B-7

Prepare the second source database to send redo to the mining database.............................. B-8

Prepare the third source database to send redo to the mining database.................................. B-8

Set up Extracts at downstream mining database......................................................................... B-9

C Supporting changes to XML schemas

Supporting RegisterSchema.................................................................................................................C-1

Supporting DeleteSchema:...................................................................................................................C-1

Supporting CopyEvolve........................................................................................................................C-1

D Preparing DBFS for active-activepropagation with Oracle GoldenGate

Supported operations and prerequisites ............................................................................................D-1

Applying the required patch.................................................................................................................D-1

Examples used in these procedures .....................................................................................................D-2

Partitioning the DBFS sequence numbers .........................................................................................D-2

Configuring the DBFS filesystem........................................................................................................D-3

Mapping local and remote peers correctly .........................................................................................D-4

E Oracle GoldenGate installed components

Oracle Goldengate Programs And Utilities .......................................................................................E-1

Oracle Goldengate Subdirectories.......................................................................................................E-2

Other Oracle GoldenGate files.............................................................................................................E-4

Oracle GoldenGate checkpoint table ..................................................................................................E-8

x

Preface

With Oracle GoldenGate for Oracle, you can:

■ Map, filter, and transform transactional data changesbetween similar or dissimilar

supported Oracle versions, and between supported Oracle versions and other

supported types of databases.

■ Replicate and filter Oracle DDL operations betweenheterogeneous Oracle

databases.

■ Perform initial loads to target tables in Oracle or otherdatabases to instantiate a

synchronized replication environment.

This guide helps you get started with installing, configuring, and runningOracle

GoldenGate on an Oracle database system. It helps you produce a basicOracle

GoldenGate configuration, from source to target, that is tailored to theOracle

environment. Where needed, it points you to other documentation where youcan find

additional information to expand the configuration to suit your needs.

Audience

This guide is intended for installers, database administrators, and system

administrators who are installing, configuring and running OracleGoldenGate.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit theOracle

Accessibility Program website at

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers have access to electronic support through My OracleSupport. For

information, visit

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoor visit

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsif you are

hearing impaired.

Related Documents

The complete Oracle GoldenGate documentation set includes the following

components:

HP NonStop Platform

■ Oracle GoldenGate forNonStop Reference Guide

■ Oracle GoldenGate forNonStop Administrator's Guide

Windows, UNIX, and Linux Platforms

■ Oracle GoldenGateInstallation and Setup Guides per supported database

■ Oracle GoldenGate Windowsand UNIX Administrator’s Guide

■ Oracle GoldenGate Windowsand UNIX Reference Guide

■ Oracle GoldenGate Windowsand UNIX Troubleshooting and Tuning Guide

■ Oracle GoldenGate UpgradeGuide

Other Oracle GoldenGate Products

■ Oracle GoldenGate Adapterfor Flat Files Administrator’s Guide

■ Oracle GoldenGate Adapterfor Java Administrator’s Guide

■ Oracle GoldenGate DirectorAdministrator’s Guide

■ Oracle GoldenGate MonitorAdministrator’s Guide

■ Oracle GoldenGate VeridataAdministrator’s Guide

Conventions

The following text conventions are used in this document:

Convention Meaning

boldface Boldface type indicates graphicaluser interface elements associated

with an action, such as "From the File menu, select Save." Boldface also

is used for terms defined in text or in the glossary.

italic

italic

Italic type indicates placeholder variables for which you supply

particular values, such as in the parameter statement: TABLE table_

name. Italic type also is used for book titles and emphasis.

monospace

MONOSPACE

Monospace type indicates code components such as user exits and

scripts; the names of files and database objects; URL paths; and input

and output text that appears on the screen. Uppercase monospace type

is generally used to represent the names of Oracle GoldenGate

parameters, commands, and user-configurable functions, as well as

SQL commands and keywords.

UPPERCASE Uppercase in the regular text font indicates the name of autility unless

the 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

this syntax, the SAVE clause isoptional: CLEANUP REPLICATgroup_

name [, SAVE count]. Multiple options within anoptional element

are separated by a pipe symbol, for example: [option1 | option2].

Convention Meaning

 

1

System requirementsand preinstallation instructions 1-1

1Systemrequirements and preinstallation

instructions

This chapter contains the requirements for the system and databaseresources that

support Oracle GoldenGate.

1.1 Supported Platforms

To find out which Oracle GoldenGate builds are available for a specificcombination of

database version and operating system, log onto http://support.oracle.com

and select the Certifications tab. For assistance, click Tipsfor Finding Certifications.

An e-mail and password are required to enter this site.

1.2 Operating system requirements

This section outlines the operating system resources that are necessary tosupport

Oracle GoldenGate.

1.2.1 Memory requirements

The amount of memory that is required for Oracle GoldenGate depends on the

number of concurrent processes that will be running. At minimum on thesource

system, there is a primary Extract process that captures source data and asecondary

Extract data-pump process that transfers data across the network. Atminimum on the

target system is at least one Replicat process that applies the replicateddata to the

target database. In some cases, these processes might all operate on thesame system,

depending on the required configuration.

It is possible that you will need to use additional, parallel processes toimprove

throughput if your environment generates a large volume of transactionaldata that

must be replicated. Oracle GoldenGate supports up to 5,000 concurrentExtract and

Replicat processes per instance of Oracle GoldenGate. Each Extract andReplicat

process needs approximately 25-55 MB of memory, or more depending on thesize of

the transactions and the number of concurrent transactions.

The actual amount of physical memory that is used by any Oracle GoldenGateprocess

is controlled by the operating system, not the Oracle GoldenGate program.The Oracle

Note: Oracle GoldenGate supports twocapture modes for an Oracle

source database. Some system requirements may vary depending on

the capture mode that is selected. To learn about the capture modes,

see "Decidingwhich capture method to use" on page 4-3.

Operating system requirements

1-2 Oracle GoldenGate for Oracle Installation and Setup Guide

GoldenGate cache manager takes advantage of the memory managementfunctions of

the operating system to ensure that Oracle GoldenGate processes work in asustained

and efficient manner. For more information about evaluating OracleGoldenGate

memory requirements, see the CACHEMGR parameter inthe Oracle GoldenGate Windows

and UNIX Reference Guide.

1.2.2 Disk requirements

Assign the following free disk space:

■ 50-150 MB, depending on the database and platform. Thisincludes space for the

compressed download file and space for the uncompressed files. You candelete

the download file after the installation is complete.

■ 40 MB for the working directories and binaries for eachinstance of Oracle

GoldenGate that you are installing on the system. For example, to installtwo

builds of Oracle GoldenGate into two separate directories, allocate 80 MBof space.

■ To install Oracle GoldenGate into a cluster environment,install the Oracle

GoldenGate binaries and files as the Oracle user on a shared file systemthat is

available to all cluster nodes. See "Preparing to installOracle GoldenGate within a

cluster" on page 2-5 for more information.

■ An additional 1 GB of disk space on any system that hostsOracle GoldenGate

trails, which are files that contain the working data. You may need moreor less

than this amount, because the space that is consumed by the trails dependson the

volume of data that will be processed. See the guidelines for sizingtrails in the

Oracle GoldenGate Administrator's Guide.

1.2.3 Temporary disk requirements

By default, Oracle GoldenGate maintains data that it swaps to disk in the dirtmp

sub-directory of the Oracle GoldenGate installation directory. The cachemanager

assumes that all of the free space on the file system is available. Thisdirectory can fill

up quickly if there is a large transaction volume with large transactionsizes. To

prevent I/O contention and possible disk-related Extract failures,dedicate a disk to

this directory. You can assign a name to this directory with the CACHEDIRECTORY option

of the CACHEMGR parameter.

1.2.4 Network

The following network resources must be available to support OracleGoldenGate.

■ For optimal performance and reliability, especially inmaintaining low latency on

the target, use the fastest network possible and install redundancies atall points of

failure.

■ Configure the system to use TCP/IP services, includingDNS. Oracle GoldenGate

supports IPv4 and IPv6 and can operate in a system that supports one orboth of

these protocols.

■ Configure the network with the host names or IP addressesof all systems that will

be hosting Oracle GoldenGate processes and to which Oracle GoldenGate willbe

connecting. Host names are easier to use.

■ Oracle GoldenGate requires some unreserved andunrestricted TCP/IP ports, the

number of which depends on the number and types of processes in your

configuration. See the Oracle GoldenGate Windows and UNIX Administrator'sGuide

for details on how to configure the Manager process to handle the requiredports.

Operating system requirements

System requirementsand preinstallation instructions 1-3

■ Keep a record of the ports that you assigned to OracleGoldenGate. You will

specify them with parameters when configuring the Manager process.

■ Configure your firewalls to accept connections throughthe Oracle GoldenGate

ports.

1.2.5 Operating system privileges

The following are the privileges in the operating system that are requiredto install

Oracle GoldenGate and to run the processes.

■ To install on Windows, the person who installs OracleGoldenGate must log in as

Administrator.

■ To install on UNIX, the person who installs OracleGoldenGate must have read

and write privileges on the Oracle GoldenGate installation directory.

■ The Oracle GoldenGate Extract, Replicat, and Managerprocesses must operate as

an operating system user that has privileges to read, write, and deletefiles and

subdirectories in the Oracle GoldenGate directory. In addition, theManager

process requires privileges to control the other Oracle GoldenGateprocesses.

■ (Classic capture mode) In classic capture mode, theExtract process reads the redo

logs directly and must operate as an operating system user that has readaccess to

the log files, both online and archived. On UNIX systems, that user mustbe a

member of the group that owns the Oracle instance. If you install theManager

process as a Windows service during the installation steps in thisdocumentation,

you must install as Administrator for the correct permissions to beassigned. If you

cannot install Manager as a service, assign read access to the Extractprocess

manually, and then always run Manager and Extract as Administrator.

■ Dedicate the Extract, Replicat, and Manager operatingsystem users to Oracle

GoldenGate. Sensitive information might be available to anyone who runs an

Oracle GoldenGate process, depending on how database authentication is

configured.

1.2.6 Itanium requirements

To install Oracle GoldenGate on a Microsoft Itanium system, the vcredist_IA64.exe

runtime library package must be installed. You can download this packagefrom the

Microsoft website. This package includes VisualStudio DLLs necessary forOracle

GoldenGate to operate on the Itanium platform. If these libraries are notinstalled,

Oracle GoldenGate generates the following error.

Theapplication failed to initialize properly (0xc0150002). Click on Ok to

terminatethe application.

1.2.7 Console

The operating system and the command console must have the same charactersets.

Mismatches occur on Microsoft Windows systems, where the operating systemis set

to one character set, but the DOS command prompt uses a different, olderDOS

character set. Oracle GoldenGate uses the character set of the operatingsystem to send

information to GGSCI command output; therefore a non-matching consolecharacter

set causes characters not to display correctly. You can set the characterset of the

console before opening a GGSCI session by using the following DOS command:

chcp OS character set

Database configuration

1-4 Oracle GoldenGate for Oracle Installation and Setup Guide

If the characters do not display correctly after setting the code page,try changing the

console font to Lucida Console, which has an extended character set.

1.2.8 Other programs

The following are additional considerations in support of Oracle GoldenGate.

■ Before installing Oracle GoldenGate on a Windows system,install and configure

the Microsoft Visual C ++ 2005 SP1 Redistributable Package. Makecertain it is the

SP1 version of this package, and make certainto get the correct bit version for

your server. This package installs runtimecomponents of Visual C++ Libraries.

For more information, and to download this package, go to

http://www.microsoft.com.

■ Oracle GoldenGate fully supports virtual machineenvironments created with any

virtualization software on any platform. When installing Oracle GoldenGateinto a

virtual machine environment, select a build that matches the database andthe

operating system of the virtual machine, not the host system. For example,on a

Windows system with a RHAS 4.0 virtual machine running Oracle11g, youwould

install the RHAS 4.0 build for Oracle 11g, just as you would on an actualLinux

machine.

1.3 Database configuration

This section contains Oracle GoldenGate requirements that are specific tothe Oracle

database.

■ To run Oracle GoldenGate for multiple Oracle instances ona Windows system,

you must install an instance of Oracle GoldenGate for each one

■ On 64-bit Sun Solaris, HP Tru64 (OSF/1), and LINUXmachines with 32-bit Oracle

databases, Oracle GoldenGate requires LD_LIBRARY_PATH to include the 32-bit

Oracle libraries. You will be instructed to set LD_LIBRARY_PATH in "Setting library

paths for dynamic builds on UNIX" on page 2-3.

■ If the database is configured to use a bequeathconnection, the sqlnet.orafile

must contain the bequeath_detach=true setting.

■ (Integrated capture mode) Oracle GoldenGate 11.2.1introduced integrated

capture support for Oracle 11.2.0.3 with the 11.2.0.3 Database specificbundle patch

for Integrated Extract 11.2.x (Doc ID 1411356.1). This mode makes use of a

logmining server on the source system or in a downstream Oracle database.For

more information, see "Deciding which capture method to use" on page 4-3.

■ The full Oracle client must be used with OracleGoldenGate so that the Oracle

GoldenGate programs have access to the Oracle XDK libraries. Do not useOracle

Instant Client, which lacks those libraries. You can download the fullclient from

the Oracle website.

■ To install Oracle GoldenGate in an Oracle RealApplication Cluster (RAC)

environment, install Oracle GoldenGate on the shared drive(s) that areaccessed by

the RAC nodes. For more information, see "Preparing to installOracle GoldenGate

within a cluster" on page 2-5.

■ Additional database user privileges and configurationrequirements are explained

elsewhere in this manual.

Summary of supported Oracle data types and objects percapture mode

System requirementsand preinstallation instructions 1-5

1.4 Summary of supported Oracle data typesand objects per capture

mode

This section contains summary and detail information about the way thatOracle

GoldenGate supports the Oracle data types according to the capture modethat you

choose. For more information about capture modes, see "Deciding which capture

method to use" on page 4-3.

Detailed support information for Oracle data types, objects, andoperations starts with

"Details of support for Oracle data types" on page 1-7.

Table 1–1 Supported data types per capturemode

Data type Classic capture Integrated capture

Scalar columns including

DATE and DATETIME

columns

Captured from redo. Captured from redo.

BASICFILELOB columns LOBmodifications done via DML

(INSERT/UPDATE/DELETE) are captured

from redo.

LOB modifications done via DBMS_LOB

package are captured by fetching values

from the base table.

All LOB modifications (done via DML

and those done via DBMS_LOB package) are

captured from redo.

SECUREFILELOB SECUREFILE LOBs are only captured from

redo if LOBs are not transformed (such as

not compressed or encrypted) and stored

out of row, and if the modification is done

via DML statements.

LOBs are fetched from the base table for

the following cases:

■ LOB is encrypted

■ LOB is compressed

■ LOB is stored in-line

■ LOB is modified via DBMS_LOB

package

■ LOB is deduplicated

■ LOB is modified via fragment

operations

■ NOLOGGING LOBs

SECUREFILELOBs arecaptured from redo

except for the following cases:

■ LOB is deduplicated

■ LOB is modified via fragment

operations

■ NOLOGGING LOBs

LOBs are fetched from the base table for

the following cases:

■ LOB is deduplicated

■ LOB is modified via fragment

operations

■ NOLOGGING LOBs

Requires source database COMPATIBLE

setting to be 11.2.0.0.0 or higher.

Index Organized Tables

(IOT)

Captured from redo with the following

restrictions:

■ IOT with mapping table not

supported.

■ Direct load inserts to IOT tables

cannot have the SORTED clause.

■ IOT with prefix compression as

specified with COMPRESSclause is not

supported.

Captured from redo.

XML stored as CLOB ■ Captured from redo. Captured from redo.

Requires source database compatibility to

be set to 11.0.0.0.0 or higher.

Summary of supported Oracle data types and objects percapture mode

1-6 Oracle GoldenGate for Oracle Installation and Setup Guide

XML stored as Binary Fetched from base table. Captured from redo.

Requires source database compatibility to

be set to 11.2.0.3.0 or higher.

XML stored as

Object-Relational

Not supported. Captured from redo.

Requires source database compatibility to

be set to 11.2.0.3.0 or higher.

XMLType Table Not supported. Captured from redo.

ADT (Abstract Data Type) Fetched from source table. Fetched from sourcetable.

Requires source database compatibility to

be set to 11.2.0.3.0 or higher.

Collections (VARRAYs) Fetched from source table. Fetched from sourcetable.

Requires source database compatibility to

be set to 11.2.0.0.0 or higher.

Collections (Nested

Tables)

Fetched from source table with

limitations.

See "Detailsof support for Oracle objects

and operations in DML" on page 1-12.

Fetched from source table with

limitations.

See "Detailsof support for Oracle objects

and operations in DML" on page 1-12.

Object Table Fetched from source table. Fetched from source table.

Transparent Data

Encryption (Column

Encryption & Tablespace

Encryption)

Captured from redo.

Requires additional setup: See

"Configuring Oracle TDE data in classic

capture mode" on page 6-1.

Captured from redo.

No additional setup is required.

Requires source database compatibility to

be set to 11.0.0.0.0 or higher.

Basic Compression Not supported. Captured from redo.

Requires source database compatibility to

be set to 11.2.0.0.0 or higher.

OLTP-Compression Not supported. Captured from redo.

Requires source database compatibility to

be set to 11.2.0.0.0 or higher.

Exadata Hybrid Columnar

Compression

Not supported. Captured from redo.

Requires source database compatibility to

be set to 11.2.0.0.0 or higher.

XA on non-RAC database Captured from redo. Captured from redo.

XA on RAC database Not supported.

To get support, must make sure all

branches of XA goes to the same instance.

Captured from redo.

Requires source database compatibility to

be set to 11.2.0.0.0 or higher.

PDML on non-RAC

database

Captured from redo. Captured from redo.

PDML on RAC database Not supported.

To get support, must make sure child

transactions spawned from a PDML

transaction does not span multiple

instances.

Captured from redo.

Table 1–1 (Cont.) Supported data types percapture mode

Data type Classic capture Integrated capture

Details of support for Oracle data types

System requirementsand preinstallation instructions 1-7

1.5 Details of support for Oracle data types

The following outlines details of Oracle data type support by Oracle GoldenGate.

Unless otherwise noted, the support applies to both classic and integratedcapture

mode. For more information about these modes, see "Configuring OracleGoldenGate

on Oracle source and target databases" on page 4-1.

1.5.1 Numeric data types

The following numeric data types are supported:

■ NUMBER up to themaximum size permitted by Oracle

■ BINARY FLOAT

■ BINARY DOUBLE

1.5.1.1 Limitations of support

The support of range and precision for floating-point numbers depends onthe host

machine. In general, the precision is accurate to 16 significant digits,but you should

review the database documentation to determine the expectedapproximations. Oracle

GoldenGate rounds or truncates values that exceed the supported precision.

1.5.2 Character data types

The following character data types are supported:

■ CHAR

■ VARCHAR2

■ LONG

■ NCHAR

■ NVARCHAR2

1.5.3 Multi-byte character types

The following multi-byte character types are supported:

■ NCHAR and NVARCHAR2 multi-byte character data types

■ Multi-byte data stored in CHAR and VARCHAR2 columns

1.5.3.1 Limitations of support

■ For Oracle GoldenGate to support multi-byte characterdata, the source and target

databases must be logically identical in terms of schema definition forthe tables

and sequences being replicated. Transformation, filtering, and othermanipulation

are not supported. The character sets between the two databases must beone of

the following:

– Identical, for example SHIFT-JIS onthe source and on the target.

– Equivalent, which is not the samecharacter set but containing the same set of

characters, for example SHIFT-JIS and EUC-JP.

– Target is superset of the source:For example, UNICODE is a superset of all

character types, and therefore of any other character set.

Details of support for Oracle data types

1-8 Oracle GoldenGate for Oracle Installation and Setup Guide

■ Multi-byte data is supported whether the length semanticsare in bytes or

characters.

For additional configuration requirements, see "Handling special datatypes" on

page 5-9.

1.5.4 Binary data types

The following binary data types are supported:

■ RAW

■ LONG RAW

1.5.5 Date and timestamp data types

The following date and time data types are supported:

■ DATE

■ TIMESTAMP (see Limitations of support)

1.5.5.1 Limitations of support

■ Oracle GoldenGate does not support negative dates.

■ INTERVAL DAY and INTERVAL YEAR are supported only if the size ofthe target

column is equal to, or greater than, that of the source.

■ Oracle GoldenGate supports the capture and replication ofTIMESTAMP WITH TIME

ZONE as a UTC offset (TIMESTAMP '2011-01-01 8:00:00 -8:00').

■ TIMESTAMP WITH TIME ZONE as TZR (Region ID) issupported for the replication of

data changes, but not for initial loads, for SQLEXEC, or for operations where the

column must be fetched from the database. In these cases, the region ID is

converted to a time offset by the database when the column is selected.Replicat

replicates the timestamp as date and time data with a time offset value.

To support TIMESTAMPWITH TIME ZONE specified as TZR properly, and also to handle

TIMESTAMPWITH LOCAL TIMEZONE properly, see the "Handling special data types" on

page 5-9.

1.5.6 Large object data types

The following large object types are supported:

■ CLOB

■ NCLOB

■ BLOB

■ SECUREFILE and BASICFILE are both supported.

1.5.6.1 General limitations of support -integrated and classic capture modes

When the size of a large object exceeds 4K, Oracle GoldenGate stores thedata in

segments within the Oracle GoldenGate trail. The first 4K is stored in thebase

segment, and the rest is stored in a series of 2K segments. OracleGoldenGate does not

support the filtering, column mapping, or manipulation of large objects ofthis size.

Full Oracle GoldenGate functionality can be used for objects that are 4Kor smaller.

Details of support for Oracle data types

System requirementsand preinstallation instructions 1-9

1.5.6.2 Limitations of support - classiccapture mode

■ BASICFILE LOBs are captured from the redo log regardless of storage, but are

fetched from the database in the following circumstances:

– Extract determines the LOB isinvalid.

– The LOB data is not in the redo log,which occurs when the BASICFILE LOB is

created with the no_logging option.

– The LOB is created with the CACHE attribute.

– The LOB is only partially updated.Oracle GoldenGate does not support

partial column data. Extract assumes LOB data to be incomplete if the LOB

does not start with a LOB reset record, or if the LOB does not start atthe first

byte and does not end at the last byte, according to the new LOB length.

Partial updates can be generated by the following OCI calls: OCILOBWrite(),

OCILobAppend(), OCiLobCopy(), OCILobLoadFromFile(), OCILobTrim(), and

by updates made through procedures in the dbms_lob package.

– Extract detects an anomaly in theLOB data, such as a missing page number,

missing END MARKER, or a mismatch between the sizethat was captured and

the expected size.

■ SECUREFILE LOBs are captured from the redo logs only when the update is

complete and the LOB is not transformed (the column is not compressed or

encrypted or deduplicated) and stored out-of-row. SECUREFILE LOBs are fetched

from the database in the following circumstances:

– The LOB is stored in-row.

– The LOB is transformed either withcompression or encryption.

– The LOB is created with the CACHE attribute.

– Extract determines that a LOBinstance is invalid.

– LOB data is missing from the redolog. This can occur if the LOB is created

with any of following options: deduplicate, no_logging, filesystem_like_

logging.

– The LOB is updated using OCILOBWrite(), OCILobAppend(), OCiLobCopy(),

OCILobLoadFromFile(), OCILobTrim(), or through procedures in the dbms_lob

package.

– Any other anomalies as detected byExtract in terms of a missing page

number, a missing END MARKER, or a mismatch between the size that was

captured and the expected size.

■ When changing a SECUREFILE LOB from one storage to another (such as from

ENCRYPT to DECRYPT), Oracle updates the whole table,and Extract captures those

updates from the log. Therefore, it will appear as though Oracle updatedall of the

data blocks that are associated with the table. This also can happen whenan ALTER

TABLE command sets a DEFAULT value to a column that has nullvalues.

For additional setup requirements, see "Handling special datatypes" on page 5-9.

1.5.7 XML data types

The following XML types are supported:

■ In integrated capture mode, Oracle GoldenGate supports XMLType columns and

XMLType tables stored as XML CLOB, XML Object Relational, and XML Binary.

Details of support for Oracle data types

1-10 Oracle GoldenGate for Oracle Installation and Setup Guide

■ In classic capture mode, Oracle GoldenGate supports XMLType columns and

XMLType tables stored as XML CLOB and XML Binary.

1.5.7.1 Limitations of support - integratedand classic capture modes

■ Oracle GoldenGate treats XMLType data as a LOB.

■ The source and target objects that contain the XML mustbe identical. Filtering and

manipulation are not supported. You can map the XML representation of anobject

to a character column by means of a COLMAP clause in a TABLE or MAP statement.

■ The following are not supported:

– Hierarchy-enabled tables (these aremanaged by the Oracle XML database

repository.)

– XMLType tables created from a CTAS (CREATE TABLE AS SELECT) statement that

populates the table. Assuming DDL support is enabled, Oracle GoldenGate

replicates the CTAS statement and allows it to selectthe data from the

underlying target table(s). The original inserts are not replicated. For XMLType

tables, the row object IDs must match between source and target, which

cannot be maintained when Replicat uses logical SQL statements. XMLType

tables created by an empty CTAS statement (thatdoes not insert data in the

new table) can be maintained correctly.

– XMLType tables with primary key-based objectidentifiers (OID)

– Non-XMLType tables with a single XML column

– SQL*Loader direct-path insert for XML Binary and XML Object Relational

■ XMLSchema-based XMLType tables andcolumns are supported, but changes made

to XMLSchemas are not replicated and must be registered on both source and

target databases with the dbms_xml package.

■ Supported tables must have at least one unique keyconstraint that is made up of

scalar columns, or the combination of all scalar columns must guarantee

uniqueness. Extract or Replicat cannot use unique or primary keyconstraints

made up of XML attributes for row identification purposes.

1.5.7.2 Limitations of support - integratedcapture mode

■ The Oracle database must be release 11.2.0.3 or higher,and Extract must be

configured in integrated capture mode.

■ The maximum length for the entire SET value of an update to an XMLType is 32K,

including the new content plus other operators and XQuery bind values.

1.5.7.3 Limitations of support - classiccapture mode

■ For XML Binary, Oracle GoldenGate fetches additional row data from the source

database because the redo log does not contain enough information. Becausethe

fetched data is not part of the original transaction, it may lead toinconsistency.

■ A table that contains XMLType columns must have one of thefollowing: a primary

key, column(s) with a unique constraint, or a unique index.

See "Handlingspecial data types" on page 5-9 for aditional information about

replicating XML.

Details of support for Oracle data types

System requirementsand preinstallation instructions 1-11

1.5.8 User defined or abstract types

Oracle GoldenGate supports user defined types (UDT) or abstract data types(ADT)

when the source and target objects have the same structure. The schemanames can be

different.

1.5.8.1 General limitations of support -integrated and classic capture modes

■ Because a UDT must be fetched, a table that contains onemust have one of the

following: a primary key, column(s) with a unique constraint, or a uniqueindex.

■ Oracle GoldenGate does not support UDTs with thefollowing embedded scalar

types: CLOB, CFILE, BFILE, or INTERVAL_YM, INTERVAL_DS, and OPAQUE (with the

exception of XMLType, which is supported).

■ Object or relational tables where the key contains a UDT,or where a UDT is the

only column, are not supported.

■ The RMTTASK parameter doesnot support user-defined types (UDT).

■ CHAR and VARCHAR attributes that contain binary orunprintable characters are not

supported.

■ UDTs, including values inside object columns or rows,cannot be used within

filtering criteria in TABLE or MAP statements, or as input or outputfor the Oracle

GoldenGate column-conversion functions, SQLEXEC, or other built-in

data-manipulation tools. Support is only provided for like-to-like Oraclesource

and targets.

■ Oracle GoldenGate does not support REF types.

For additional setup requirements, see "Handling special datatypes" in Chapter 5.

1.5.8.2 Limitations for collection types -integrated and classic capture modes

■ When data in a nested table is updated, the row thatcontains the nested table

must be updated at the same time.

■ When VARRAYS and nestedtables are fetched, the entire contents of the column are

fetched each time, not just the changes.

1.5.8.3 Limitations for object tables- -integrated and classic capture modes

■ Oracle GoldenGate supports object tables inuni-directional and active-active

configurations. Object tables are captured from the redo log, but certaindata types

that are fetched from the database when in regular relational tables, suchas LOBs

and collection types, are also fetched when in object tables. Similarly,current

limitations that apply to collection types when in regular tables alsoapply to these

types when in object tables.

■ An Oracle object table can be mapped to a non-Oracleobject table in a supported

target database.

■ A primary key must be defined on the root-level objectattributes of the object

table, and cannot include leaf-level attributes. If no key is defined,Oracle

GoldenGate will use all viable columns as a pseudo-key.

■ Oracle GoldenGate does not support the replication of DDLoperations for an

object table. This limitation includes the database object versioning thatis

associated with ALTERs of objecttables.

■ Synonyms are not supported for object tables orrelational tables that contain

object tables.

Details of support for Oracle objects and operations inDML

1-12 Oracle GoldenGate for Oracle Installation and Setup Guide

1.5.8.4 Limitations for spatial types -integrated and classic capture modes

Oracle GoldenGate supports SDO_GEOMETRY, SDO_TOPO_GEOMETRY, and SDO_GEORASTER

(raster tables).

See additional configuration information in "Handling special datatypes" on page 5-9.

1.5.9 Non-supported Oracle data types

Oracle GoldenGate does not support the following data types.

■ Abstract data types (ADT) with scalar, LOBs, VARRAYS, nested tables, and/or

REFsANYDATA

■ ANYDATASET

■ ANYTYPE

■ BFILE

■ MLSLABEL

■ ORDDICOM

■ TIMEZONE_ABBR

■ URITYPE

■ UROWID

See additional exclusions in the Limitations of support sections in "Summary of

supported Oracle data types and objects per capture mode" on page 1-5.

1.6 Details of support for Oracle objects andoperations in DML

This section outlines the Oracle objects and operations that OracleGoldenGate

supports for the capture and replication of DML operations.

1.6.1 Tables, views, and materialized views

Oracle GoldenGate supports the following DML operations made to regulartables,

index-organized tables, clustered tables, and materialized views.

■ INSERT

■ UPDATE

■ DELETE

■ Associated transaction control operations

1.6.1.1 Limitations of support for regulartables

These limitations apply to integrated and classic capture modes.

■ Oracle GoldenGate supports tables that contain any numberof rows up to 2 MB in

length. Each character LOB/LONG column contributes up to 4 KB to thislimit,

and each binary LOB column contributes up to 8 KB. This row-sizelimitation

mostly affects update operations on columns that are being used as a row

identifier. This identifier can be a primary or unique key, a key definedwithin the

Oracle GoldenGate parameter file, or all of the columns if no key isdefined. If a

row identifier is updated, the 2 MB length must include not only the afterimage,

but also the full before image, which is required to find the correct keyon the

target for the update.

Details of support for Oracle objects and operations inDML

System requirementsand preinstallation instructions 1-13

■ Oracle GoldenGate supports the maximum number of columnsper table that is

supported by the database.

■ Oracle GoldenGate supports the maximum column size thatis supported by the

database.

■ Oracle GoldenGate supports tables that contain only onecolumn, except when the

column contains one of the following data types:

– LOB

– LONG

– Nested table

– User defined data type

– VARRAY

– XML

■ Oracle GoldenGate supports tables with unused columns,but the support is

disabled by default, and Extract abends on them. See "Handling other database

properties" on page 5-12.

■ Oracle GoldenGate supports tables with these partitioningattributes:

– Range partitioning

– Hash Partitioning

– Interval Partitioning

– System Partitioning

– Composite Partitioning

– Virtual Column-Based Partitioning

– Reference Partitioning

– List Partitioning

See "Handlingother database properties" on page 5-12.

■ Oracle GoldenGate supports tables with virtual columns,but does not capture

change data for these columns or apply change data to them: The databasedoes

not write virtual columns to the transaction log, and the Oracle databasedoes

permit DML on virtual columns. For the same reason, initial load datacannot be

applied to a virtual column. You can map the data from virtual columns to

non-virtual target columns. See "Handling other database properties" on

page 5-12.

■ Oracle GoldenGate ignores any virtual column that is partof a unique key or

index. If a virtual column is the only unique identifier for a table,Oracle

GoldenGate uses all of the remaining columns for row identification, so itis

possible that the wrong target rows could be deleted or updated if theremaining

columns do not enforce uniqueness.

■ Oracle GoldenGate supports replication to and from OracleExadata. See "Using

Oracle GoldenGate with Oracle Exadata" on page 5-12.

■ Oracle GoldenGate supports Transparent Data Encryption(TDE). For integrated

capture, the source database must be Oracle version 11.1.0 withcompatibility

setting of 11.0.0.0 or higher. Column-level encryption is supported forall versions

of Oracle 10.2.0.5, 11.1, and 11.2. Tablespace-level encryption issupported for all

versions of Oracle 10.2.0.5 and 11.2.0.1. TDE is supported without setup

Details of support for Oracle objects and operations inDML

1-14 Oracle GoldenGate for Oracle Installation and Setup Guide

requirements in integrated capture mode. TDE in classic capture moderequires

some setup. See "Configuring Oracle TDE data in classic capturemode" on

page 6-1.

■ Oracle GoldenGate supports TRUNCATE statements as part of its DDLreplication

support, or as standalone functionality that is independent of the DDLsupport.

See "Handlingother database properties" on page 5-12.

■ Oracle GoldenGate supports the capture of direct-load INSERTs. Supplemental

logging must be enabled, and the database must be in archive log mode. The

following direct-load methods are supported.

– /*+ APPEND */ hint

– /*+ PARALLEL */ hint (Non-RAC only in classiccapture mode)

– SQLLDR with DIRECT=TRUE

■ Oracle GoldenGate fully supports basic, advanced, andEHCC compressed tables

in integrated capture mode. In classic capture mode, Oracle GoldenGate can

deliver to, but not capture from, regular and EHCC compressed tables onOracle

Exadata. See "Handling other database properties" on page 5-12.

■ Oracle GoldenGate supports XA and PDML distributedtransactions in integrated

capture mode.

1.6.1.2 Limitations of support forindex-organized tables

These limitations apply to classic capture mode.

■ IOT with a mapping table is not supported in classiccapture mode. The DDL for

an IOT with mapping table will be replicated correctly, but subsequent DMLon it

will fail. This limitation applies to integrated and classic capturemodes.

■ IOT with key compression enabled (indicated by the COMPRESS keyword in the

key_compressionclause) is notsupported in classic capture mode, but is

supported in integrated capture mode.

1.6.1.3 Limitations of support for views

These limitations apply to integrated and classic capture modes.

■ Oracle GoldenGate supports capture from a view whenExtract is in initial-load

mode (capturing directly from the source view, not the redo log).

■ Oracle GoldenGate does not capture change data from aview, but it supports

capture from the underlying tables of a view.

■ Oracle GoldenGate can replicate to a view as long as theview is inherently

updatable. The structures of the source tables and a target view must beidentical.

See configuration requirements for views in "Handling other databaseproperties" on

page 5-12.

1.6.1.4 Limitations of support formaterialized views

These limitations apply to integrated and classic capture modes.

■ Materialized views created WITH ROWID are not supported.

■ The materialized view log can be created WITH ROWID.

■ The source table must have a primary key.

Details of support for Oracle objects and operations inDML

System requirementsand preinstallation instructions 1-15

■ Truncates of materialized views are not supported. Youcan use a DELETE FROM

statement.

■ Some Oracle GoldenGate initial-load methods do notsupport LOBs in a

materialized view.

■ For Replicat, the materialized view must be updateable.

■ DML (but not DDL) from a full refresh of a materializedview is supported. If DDL

support for this feature is required, open an Oracle GoldenGate supportcase.

1.6.1.5 Limitations of support for clusteredtables

Indexed and hash clusters are both supported in both integrated andclassic capture

modes, but in classic capture mode the following limitations apply:

■ Encrypted and compressed clustered tables are notsupported in classic capture.

■ Extract in classic capture mode captures DML changes madeto index clustered

tables if the cluster size remains the same. Any DDL that causes the clustersize to

increase or decrease may cause Extract to capture subsequent DML on thattable

incorrectly.

1.6.2 Sequences

■ Oracle GoldenGate supports the replication of sequencevalues in a uni-directional

and active-passive high-availability configuration.

■ Oracle GoldenGate ensures that the target sequence valueswill always be higher

than those of the source (or equal to them, if the cache is 0).

1.6.2.1 Limitations of support for sequences

These limitations apply to integrated and classic capture modes.

■ Oracle GoldenGate does not support the replication ofsequence values in an

active-active bi-directional configuration.

■ The cache size and the increment interval of the sourceand target sequences must

be identical. The cache can be any size, including 0 (NOCACHE).

■ The sequence can be set to cycle or not cycle, but thesource and target databases

must be set the same way.

See configuration requirements in "Handling other databaseproperties" on page 5-12.

1.6.3 Non-supported objects and operations inOracle DML

The following are not supported in either classic or integrated capturemode:

■ REF

■ Sequence values in an active-active bi-directionalconfiguration

■ Database Replay

■ Tables created as EXTERNAL

The following are not supported in classic capture mode only:

■ Exadata Hybrid Columnar Compression

■ Capture from tables with OLTP table compression

■ Capture from tablespaces and tables created or alteredwith COMPRESS

Details of support for objects and operations in OracleDDL

1-16 Oracle GoldenGate for Oracle Installation and Setup Guide

■ Capture from encrypted and compressed clustered tables

■ Synonyms

■ Distributed transactions. In Oracle versions 11.1.0.6 andhigher, you can capture

these transactions if you make them non-distributed by using the following

command, which requires the database to be restarted.

altersystem set _CLUSTERWIDE_GLOBAL_TRANSACTIONS=FALSE;

■ XA and PDML distributed transactions

■ Materialized views created WITH ROWID

■ Truncates of materialized views

1.7 Details of support for objects andoperations in Oracle DDL

This section outlines the Oracle objects and operation types that OracleGoldenGate

supports for the capture and replication of DDL operations.

1.7.1 Supported objects and operations inOracle DDL

These statements apply to integrated and classic capture modes.

■ All Oracle GoldenGate topology configurations aresupported for Oracle DDL

replication.

■ Active-active (bi-directional) replication of Oracle DDLis supported between two

(and only two) databases that contain identical metadata.

■ Oracle GoldenGate supports DDL operations of up to 2 MBin size on the

following objects:

– clusters

– functions

– indexes

– packages

– procedure

– tables

– tablespaces

– roles

– sequences

– synonyms

– triggers

– types

– views

– materialized views

– users

The 2 MB size limitation includes packages, procedures, and functions.

Details of support for objects and operations in OracleDDL

System requirementsand preinstallation instructions 1-17

See the Oracle GoldenGate Windows and UNIX Administrator's Guide for specific

support guidelines, support limitations, and configuration instructions.

1.7.2 Non-supported objects and operations inOracle DDL

These statements apply to integrated and classic capture modes.

1.7.2.1 Oracle-reserved schemas

The following schema names are considered Oracle-reserved and must beexcluded

from the Oracle GoldenGate DDL configuration. Oracle GoldenGate willignore these

schemas.

ANONYMOUS

AURORA

$JIS

$UTILITY

$AURORA

$ORB

$UNAUTHENTICATED

CTXSYS

DBSNMP

DMSYS

DSSYS

EXFSYS

MDSYS

ODM

ODM_MTR

OLAPSYS

ORDPLUGINS

ORDSYS

OSE$HTTP$ADMIN

OUTLN

PERFSTAT

PUBLIC

REPADMIN

SYS

SYSMAN

SYSTEM

TRACESVR

WKPROXY

WKSYS

WMSYS

XDB

1.7.2.2 Other non-supported DDL

Oracle GoldenGate does not support the following:

■ ALTER TABLE ... MOVE TABLESPACE

Note: The actual size limit of the DDLsupport is approximate,

because the size will not only include the statement text but also

Oracle GoldenGate maintenance overhead that depends on the length

of the object name, the DDL type, and other characteristics of keeping

a DDL record internally.

Supported and non-supported object names

1-18 Oracle GoldenGate for Oracle Installation and Setup Guide

■ DDL on nested tables

■ ALTER DATABASE and ALTER SYSTEM (these are not considered to be DDL)

■ DDL on a standby database

In addition, classic capture mode does not support DDL that involvespassword-based

column encryption, such as:

■ CREATE TABLE t1 ( a number, b varchar2(32) ENCRYPT IDENTIFIED BY my_

password);

■ ALTER TABLE t1 ADD COLUMN c varchar2(64) ENCRYPT IDENTIFIED BY my_

password;

1.8 Supported and non-supported object names

For information about Oracle GoldenGate support for object names and case,see the

Oracle GoldenGate Windows and UNIX Administrator's Guide.

2

Installing OracleGoldenGate 2-1

2InstallingOracle GoldenGate

These instructions are for installing Oracle GoldenGate for the firsttime. To upgrade

Oracle GoldenGate from one version to another, follow the instructions on:

http://www.oracle.com/technology/software/products/goldengate/in

dex.html

Installing Oracle GoldenGate installs all of the components that arerequired to run

and manage the processing (excluding any components required from othervendors,

such as drivers or libraries) and it installs the Oracle GoldenGateutilities.

The installation process takes a short amount of time.

2.1 Installation overview

To install Oracle GoldenGate, the following steps are required:

■ Downloading Oracle GoldenGate

■ Setting ORACLE_HOME and ORACLE_SID

■ Setting library paths for dynamic builds on UNIX

■ Preparing to install Oracle GoldenGate within a cluster

■ Installing Oracle GoldenGate on Linux and UNIX

■ Installing Oracle GoldenGate on Windows

■ Integrating Oracle GoldenGate into a cluster

■ Installing support for Oracle sequences

2.2 Downloading Oracle GoldenGate

Download the appropriate Oracle GoldenGate build to each system that willbe part of

the Oracle GoldenGate configuration.

1. Navigate to http://edelivery.oracle.com

2. On the Welcome page:

■ Select your language.

■ Click Continue.

3. On the Export Validation page:

■ Enter your identification information.

■ Accept the Trial License Agreement (even if you have a permanentlicense).

Setting ORACLE_HOME and ORACLE_SID

2-2 Oracle GoldenGate for Oracle Installation and Setup Guide

■ Accept the Export Restrictions.

■ Click Continue.

4. On the Media Pack Search page:

■ Select the Oracle Fusion Middleware Product Pack.

■ Select the platform on which you will be installing thesoftware.

■ Click Go.

5. In the Results List:

■ Select the Media Pack that you want to download.

■ Click Continue.

6. On the Download page:

■ Click Download for each component that you want.Follow the automatic

download process to transfer the mediapack.zip file to your system.

2.3 Setting ORACLE_HOME and ORACLE_SID

Make certain that the ORACLE_HOME and ORACLE_SID system environment variables are

set to the correct Oracle instance. The Oracle GoldenGate processes referto them when

connecting to the database.

2.3.1 Specifying Oracle variables on UNIX andLinux systems

If there is one instance of Oracle on the system, set ORACLE_HOME and ORACLE_SID at the

system level. If you cannot set them that way, use the following SETENV statements in

the parameter file of every Extract and Replicat group that will beconnecting to the

instance. The SETENV parameters override the systemsettings and allow the Oracle

GoldenGate process to set the variables at the session level when itconnects to the

database.

SETENV(ORACLE_HOME = “path to Oracle home location”)

SETENV(ORACLE_SID = “SID”)

If there are multiple Oracle instances on the system with Extract andReplicat

processes connecting to them, you will need to use a SETENV statement in the

parameter file of each process group and point it to the correct instance.For example,

the following shows parameter files for two Extract groups, each capturingfrom a

different Oracle instance.

Group 1:

EXTRACTora9a

SETENV(ORACLE_HOME = “/home/oracle/ora/product”)

SETENV(ORACLE_SID = “oraa”)

USERIDggsa, PASSWORD ggsa

RMTHOSTsysb

RMTTRAIL/home/ggs/dirdat/rt

TABLEhr.emp;

TABLEhr.salary;

Note: Before installing the software,review the release notes for any

new features, new requirements, or bug fixes that affect your current

configuration. Review the readme file for known issues.

Setting library paths for dynamic builds on UNIX

Installing OracleGoldenGate 2-3

Group 2:

EXTRACTorab

SETENV(ORACLE_HOME = “/home/oracle/ora/product”)

SETENV(ORACLE_SID = “orab”)

USERIDggsb, PASSWORD ggsb

RMTHOSTsysb

RMTTRAIL/home/ggs/dirdat/st

TABLEfin.sales;

TABLEfin.cust;

2.3.2 Specifying Oracle variables on Windowssystems

If there is one instance of Oracle on the system, the Registry settingsfor ORACLE_HOME

and ORACLE_SID should be sufficient for OracleGoldenGate. If those settings are

incorrect in the Registry and cannot be changed, you can set an overrideas follows.

1. On the Desktop or Start menu(depending on the Windows version), right-click

My Computer, and then select Properties.

2. In Properties, click the Advancedtab.

3. Click Environment Variables.

4. Under System Variables, click New.

5. For Variable Name, type ORACLE_HOME.

6. For Variable Value, type the path tothe Oracle binaries.

7. Click OK.

8. Click New again.

9. For Variable Name, type ORACLE_SID.

10. For Variable Value, type theinstance name.

11. Click OK.

If there are multiple Oracle instances on the system with Extract andReplicat

processes connecting to them, do the following.

1. Use the preceding procedure (singleOracle instance on system) to set the ORACLE_

HOME and ORACLE_SID system variables to the first Oracleinstance.

2. Start all of the Oracle GoldenGateprocesses that will connect to that instance.

3. Repeat the procedure for the nextOracle instance, but first edit the existing

ORACLE_HOMEand ORACLE_SID variables to specify the newinformation.

4. Start the Oracle GoldenGateprocesses that will connect to that instance.

5. Repeat the edit and startupprocedure for the rest of the Oracle instances.

2.4 Setting library paths for dynamic buildson UNIX

Oracle GoldenGate uses shared libraries. When you install OracleGoldenGate on a

UNIX system, the following must be true before you run GGSCI orany other Oracle

GoldenGate process.

1. Make certain that the databaselibraries are added to the shared-library

environment variables of the system. This procedure is usually performedat

Setting library paths for dynamic builds on UNIX

2-4 Oracle GoldenGate for Oracle Installation and Setup Guide

database installation time. Consult your Database Administrator if youhave any

questions.

When Oracle GoldenGate is running on the same server as the database, allof the

following must have the same bit type, either all 32-bit, all 64-bit, orall IA64:

■ Oracle library versions

■ Oracle GoldenGate version

■ Database versions

When Oracle GoldenGate connects remotely to the database server through

SQL*Net, the following are required:

■ Replicat: The Oracle client library and the OracleGoldenGate build must have

the same Oracle version, bit type (32-bit, 64-bit, IA64), and operatingsystem

version.

■ Extract: The Oracle client library and the OracleGoldenGate build must have

the same Oracle version, bit type (32-bit, 64-bit, IA64), and operatingsystem

version. In addition, both operating systems must be the same endian.

2. If you will be running an OracleGoldenGate program from outside the Oracle

GoldenGate installation directory on a UNIX system:

■ (Optional) Add the Oracle GoldenGate installationdirectory to the PATH

environment variable.

■ (Required) Add the Oracle GoldenGate installationdirectory to the

shared-libraries environment variable.

For example, given an Oracle GoldenGate installation directory of /users/ogg, the

second command in the following example requires these variables to beset:

To set the variables in Korn shell

PATH=installation_directory:$PATH

exportPATH

shared_libraries_variable=absolute_path_of_installation_directory:$shared_

libraries_variable

export shared_libraries_variable

To set the variables in Bourne shell

exportPATH=installation_directory:$PATH

export shared_libraries_variable=absolute_path_of_installation_directory:$shared_

libraries_variable

To set the variables in C shell

setenvPATH installation_directory:$PATH

setenv shared_libraries_variableabsolute_path_of_installation_directory:$shared_

libraries_variable

Where: shared libraries variable is one of the variables shown in Table 2–1:

Command Requires GG libraries in environmentvariable?

$users/ogg > ./ggsci No

$ users> ./ogg/ggsci Yes

Preparing to install Oracle GoldenGate within a cluster

Installing OracleGoldenGate 2-5

Example

exportLD_LIBRARY_PATH=/ggs/11.0:$LD_LIBRARY_PATH

2.5 Preparing to install Oracle GoldenGatewithin a cluster

This topic covers the installation requirements that apply when OracleGoldenGate

will be installed in a cluster environment. Oracle GoldenGate can be usedwith any

cluster-management solution that is Oracle-certified. The OracleClusterware solution

provides the advantage of being able to be used with or without an OracleRAC

database, which enables you to include any non-database servers that arerunning

Oracle GoldenGate.

2.5.1 Installing as the Oracle user

To install into an Oracle cluster, install as the Oracle operating systemuser.

2.5.2 Supported Oracle cluster storage

You will need to install at least some Oracle GoldenGate objects on sharedstorage.

Select cluster-aware shared storage that is independent of, but availableto, all nodes of

the cluster. You can use any of the following:

■ Oracle Cluster File System (OCFS). Instead of installingOracle GoldenGate in a

local directory, install it in a directory that is mounted to an OCFSvolume. See the

OCFS2 documentation for configuration information.

■ Oracle Automatic Storage Management System (AFS). Ifusing classic capture, see

setup requirements in "Capturing from an Oracle ASM instance when inclassic

capture mode" on page 6-7.

■ Oracle Database Filesystem (DBFS). Do not install OracleGoldenGate on DBFS,

but you can store the subdirectories (that are created with CREATE SUBDIRS during

installation) in a DBFS cluster that is only mounted to one server at atime. For

requirements in high-availability, see "Preparing DBFS foractive-active

propagation with Oracle GoldenGate" on page D-1.

Table 2–1 UNIX/Linux library path variablesper platform

Platform Environment variable

IBM AIXLIBPATH

HP-UXSHLIB_PATH

SunSolaris

HP Tru64(OSF/1)

LINUX

LD_LIBRARY_PATH1

1 In 64-bitenvironments with 32-bit Oracle databases, Oracle GoldenGate requires the LD_LIBRARY_PATH to

include the 32-bit Oracle libraries.

Note: To view the libraries that arerequired by an Oracle

GoldenGate process, use the ldd goldengate_processshell command

before starting the process. This command also shows an error

message for any that are missing.

Installing Oracle GoldenGate on Linux and UNIX

2-6 Oracle GoldenGate for Oracle Installation and Setup Guide

2.5.3 Deciding where to install OracleGoldenGate binaries and files in the cluster

The best practice is to install Oracle GoldenGate entirely on sharedstorage. This

allows you to start the Oracle GoldenGate processes from any of the nodeswithout

having to make changes to the parameter files. If the active node fails,the processes

can be started quickly on another node, using the processing checkpointsthat are

preserved in the installation directory.

If you decide to install the Oracle GoldenGate binaries and files on eachnode, rather

than on shared storage, the following must be true:

■ The Oracle GoldenGate installation must have the samelocation path on every

node.

■ At minimum, install the following directories on theshared storage to support

Oracle GoldenGate recovery requirements. On UNIX or Linux, you can create

symbolic 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 during

installation.

■ The parameter files in the dirprm directory, if not placed on theshared drive, must

be identical on all nodes. To resolve environment settings that must bedifferent

from one node to the other, you can set environment settings so they areinherited

from the local Manager process or reference a node-specific OracleGoldenGate

macro file. Because this scenario can be difficult to enforce, theinherent concerns

can be avoided by storing the parameter files on the shared drive.

See also "IntegratingOracle GoldenGate into a cluster" on page 2-9 after you install

Oracle GoldenGate.

2.6 Installing Oracle GoldenGate on Linux andUNIX

Follow these steps to install Oracle GoldenGate for Oracle on a Linux orUNIX system

or in the appropriate location in a cluster. See Section 2.5, "Preparing toinstall Oracle

GoldenGate within a cluster" for more information.

1. Extract the Oracle GoldenGate mediapack.zip file to the system and directory

where you want Oracle GoldenGate to be installed.

2. Run the command shell.

3. Change directories to the new OracleGoldenGate directory.

4. From the Oracle GoldenGatedirectory, run the GGSCI program.

GGSCI

5. In GGSCI, issue the followingcommand to create the Oracle GoldenGate working

directories.

CREATESUBDIRS

6. Issue the following command to exitGGSCI.

EXIT

Installing Oracle GoldenGate on Windows

Installing OracleGoldenGate 2-7

2.7 Installing Oracle GoldenGate on Windows

Follow these steps to install Oracle GoldenGate for Oracle on a Windowssystem or in

the appropriate location in a cluster. See Section 2.5, "Preparing toinstall Oracle

GoldenGate within a cluster" for more information.

2.7.1 Installing Oracle GoldenGate into aWindows Cluster

1. Log into one of the nodes in thecluster.

2. Choose a drive for the OracleGoldenGate installation location. This drive must be

a resource within the same cluster group that contains the databaseinstance.

3. Ensure that this cluster group isowned by the cluster node that you are logging

into.

4. Install Oracle GoldenGate accordingto "Installingthe Oracle GoldenGate files".

2.7.2 Installing the Oracle GoldenGate files

1. Unzip the downloaded file(s) byusing WinZip or an equivalent compression

product.

2. Move the files in binary mode to afolder on the drive where you want to install

Oracle GoldenGate. Do not install Oracle GoldenGate into a folder thatcontains

spaces in its name, even if the path is in quotes. For example:

C:\“OracleGoldenGate” is not valid.

C:\Oracle_GoldenGateis valid.

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

4. In GGSCI, issue the followingcommand to create the Oracle GoldenGate working

directories.

CREATESUBDIRS

5. Issue the following command to exitGGSCI.

EXIT

6. Copy the following files from theOracle GoldenGate installation directory to the

SYSTEM32directory.

category.dll

ggsmsg.dll

2.7.3 Specifying a custom Manager name

You must specify a custom name for the Manager process if either of thefollowing is

true:

■ You want to use a name for Manager other than the defaultof GGSMGR.

■ There will be multiple Manager processes running asWindows services on this

system. Each Manager on a system must have a unique name. Beforeproceeding

further, note the names of any local Manager services.

To specify a custom Manager name

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

2. Issue the following command.

Installing Oracle GoldenGate on Windows

2-8 Oracle GoldenGate for Oracle Installation and Setup Guide

EDITPARAMS ./GLOBALS

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

service.

MGRSERVNAMEname

4. Save the file. The file is savedautomatically with the name GLOBALS, but without a

file extension. Do not move this file. It is used during installation ofthe Windows

service and during data processing.

2.7.4 Installing Manager as a Windows service

By default, Manager is not installed as a service and can be run by alocal or domain

account. However, when run this way, Manager will stop when the user logsout.

When you install Manager as a service, you can operate it independently ofuser

connections, and you can configure it to start manually or at systemstart-up.

Installing Manager as a service is required on a Windows Cluster, butoptional

otherwise.

To install Manager as a Windows service

1. (Recommended) Log on as the systemadministrator.

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

3. From the directory that contains theManager program that you are installing as a

service, run the INSTALL utility with the following syntax:

install option [...]

Where: option is one of the following:

Note: The ./ portion of this command mustbe used, because the

GLOBALS file must reside at the root of theOracle GoldenGate

installation file.

Table 2–2 INSTALL utility options

Option Description

ADDEVENTSAdds OracleGoldenGate events to the Windows Event

Manager.

ADDSERVICEAdds Manager asa service with the name that is specified with

the MGRSERVNAME parameter in the GLOBALS file, if one exists, or

by the default of GGSMGR. ADDSERVICE configures the service to

run as the Local System account, the standard for most

Windows applications because the service can be run

independently of user logins and password changes. To run

Manager as a specific account, use the USER and PASSWORD

options.1

The service is installed to start at system boot time (see

AUTOSTART). To start itafter installation, either reboot the system

or start the service manually from the Services applet of the

Control Panel.

AUTOSTARTSets theservice that is created with ADDSERVICE to start at system

boot time. This is the default unless MANUALSTART is used.

Integrating Oracle GoldenGate into a cluster

Installing OracleGoldenGate 2-9

4. (Windows Server 2008) If WindowsUser Account Control (UAC) is enabled, you

are prompted to allow or deny the program access to the computer. Select Allow

to enable the INSTALL utility to run.

The INSTALL utility installs the Manager service with a local systemaccount

running with administrator privileges. No further UAC prompts will be

encountered when running Manager if installed as a service.

2.8 Integrating Oracle GoldenGate into acluster

If you installed Oracle GoldenGate in a cluster, take the following stepsto integrate

Oracle GoldenGate within the cluster solution.

2.8.1 General requirements in a cluster

1. Register the Oracle GoldenGateManager process (and only Manager) as a

cluster-managed resource as you would any other application. Manager mustbe

the only Oracle GoldenGate process that the cluster-management softwarestarts

and stops, because it is the parent process that manages all otherprocesses.

2. If the cluster uses a virtual IPaddress (such as Oracle Clusterware), you may need

to obtain an available fixed IP address for the Manager process. The VIPmust be

an available IP address on the public subnet and cannot be determinedthrough

DHCP. In the parameter files of the Extract data pumps, specify the VIP ofthe

remote Manager as the input value of the RMTHOST parameter. Other Oracle

GoldenGate products that access Manager also should use the VIP.

3. (Oracle databases earlier thanversion 10.2) Make certain that all nodes in the

cluster have synchronized system clocks. The clocks must be synchronizedwith

the clock on the system where Extract is executed. Oracle GoldenGatecompares

the time of the local system to the commit timestamps to make criticaldecisions.

For information about synchronizing system clocks, consult www.ntp.org or

your systems administrator. See also the IOLATENCY option of the THREADOPTIONS

parameter in the Oracle GoldenGate Windows and UNIX ReferenceGuide. This is

not a requirement for integrated capture.

MANUALSTARTSets theservice that is created with ADDSERVICE to start manually

through GGSCI, a script, or the Services applet of the Control

Panel. The default is AUTOSTART .

USER name Specifies a domain user account thatexecutes Manager. For the

name, include the domain name, a backward slash, and the user

name, for example HEADQT\GGSMGR .

By default, the Manager service is installed to use the Local

System account.

PASSWORDpasswordSpecifies thepassword for the user that is specified with USER .

1 A user accountcan be changed by selecting the Properties action from the Services applet ofthe

Windows Control Panel.

Note: If Manager is not installed as aservice, Oracle GoldenGate

users will receive a UAC prompt to confirm the elevation of privileges

for Manager when it is started from the GGSCI command prompt.

Running other Oracle GoldenGate programs also triggers a prompt.

Table 2–2 (Cont.) INSTALL utility options

Option Description

Installing support for Oracle sequences

2-10 Oracle GoldenGate for Oracle Installation and Setup Guide

4. Make certain that all nodes in thecluster have the same COMPATIBLE parameter

setting.

5. When you configure Manager, add the AUTOSTART and AUTORESTART parameters so

that Manager starts the replication processes automatically (see "Creating the

Oracle GoldenGate instance" on page 4-9). You can, when needed, control Extract,

Replicat, and other Oracle GoldenGate processes from within the Oracle

GoldenGate user interfaces.

6. Mount the shared drive on one nodeonly. This prevents processes from being

started on another node. Use the same mount point on all nodes.

7. Configure Oracle GoldenGate asdirected in this documentation.

2.8.2 Adding Oracle GoldenGate as a Windowscluster resource

When installing Oracle GoldenGate in a Windows cluster, follow theseinstructions to

establish Oracle GoldenGate as a cluster resource and configure theManager service

correctly on all nodes.

■ In the cluster administrator, add the Manager process tothe group that contains

the database instance to which Oracle GoldenGate will connect.

■ Make sure all nodes on which Oracle GoldenGate will runare selected as possible

owners of the resource.

■ Make certain the Manager Windows service has thefollowing dependencies

(configurable from the Services control panel):

– The database resource

– The disk resource that contains theOracle GoldenGate directory

– The disk resource that contains thedatabase transaction log files

– The disk resource that contains thedatabase transaction log backup files

2.9 Installing support for Oracle sequences

To support Oracle sequences, you must install some database procedures.These

procedures support the Oracle GoldenGate FLUSH SEQUENCE command, which you

issue immediately after you start the Oracle GoldenGate processes for thefirst time

(typically when you perform the initial data synchronization procedure).

To install Oracle sequence objects

You will perform steps on the source and target systems.

1. In SQL*Plus, connect to the sourceand target Oracle systems as SYSDBA.

2. If you already assigned a databaseuser to support the Oracle GoldenGate DDL

replication feature, you can skip this step. Otherwise, in SQL*Plus onboth systems

create a database user that can also be the DDL user.

CREATEUSER DDLuser IDENTIFIED BY password;

GRANTCONNECT, RESOURCE, DBA TO DDLuser;

3. From the Oracle GoldenGateinstallation directory on each system, run GGSCI.

4. In GGSCI, issue the followingcommand on each system.

EDITPARAMS ./GLOBALS

Installing support for Oracle sequences

Installing OracleGoldenGate 2-11

5. In each GLOBALS file, enter the GGSCHEMA parameter and specify the schema ofthe

DDL user that you created earlier in this procedure.

GGSCHEMAschema

6. Save and close the files.

7. In SQL*Plus on both systems, run thesequence.sql script from the root of the

Oracle GoldenGate installation directory. This script creates someprocedures for

use by Oracle GoldenGate processes. (Do not run them yourself.) You are

prompted for the user information that you created in the first step.

@sequence.sql

8. In SQL*Plus on the source system,grant EXECUTE privilege on the updateSequence

procedure to a database user that can be used to issue the DBLOGIN command.

Remember or record this user. You use DBLOGIN to log into the database prior to

issuing the FLUSHSEQUENCE command, whichcalls the procedure.

GRANTEXECUTE on DDLuser.updateSequence TO DBLOGINuser;

9. In SQL*Plus on the target system,grant EXECUTE privilege on the

replicateSequenceprocedure tothe Replicat database user.

GRANTEXECUTE on DDLuser.replicateSequence TO Replicatuser;

10. In SQL*Plus on the source system,issue the following statement in SQL*Plus.

ALTERTABLE sys.seq$ ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

Installing support for Oracle sequences

2-12 Oracle GoldenGate for Oracle Installation and Setup Guide

3

Installing OracleGoldenGate DDL support for an Oracle database 3-1

3InstallingOracle GoldenGate DDL support

for an Oracle database

This chapter contains instructions for installing the objects that supportDDL

replication. To configure Oracle GoldenGate to capture and replicate DDL,see

Chapter 7.

3.1 Overview of the DDL objects

To install the Oracle GoldenGate DDL environment, you will be installingthe

database objects shown in Table 3–1.

Note: DDL support for sequences (CREATE, ALTER, DROP, RENAME) is

compatible with, but not required for, replicating the sequence values

themselves. To replicate just sequence values, you do not need to

install the Oracle GoldenGate DDL support environment. You can just

use the SEQUENCE parameter in the Extract configuration.

Table 3–1 DDL synchronization objects

Object Purpose Default name

DDL marker table Stores DDL information. This

table only receives inserts.

GGS_MARKER

Sequence on marker

table

Used for a column in the marker

table.

GGS_DDL_SEQ

DDL history table Stores object metadata history.

This table receives inserts,

updates, deletes.

GGS_DDL_HIST

Object ID history table Contains object IDs of configured

objects.

GGS_DDL_HIST_ALT

DDL trigger Fires on DDL operations. Writes

information about the operation

to the marker and history tables.

Installed with the trigger are

some packages.

GGS_DDL_TRIGGER_BEFORE

DDL schema Contains the DDL

synchronization objects.

None; must be specified during

installation and in the GLOBALS

file.

User role Establishes the role needed to

execute DDL operations.

GGS_GGSUSER_ROLE

Installing the DDL objects

3-2 Oracle GoldenGate for Oracle Installation and Setup Guide

3.2 Installing the DDL objects

Follow these steps to install the database objects that support OracleGoldenGate DDL

capture.

1. Choose a schema that can contain theOracle GoldenGate DDL objects. This

schema cannot be case-sensitive.

2. Grant the following permission tothe Oracle GoldenGate schema.

GRANTEXECUTE ON utl_file TO schema;

3. Create a default tablespace for theOracle GoldenGate DDL schema. This

tablespace must be dedicated to the DDL schema; do not allow any otherschema

to share it. AUTOEXTENDmust be set to ON for this tablespace, and thetablespace

must be sized to accommodate the growth of the GGS_DDL_HIST and GGS_MARKER

tables. The GGS_DDL_HISTtable, inparticular, will grow in proportion to overall

DDL activity.

4. Create a GLOBALS file (or edit it, if one exists).

EDITPARAMS ./GLOBALS

Internal setup table Database table for internal use

only.

GGS_SETUP

ddl_pin Pins DDL tracing, the DDL

package, and the DDL trigger for

performance improvements.

ddl_pin

ddl_cleartrace.sqlRemoves the DDLtrace file. ddl_cleartrace.sql

ddl_status.sqlVerifies thatthe Oracle

GoldenGate DDL objects are

installed

ddl_status.sql

marker_status.sqlVerifies thatthe marker table is

installed.

marker_status.sql

ddl_tracelevel.sqlSets the levelfor DDL tracing. ddl_tracelevel.sql

Note: If the DDL tablespace fills up,Extract stops capturing DDL.

To cause user DDL activity to fail when that happens, edit the

params.sqlscript and setthe ddl_fire_error_in_triggerparameter

to TRUE. Stopping user DDL gives you timeto extend the tablespace

size and prevent the loss of DDL capture. Managing tablespace sizing

this way, however, requires frequent monitoring of the business

applications and Extract to avoid business disruptions. Instead, Oracle

recommends that you size the tablespace appropriately and set

AUTOEXTENDto ON so that the tablespace does not fillup.

WARNING: Do not edit any otherparameters in params.sql except

if you need to follow documented instructionsto change certain

object names.

Table 3–1 (Cont.) DDL synchronization objects

Object Purpose Default name

Installing the DDL objects

Installing OracleGoldenGate DDL support for an Oracle database 3-3

5. In the GLOBALS file, specify the name of the DDLschema by adding the following

parameter to the GLOBALS file.

GGSCHEMAschema_name

6. (Optional) To change the names ofother objects listed in Table 3–1, the changes

must be made now, before proceeding with the rest ofthe installation. Otherwise,

you will need to stop Oracle GoldenGate DDL processing and reinstall theDDL

objects. It is recommended that you accept the default names of thedatabase

objects. To change any name in Table 3–1 (except the schema), do one or both of

the following:

■ Record all name changes in the params.sql script. Edit this script and change

the appropriate parameters. Do not run this script.

■ List the names shown in Table 3–2 in the GLOBALS file. The correct parameters

to use are listed in the Parameter column of the table.

7. Save and close the GLOBALS file.

8. Change directories to the Oracle GoldenGateinstallation directory.

9. Exit all Oracle sessions, includingthose of SQL*Plus, those of business

applications, those of the Oracle GoldenGate processes, and those of anyother

software that uses Oracle. Prevent the start of any new sessions.

10. Run SQL*Plus and log in as a userthat has SYSDBA privilege. This privilege is

required to install the DDL trigger in the SYS schema, which is required by Oracle.

All other DDL objects are installed in the schema that you created in step1.

11. Run the marker_setup.sql script. Supply the name of theOracle GoldenGate

schema when prompted, and then press Enter to execute the script. The script

installs support for the Oracle GoldenGate DDL marker system.

@marker_setup.sql

12. Run the ddl_setup.sql script. You are prompted to specifythe name of the DDL

schema that you configured in step 1. (Note: ddl_setup.sql will fail if the

tablespace for this schema is shared by any other users. It will not fail,however, if

the default tablespace does not have AUTOEXTEND set to ON, the recommended

setting.)

@ddl_setup.sql

Note: EDIT PARAMS creates a simple text file. When yousave the file

after EDIT PARAMS, it is saved with the name GLOBALS in upper case,

without a file extension, at the root of the Oracle GoldenGate

directory. Do not alter the file name or location.

Table 3–2 GLOBALS parameters for changing DDLobject names

Object Parameter

Marker table MARKERTABLEnew_table_name1

1 Do not qualifythe name of any of these tables. The schema name for these table must be eitherthe one

that is specified with GGSCHEMA or the schemaof the current user, if GGSCHEMA is notspecified in GLOBALS.

History table DDLTABLEnew_table_name

Installing the DDL objects

3-4 Oracle GoldenGate for Oracle Installation and Setup Guide

13. Run the role_setup.sql script. At the prompt, supply theDDL schema name. The

script drops and creates the role that is needed for DDL synchronization,and it

grants DML permissions on the Oracle GoldenGate DDL objects.

@role_setup.sql

14. Grant the role that was created(default name is GGS_GGSUSER_ROLE) to all Oracle

GoldenGate Extract users. You may need to make multiple grants if theprocesses

have different user names.

GRANT role TO user;

15. Run the ddl_enable.sql script to enable the DDL trigger.

@ddl_enable.sql

To install and use the optional performancetool

To improve the performance of the DDL trigger, make the ddl_pin script part of the

database startup. It must be invoked with the Oracle GoldenGate DDL username, as

in:

@ddl_pinDDL_user

This script pins the PL/SQL package that is used by the trigger intomemory. If

executing this script from SQL*Plus, connect as SYSDBA from the Oracle GoldenGate

installation directory. This script relies on the Oracle dmbs_shared_pool system

package, so install that package before using ddl_pin.

4

Configuring OracleGoldenGate on Oracle source and target databases 4-1

4ConfiguringOracle GoldenGate on Oracle

source and target databases

This chapter contains instructions for configuring Oracle GoldenGate tocapture

source Oracle data and apply it to a target Oracle database.

4.1 What to expect from this procedure

These instructions show you how to configure a basic set of OracleGoldenGate

parameter (configuration) files, one for each process that replicatestransactional data

changes from an Oracle source to an identical Oracle target. Your business

requirements probably will require a more complex topology, but thisprocedure

forms a basis for the rest of your configuration steps.

Figure 4–1 The basic configuration

By performing these steps, you can:

■ get the basic configuration files established.

■ build upon them later by adding more parameters as youmake decisions about

features or requirements that apply to your environment.

■ use copies of them to make the creation of additionalparameter files faster than

starting from scratch.

4.2 Creating and editing parameter files

You will be working with Oracle GoldenGate parameter files throughout the

deployment process. To create and edit a parameter file, use the EDIT PARAMS

command in GGSCI at any time after you start Manager.

EDITPARAMS name ofparameter file

Overview of basic steps to configure Oracle GoldenGate

4-2 Oracle GoldenGate for Oracle Installation and Setup Guide

For more information about ways to work with Oracle GoldenGate parameterfiles, see

the Oracle GoldenGate Windows and UNIX Administrator's Guide.

4.3 Overview of basic steps to configureOracle GoldenGate

You will make the following decisions:

■ Choosing names for processes and files

■ Deciding which capture method to use

■ Assigning a database user for Oracle GoldenGate

You will create the following basic set of objects.

On both systems:

■ Creating the Oracle GoldenGate instance

On the source system:

■ Configuring Extract for change capture

On the target system:

■ Configuring Replicat for change delivery

This chapter also includes recommendations for:

■ Tuning recommendations for integrated capture

■ Configuring additional process groups for bestperformance

■ Next steps in the deployment

■ When to start replicating transactional changes

■ Testing your configuration

4.4 Choosing names for processes and files

It is helpful to develop some naming conventions for the Oracle GoldenGateprocesses

and files before you start configuration steps. Choosing meaningful nameshelps you

differentiate among multiple processes and files in displays, error logs,and external

monitoring programs. In addition, it accommodates the naming of additional

processes and files later, as your environment changes or expands.

This section contains instructions for:

■ Choosing group names

■ Choosing file names

4.4.1 Choosing group names

You specify the names of Oracle GoldenGate processes in the parameterfiles and

when you create them during the instantiation of the Oracle GoldenGateenvironment

(Chapter 8). At minimum, you must choose namesfor the following processing

components:

Deciding which capture method to use

Configuring OracleGoldenGate on Oracle source and target databases 4-3

■ Primary Extract: The primary Extract processcaptures data and DDL from the

database source.

■ Data pump: The data pump is a secondaryExtract process that reads captured

data from a local trail on the source system and sends it over the networkto the

target. The data pump adds storage flexibility and isolates the primaryExtract

process from TCP/IP activity. For an illustration of how a data pump fitsinto the

capture configuration, see Figure 4–1.

■ Replicat: The Replicat process reads aremote trail and applies the transactional

changes to the target database.

You may need to create more than one Replicat group and possibly more thanone

primary Extract group and data pump, depending on such decisions ascapture

method, performance tuning, or load balancing. For process namingconventions, see

the ADD EXTRACT and ADD REPLICAT commands in the Oracle GoldenGate Windowsand

UNIX Reference Guide.

4.4.2 Choosing file names

Captured data must be processed into a series of files called a trail,where it is stored

for processing by the next Oracle GoldenGate process downstream. The basic

configuration is:

■ a local trail on the source system

■ a remote trail on the target system.

The name can be a relative or fully qualified path name. The actual trailname can

contain only two characters, such as ./dirdat/tr. Oracle GoldenGate appends this

name with a six-digit sequence number whenever a new file is created, suchas

./dirdat/aa000002.

For more information about trail files, how they are stored, and how theyare

managed, see the Oracle GoldenGate Windows and UNIXAdministrator's Guide.

4.5 Deciding which capture method to use

For an Oracle source database, you can use either classic capture orintegrated capture

mode. The following explains these modes and the database versions thateach mode

supports.

4.5.1 About classic capture

In classic capture mode, the Oracle GoldenGate Extract process capturesdata changes

from the Oracle redo or archive log files on the source system or fromshipped archive

logs on a standby system.

Figure 4–2 Classic capture

Deciding which capture method to use

4-4 Oracle GoldenGate for Oracle Installation and Setup Guide

Classic capture supports most Oracle data types fully, with restrictedsupport for the

complex data types. Classic capture is the original, fast, and time-provenOracle

GoldenGate capture method that supports a broad array of the most commonlyused

Oracle data types and features. You can use classic capture for any sourceOracle

RDBMS that is supported by Oracle GoldenGate.

You can use classic capture to support the following:

■ ADTs, VARRAYs, NOLOGGING LOBs with source database compatibility set below

11.2.0.0.0.

■ Transparent Data Encryption support with source databasecompatibility set

below 11.0.0.0.0.

■ SECUREFILE LOB support with source database compatibility set below 11.2.0.0.0.

■ NOLOGGING LOB support with source database compatibility set below 11.2.0.0.0.

For more information, see "Summary of supported Oracle data types and objectsper

capture mode" on page 1-5.

If using classic capture, some additional setup is required after youcomplete the

configuration steps to produce a basic set of Oracle GoldenGate parameterfiles. See

"Additional configuration steps when using classic capture" on page 6-1.

4.5.2 About integrated capture

In integrated capture mode, the Oracle GoldenGate Extract processinteracts directly

with a database logmining server to receive data changes in the form oflogical change

records (LCR). Integrated capture supports more data and storage types ascompared

to classic capture, and the support is more transparent. For moreinformation, see

"Summary of supported Oracle data types and objects per capturemode" on page 1-5.

Figure 4–3 Integrated capture

The following are some additional benefits of integrated capture:

■ Because integrated capture is fully integrated with thedatabase, no additional

setup is required to work with Oracle RAC, ASM, and TDE.

■ Integrated capture uses the database logmining server toaccess the Oracle redo

stream, with the benefit of being able to automatically switch betweendifferent

copies of archive logs or different mirrored versions of the online logs.Thus

integrated capture can transparently handle the inavailability of a logfile caused

by disk corruption, hardware failure, or operator error, assuming thatadditonal

copies of the archived and online logs are available

■ Integrated capture enables faster filtering of tables.

■ Integrated capture handles point-in-time recovery and RACintegration more

efficiently.

Deciding which capture method to use

Configuring OracleGoldenGate on Oracle source and target databases 4-5

■ Integrated capture features integrated log management.The Oracle Recovery

Manager (RMAN) automatically retains the archive logs that are needed by

Extract.

4.5.2.1 Integrated capture supported databaseversions

The database version determines the data type support available throughintegrated

capture:

■ Full support: To support all Oracle data andstorage types, the compatibility

setting of the source database must be at least 11.2.0.3.0 with the11.2.0.3 Database

specific bundle patch for Integrated Extract 11.2.x (Doc ID 1411356.1). Toget this

patch from Oracle support, go to:

https://support.oracle.com/oip/faces/secure/km/DocumentDispla

y.jspx?id=1411356.1

■ Limited support: You can use integrated capture onan 11.2.0.3.0 downstream

mining database for a source database with a compatibility less than11.2.0.3, but

in this mode, SECUREFILELOBs, XMLcolumns, Transparent Data Encryption, and

UDTs are not supported. The downstream mining database must have the 11.2.0.3

Database specific bundle patch for Integrated Extract 11.2.x (DocID1411356.1)

applied. See "Integrated capture deployment options" on page 4-5.

To understand the differences in data type support among different RDBMSversions,

see "Summaryof supported Oracle data types and objects per capture mode" on

page 1-5.

4.5.2.2 Integrated capture deployment options

There are two deployment options for integrated capture, depending onwhere the

mining database is deployed. The mining database database is the one wherethe

logmining server is deployed.

■ Local deployment: For local deployment, the sourcedatabase and the mining

database are the same. The source database is the database for which youwant to

mine the redo stream to capture changes, and also where you deploy the

logmining server. Because integrated capture is fully integrated with thedatabase,

this mode does not require any special database setup.

■ Downstream deployment: In downstream deployment, thesource and mining

databases are different databases. You create the logmining server at the

downstream database. You configure redo transport at the source databaseto ship

the redo logs to the downstream mining database for capture at thatlocation.

Using a downstream mining server for capture may be desirable to offloadthe

capture overhead and any other overhead from transformation or otherprocessing

from the production server, but requires log shipping and otherconfiguration.

When using a downstream mining configuration, the source database andmining

database must be of the same platform. For example, if the source databaseis running

on Windows 64-bit, the downstream database must also be on a Windows64-bit

platform. To configure a downstream mining database, see "Configuring a

downstream mining database for integrated capture" on page A-1.

4.5.3 Combining capture modes

For Oracle 11.2.0.3 with the 11.2.0.3 Database specific bundle patch forIntegrated

Extract 11.2.x (Doc ID 1411356.1), you can use either integrated capture,classic

capture, or a combination of the two modes. You can divide your tablesbetween two

or more Extracts in different capture modes depending on the attributesand data

Assigning a database user for Oracle GoldenGate

4-6 Oracle GoldenGate for Oracle Installation and Setup Guide

types of the tables. The Oracle GoldenGate parameter files, trails,conversion

capabilities, mapping options, and replication mechanisms arefundamentally the

same in both modes.

4.6 Assigning a database user for OracleGoldenGate

This procedure creates a database user for each Oracle GoldenGate processand

assigns the correct database privileges.

1. Create a source database user and atarget database user, each one dedicated to

Oracle GoldenGate on the source and target systems. It can be the sameuser for all

of the Oracle GoldenGate processes that must connect to a source or targetOracle

database:

■ Extract (source database): This user performs metadataqueries on the source

database, and to fetch data from the source tables for data types that arenot

directly supported from the redo stream. For a list of these data types,see

"Summary of supported Oracle data types and objects per capturemode" on

page 1-5. In a local mining deployment of integrated capture, this useralso

creates, alters, and connects to the logmining server and receives logical

change records (LCR) from it.

■ Replicat (target database): This user is used to createthe Replicat checkpoint

table and to apply DML, DDL, and initial load operations.

■ Manager (source database, if using DDL support): Thisuser performs

maintenance on the Oracle GoldenGate database objects if DDL support is

being used.

■ DEFGEN (source ortarget database): This user performs local metadata queries

to build a data-definitions file that supplies the metadata to remoteOracle

GoldenGate instances.

2. If you are using Extract inintegrated capture mode and you will be using a

downstream mining database, create a mining user in the downstreamdatabase.

This user creates, alters, and connects to the logmining server on themining

database, and it receives logical change records (LCR) from it. This usercan be the

same as the source Extract user or different.

3. To assign the correct privileges tothe Oracle GoldenGate users, see Table 4–1

Note: Choose the name of the mining usercarefully. Once created by

this user, the database logmining server cannot be altered or used by

another user.

Assigning a database user for Oracle GoldenGate

Configuring OracleGoldenGate on Oracle source and target databases 4-7

Table 4–1 Database privileges by OracleGoldenGate process

User privilege

Extract

(Classic

Capture)

Extract

(Integrated

Capture) Replicat Manager Purpose

CREATESESSION,

ALTERSESSION

X X X

ALTERSYSTEM X X

RESOURCEX X X If RESOURCE cannot be granted to

Replicat, use the following

statement, where tablespace

represents all tablespaces that

contain target objects:

ALTERUSER user QUOTA {size |

UNLIMITED}ON tablespace;

CONNECT X X X Required only if Replicat owns

target objects or any PL/SQL

procedures. If Replicat cannot have

CONNECT, grant CREATE object for

any object that Replicat needs to

create.

SELECTANY

DICTIONARY

X X X

FLASHBACKANY

TABLE

or

FLASHBACKON

owner.table

X X

SELECTANY

TABLE

or

SELECTON

owner.table

X X X

SELECTon dba_

clusters

X X

INSERT,

UPDATE,DELETE

ON target

tables

X

CREATETABLE X Required touse ADD

CHECKPOINTTABLEto enable the

database checkpoint feature.

Privileges

required to issue

DDL operations

to target tables

(DDL support

only).

X

EXECUTEon

DBMS_FLASHBACK

package

X X Oracle GoldenGate makes a call to

DBMS_FLASHBACK.GET_

SYSTEM_CHANGE_NUMBER.

Assigning a database user for Oracle GoldenGate

4-8 Oracle GoldenGate for Oracle Installation and Setup Guide

GGS_GGSUSER_

ROLE

X X Role for DML privileges on Oracle

GoldenGate-owned DDL objects, if

DDL support is used. Role is created

during installation of DDL objects.

User that installs this role must have

SYSDBA privileges.

DELETEON

Oracle

GoldenGate

DDLobjects

X Required only if using parameters

that maintain the Oracle GoldenGate

DDL database objects.

LOCK ANYTABLE X Required onlyto use the Oracle

GoldenGate initial load method that

inserts data by means of a direct

bulk load to SQL*Loader.

sys.dbms_

internal_clkm

X Required to replicate Oracle

Transparent Data Encryption (TDE)

in classic capture mode.

SELECTANY

TRANSACTION

X Required for Extract to use a newer

Oracle ASM API. For more

information, see the DBLOGREADER

option of TRANLOGOPTIONS in the

Oracle GoldenGate reference

documentation.

Oracle 11.2.0.3

and above:

Privileges

granted through

dbms_

goldengate_

auth.grant_

admin_

privilege

Pre-11.2.1.3

Oracle releases :

Privileges

granted through

dbms_streams_

auth.grant

_admin_

privilege.

X Required to interact with a database

logmining server in integrated

capture mode. See "Deciding which

capture method to use" on page 4-3.

SELECT on the V_

$DATABASEview

X Only required for a downstream

Extract mining user in a downstream

capture configuration.

EXECUTEON

dbms_logmrn_d

package

And:

SELECTFROM

sys.logmnr_

buildlog

X Required for the source Extract user

to issue the REGISTEREXTRACT

command if the Oracle source

database is version >= 11.1.0.5 and

<= 11.2.0.1.

Table 4–1 (Cont.) Database privileges byOracle GoldenGate process

User privilege

Extract

(Classic

Capture)

Extract

(Integrated

Capture) Replicat Manager Purpose

Creating the Oracle GoldenGate instance

Configuring OracleGoldenGate on Oracle source and target databases 4-9

4. Keep a record of each databaseusers. They must be specified in the Oracle

GoldenGate parameter files.

5. To preserve the security of yourdata, and to monitor Oracle GoldenGate

processing accurately, do not permit other users, applications, orprocesses to log

on as, or operate as, the Oracle GoldenGate database user.

6. Additional users or privileges maybe required to use the following features, if

Extract will run in classic capture mode:

■ RMAN log retention (see "Log retentionoptions" on page 6-9)

■ TDE support (see "Configuring Oracle TDEdata in classic capture mode" on

page 6-1)

■ ASM (see "Capturing from an Oracle ASM instance when inclassic capture

mode" on page 6-7)

4.7 Creating the Oracle GoldenGate instance

Each Oracle GoldenGate installation is rooted in the Manager process. Thisis the

controller process that instantiates the Oracle GoldenGate processes,allocates port

numbers, and performs file maintenance. Together, the Manager process andits child

processes, and their related programs and files comprise an OracleGoldenGate

instance.

To run Oracle GoldenGate, a Manager process must be running on all systemsthat

will be part of the Oracle GoldenGate environment. To run Manager, youfirst create a

parameter file for it.

To create the Manager parameter file

1. From the Oracle GoldenGatedirectory, run the ggsci program to open the Oracle

GoldenGate Software Command Interface (GGSCI).

2. In GGSCI, edit the Manager parameterfile.

EDITPARAMS MGR

3. Add the Manager parameters, each onone line. If a parameter statement must

span multiple lines, use an ampersand (&) before each line break.

■ The only required Manager parameter is PORT, but DYNAMICPORTLIST is stronly

recommended.

■ In a cluster environment, configure Manager with the AUTOSTART and

AUTORESTARTparameters, sothat the Oracle GoldenGate processes start or

restart automatically when Manager is started or fails over.

■ Use PURGEOLDEXTRACTS to manage the accumulation of trail files.

■ For more information about Manager parameters, see theOracle GoldenGate

Windows and UNIX Reference Guide.

For more details on configuring Manager and its network connections, seethe

Oracle GoldenGate Windows and UNIX Administrator's Guide.

4. Save, then close the file.

Example 4–1

The following sample Manager parameter file is on a UNIX system usingrequired and

recommended parameters.

Configuring Extract for change capture

4-10 Oracle GoldenGate for Oracle Installation and Setup Guide

PORT7809

DYNAMICPORTLIST7810-7820, 7830

AUTOSTARTER t*

AUTORESTARTER t*, RETRIES 4, WAITMINUTES 4

STARTUPVALIDATIONDELAY5

PURGEOLDEXTRACTS/ogg/dirdat/tt*, USECHECKPOINTS, MINKEEPHOURS 2

4.8 Configuring Extract for change capture

Perform these steps on the source system to configure the primary and datapump

Extract processes that support change capture and transport across thenetwork.

4.8.1 Configuring the primary Extract(classic or integrated mode)

These steps configure the Extract that captures the transaction data.

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

EDITPARAMS name

Where: name is the name ofthe primary Extract.

2. Enter the Extract parameters in theorder shown, starting a new line for each

parameter statement. Examples are provided for classic and integratedcapture.

Your input variables will be different. See Table 4–2 for descriptions.

Basic parameters for the primary Extractgroup in classic capture mode:

EXTRACTfinance

USERIDogg,

PASSWORDAACAAAAAAAAAAAJAUEUGODSCVGJEEIUGKJDJTFNDKEJFFFTC &

AES128,ENCRYPTKEY securekey1

ENCRYPTTRAILAES192, KEYNAME mykey1

EXTTRAIL/ggs/dirdat/lt

SEQUENCEhr.employees_seq;

TABLEhr.*;

Basic parameters for the primary Extractgroup in integrated capture mode

where the source database is the miningdatabase:

EXTRACTfinancep

USERIDogg,

PASSWORDAACAAAAAAAAAAAJAUEUGODSCVGJEEIUGKJDJTFNDKEJFFFTC &

AES128,ENCRYPTKEY securekey1

TRANLOGOPTIONSMININGUSER oggm, &

MININGPASSWORDAACAAAAAAAAAAAJAUEUGODSCVGJEEIUGKJDJTFNDKEJFFFTC &

AES128,ENCRYPTKEY securekey1

TRANLOGOPTIONSINTEGRATEDPARAMS (MAX_SGA_SIZE 164, &

DOWNSTREAM_REAL_TIME_MINEy)

ENCRYPTTRAILAES192, KEYNAME mykey1

EXTTRAIL/ggs/dirdat/lt

SEQUENCEhr.employees_seq;

TABLEhr.*;

Basic parameters for the primary Extractgroup in integrated capture mode

where the mining database is a downstreamdatabase:

EXTRACTfinancep

USERIDogg, PASSWORD AACAAAAAAAAAAAJAUEUGODSCVGJEEIUGKJDJTFNDKEJFFFTC &

AES128,ENCRYPTKEY securekey1

Configuring Extract for change capture

Configuring OracleGoldenGate on Oracle source and target databases 4-11

TRANLOGOPTIONS[MININGUSER oggm, &

MININGPASSWORDAACAAAAAAAAAAAJAUEUGODSCVGJEEIUGKJDJTFNDKEJFFFTC &

AES128,ENCRYPTKEY securekey1]

TRANLOGOPTIONSINTEGRATEDPARAMS (MAX_SGA_SIZE 164, &

DOWNSTREAM_REAL_TIME_MINEy)

ENCRYPTTRAILAES192, KEYNAME mykey1

EXTTRAIL/ggs/dirdat/lt

SEQUENCEhr.employees_seq;

TABLEhr.*;

Table 4–2 Basic parameters for primaryExtract (classic or integrated mode)

Parameter Description

EXTRACT group name group name is the name of the Extract group.

USERID user id, PASSWORD pw

[encryption options]

Specifies database connection information for the database user that was

created in "Assigning a database user for Oracle GoldenGate" on page 4-6.

■ USERID specifies theExtract database user.

■ PASSWORD specifies theuser’s password.

■ encryption options specifies one of several ways toencrypt the

password.

For additional login options and encryption details, see the Oracle

GoldenGate Windows and UNIX Reference Guide.

Make certain this user has the permissions that are required for theOracle

GoldenGate capture mode that you are using:

■ Required source database login ("Assigning a database userfor Oracle

GoldenGate" on page 4-6)

■ RMAN log retention ("Log retentionoptions" on page 6-9)

■ TDE support ("Configuring Oracle TDE data in classic capturemode" on

page 6-1)

■ ASM ("Capturing from an Oracle ASM instance when inclassic capture

mode" on page 6-7)

TRANLOGOPTIONSMININGUSER user

id, MININGPASSWORD pw

[,encryption options]

(Integrated capture mode) Specifies connection information for the

logmining server at the downstream mining database, if being used.

■ MININGUSER specifies the Extract user for the downstream mining

database. This is the user that you created in "Configuring a

downstream mining database for integrated capture" on page A-1.

■ MININGPASSWORD specifies the user’s password.

■ encryption options specifies one of several ways toencrypt the

password.

Use only if the database logmining server is in a different database fromthe

source database; otherwise just use USERID. When using MININGUSER, use it in

addition to USERID. because logins are required forboth databases. For

additional login options and encryption details, see the Oracle GoldenGate

Windows and UNIX Reference Guide.

TRANLOGOPTIONS

[INTEGRATEDPARAMS(parameter[,

...])]

(Integrated capture mode) Passes parameters to the Oracle database that

contains the database logmining server. Use to specify the amount of SGA

memory used by the logmining server, the number of processes supporting

the logmining server, and whether integrated capture operates in real-time

or archived-log mode if a downstream mining database is being used. See

"Tuning recommendations for integrated capture" on page 4-16.

ENCRYPTTRAILencryptionoptions Encrypts thelocal trail. For encryption options, see the Windows and UNIX

Reference Guide.

Configuring Extract for change capture

4-12 Oracle GoldenGate for Oracle Installation and Setup Guide

3. Enter any optional Extractparameters that are recommended elsewhere in this

manual and any others shown in the Oracle GoldenGate Windowsand UNIX

Reference Guide.

4. Save and close the file.

4.8.2 Configuring the data pump

These steps configure the data pump that reads the local trail and sendsthe data

across the network to a remote trail.

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

EDIT PARAMSname

Where: name is the name ofthe data pump Extract.

2. Enter the data-pump parameters inthe order shown, starting a new line for each

parameter statement. Your input variables will be different. See Table 4–3 for

descriptions.

Basic parameters for the data-pump Extractgroup:

EXTRACTextpump

USERIDogg, PASSWORD AACAAAAAAAAAAAJAUEUGODSCVGJEEIUGKJDJTFNDKEJFFFTC &

AES128,ENCRYPTKEY securekey1

DECRYPTTRAILAES192, KEYNAME mykey1

RMTHOSTfin1, MGRPORT 7809 ENCRYPT AES192, KEYNAME securekey2

ENCRYPTTRAILAES192, KEYNAME mykey1

RMTTRAIL/ggs/dirdat/rt

SEQUENCEhr.employees_seq;

TABLEhr.*;

EXTTRAILpathnameSpecifies thepath name of the local trail to which the primary Extract writes

captured data.

SEQUENCEowner.sequence; Specifies an Oracle sequence tocapture.

■ owner is the schema name.

■ sequence is the name of the sequence.

Terminate the statement with a semi-colon.

TABLE owner.table; Specifies a table or tables forwhich to extract data changes.

■ owner is the schema name.

■ table is the name of the table or a groupof tables defined with

wildcards.

Schema names cannot be wildcarded. To extract data from tables in multiple

schemas, use a separate TABLE statement foreach schema. For example:

TABLEfin.*;

TABLEhr.*;

Terminate the TABLE statement with a semi-colon.

To exclude tables or sequences from a wildcard specification, use the

TABLEEXCLUDEowner.tableparameter afterthe TABLE statement.

For more information and for additional options that control datafiltering,

mapping, and manipulation, see TABLE in the OracleGoldenGate Windows

and UNIX Reference Guide.

Table 4–2 (Cont.) Basic parameters forprimary Extract (classic or integrated mode)

Parameter Description

Configuring Extract for change capture

Configuring OracleGoldenGate on Oracle source and target databases 4-13

3. Enter any optional Extractparameters that are recommended elsewhere in this

manual and any others shown in the Oracle GoldenGate Windowsand UNIX

Reference Guide.

4. Save and close the file.

Table 4–3 Basic parameters for a data-pumpExtract

Parameter Description

EXTRACT group name group name is the name of the data pumpExtract.

USERID user id,

PASSWORDpw [encryption

options]]

Specifies database connection information.

■ USERID specifies theExtract database user.

■ PASSWORD specifies theuser’s password.

■ encryption options specifies one of several ways toencrypt the password.

RMTHOST hostname,

MGRPORT portnumber,

[,ENCRYPT algorithm

KEYNAME keyname]

■ RMTHOST specifies thename or IP address of the target system.

■ MGRPORT specifies theport number where Manager is running on the target.

■ ENCRYPT specifiesoptional encryption of data across TCP/IP.

For additional options and encryption details, see the Oracle GoldenGate Windows

and UNIX Reference Guide.

ENCRYPTTRAILencryption

options

Encrypts the remote trail on the target to which this data pump writes.For encryption

options, see the Windows and UNIX Reference Guide.

DECRYPTTRAILencryption

options

Decrypts the local input trail that the data pump reads. The encryption options

must match those of the ENCRYPTTRAIL statement that is used for the primary Extract

group.

RMTTRAILpathnameSpecifies thepath name of the remote trail.

SEQUENCE

owner.sequence;

Specifies an Oracle sequence. In most cases, this listing will be the sameas that in the

primary Extract parameter file.

■ owner is the schema name.

■ sequence is the name of the sequence.

Terminate the statement with a semi-colon.

TABLE owner.table; Specifies a table or tables. In mostcases, this listing will be the same as that in the

primary Extract parameter file.

■ owner is the schema name.

■ table is the name of the table or a groupof tables defined with wildcards.

Schema names cannot be wildcarded. To extract data from tables in multipleschemas,

use a separate TABLE statement for each schema. Forexample:

TABLEfin.*;

TABLEhr.*;

Terminate the TABLE statement with a semi-colon.

To exclude tables or sequences from a wildcard specification, use the TABLEEXCLUDE

owner.table parameter after the TABLE statement.

For more information and for additional options that control datafiltering, mapping,

and manipulation, see TABLE in the OracleGoldenGate Windowsand UNIX Reference

Guide.

Configuring Replicat for change delivery

4-14 Oracle GoldenGate for Oracle Installation and Setup Guide

4.9 Configuring Replicat for change delivery

Perform these steps on the target system to configure the objects thatsupport change

delivery to the target database.

4.9.1 Creating a checkpoint table

Replicat maintains its checkpoints in a checkpoint table in the targetdatabase. Each

checkpoint is written to the checkpoint table within the Replicattransaction. Because a

checkpoint either succeeds or fails with the transaction, Replicat ensuresthat a

transaction is only applied once, even if there is a failure of theprocess or the

database.

4.9.1.1 Adding the checkpoint table to thetarget database

1. From the Oracle GoldenGate directoryon the target, run GGSCI and issue the

DBLOGIN command to log into the targetdatabase.

DBLOGIN,USERID db_user [, PASSWORD pw [encryption options]]

Where:

■ USERID db_user,PASSWORD pw, and encryption options supply database

credentials of a user with CREATE TABLE permissions and optinal password

encryption. See the Oracle GoldenGate Windows and UNIX ReferenceGuide for

more information about command options.

2. In GGSCI, create the checkpointtable in a schema of your choice (ideally

dedicated to Oracle GoldenGate).

ADDCHECKPOINTTABLE owner.table

4.9.1.2 Specifying the checkpoint table inthe Oracle GoldenGate configuration

1. Create a GLOBALS file (or edit the existing one).

EDITPARAMS ./GLOBALS

2. In the GLOBALS file, enter the CHECKPOINTTABLE parameter.

CHECKPOINTTABLEowner.table

Where: owner.table is the owner and a name that is supported by thedatabase.

Note: This procedure installs a defaultcheckpoint table, which is

sufficient in most cases. More than one checkpoint table can be used,

such as to use a different one for each Replicat group. To use a

non-default checkpoint table, which overrides the default table, use

the CHECKPOINTTABLE option of ADD REPLICAT when you create the

Replicat processes in the steps in "Instantiating andstarting Oracle

GoldenGate replication" on page 8-1. For details, see the Oracle

GoldenGate Windows and UNIX Reference Guide.

Note: EDIT PARAMS creates a simple text file. When yousave the file

after EDIT PARAMS, it is saved with the name GLOBALS in upper case,

without a file extension. It must remain as such, and the file must

remain in the root Oracle GoldenGate directory.

Configuring Replicat for change delivery

Configuring OracleGoldenGate on Oracle source and target databases 4-15

3. Save and close the GLOBALS file.

4.9.1.3 Disabling default asynchronous COMMITto checkpoint table

When Replicat uses a checkpoint table, it uses an asynchronous COMMIT with the

NOWAIT option to improve performance.Replicat can continue processing immediately

after applying this COMMIT, while thedatabase logs the transaction in the background.

You can disable the asynchronous COMMIT with NOWAIT by using the DBOPTIONS

parameter with the DISABLECOMMITNOWAIT option in the Replicat parameter file.

4.9.2 Configuring Replicat

These steps configure the Replicat process in a basic way without anyspecial mapping

or conversion of the data. For more advanced mapping options, see theOracle

GoldenGate Windows and UNIX Administrator's Guide.

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

EDITPARAMS name

Where: name is the name of the Replicat group.

2. Enter the Replicat parameters in theorder shown, starting a new line for each

parameter statement. See Table 4–4 for descriptions.

REPLICATfinancer

USERIDogg, PASSWORD AACAAAAAAAAAAAJAUEUGODSCVGJEEIUGKJDJTFNDKEJFFFTC &

AES128,ENCRYPTKEY securekey1

--SUPPRESSTRIGGERS is for Oracle 10.2.0.5 & later patches, and

-- forOracle 11.2.0.2 and later 11gR2 versions

-- Seefollowing "Note" for how SUPPRESSTRIGGERS works.

DBOPTIONSSUPPRESSTRIGGERS

DECRYPTTRAILAES192, KEYNAME mykey1

ASSUMETARGETDEFS

DISCARDFILE/users/ogg/disc

MAPhr.*, TARGET hr2.*;

Note: If a checkpoint table is not usedfor a Replicat group, the

checkpoints are maintained in a file on disk. In this case, Replicat uses

COMMIT with WAIT to prevent inconsistencies in theevent of a database

failure that causes the state of the transaction, as in the checkpointfile,

to be different than its state after the recovery.

Note: SUPPRESSTRIGGERS prevents the trigger body fromexecuting.

The WHEN portion of the trigger must stillcompile and execute

correctly to avoid database errors.

Tuning recommendations for integrated capture

4-16 Oracle GoldenGate for Oracle Installation and Setup Guide

3. Enter any optional Extractparameters that are recommended elsewhere in this

manual and any others shown in the Oracle GoldenGate Windowsand UNIX

Reference Guide.

4. Save and close the file.

4.10 Tuning recommendations for integratedcapture

Integrated capture uses a database logmining server in the mining databaseto mine

the redo stream of the source database. The logmining server consumes twotypes of

Table 4–4 Basic parameters for Replicat

Parameter Description

REPLICATgroupname group name is the name of the Replicat group.

USERID user id,

PASSWORDpw [encryption

options]]

Specifies database connection information.

■ USERID specifies theReplicat database user.

■ PASSWORD specifies theuser’s password.

■ encryption options specifies one of several ways toencrypt the password.

For additional login options and encryption details, see the OracleGoldenGate

Windows and UNIX Reference Guide.

DBOPTIONS

SUPPRESSTRIGGERS,

DEFERREFCONST

■ SUPPRESSTRIGGERS prevents triggers from firing on target objects that are

configured for replication with Oracle GoldenGate.

■ DEFERREFCONST sets constraints to DEFERRABLE to delay the enforcement of

cascade constraints by the target database until the Replicat transactionis

committed.

See the Oracle GoldenGate Windows and UNIX Reference Guide for additional

important information about these DBOPTIONS options.

ASSUMETARGETDEFSSpecifies howto interpret data definitions. ASSUMETARGETDEFS assumes the source and

target tables have identical definitions, including semantics. (Thisprocedure assume

identical definitions.)

Use the alternative SOURCEDEFS if the source and target tables have different

definitions, and create a source data-definitions file with DEFGEN. See the Oracle

GoldenGate Windows and UNIX Administrator's Guide for more information.

DISCARDFILEfull_

pathname

Specifies the full path name of a file to which Replicat writes rejectedrecord data, for

example records that generated database errors. A discard file is optionalbut

recommended. See the Oracle GoldenGate Windows and UNIX ReferenceGuide for

additional options.

DECRYPTTRAILencryption

options

Decrypts the input trail that this Replicat reads. The encryption options must

match those of the ENCRYPTTRAIL statement for this input trail.

MAP owner.table,

TARGET owner.table;

Specifies a relationship between a source and target table or tables.

■ owner is the schema name.

■ table is the name of a table or a wildcarddefinition for multiple tables.

Schema names cannot be wildcarded. To map tables in multiple schemas, usea

separate MAP statement for each schema. Forexample:

MAPfin.*, TARGET fin.*;

MAPhr.*, TARGET hr.*;

Terminate the MAP statement with a semi-colon.

To exclude tables from a wildcard specification, use the MAPEXCLUDE parameter.

For more information and for additional options that control datafiltering, mapping,

and manipulation, see MAP in the OracleGoldenGate Windowsand UNIX Reference

Guide.

Configuring additional process groups for bestperformance

Configuring OracleGoldenGate on Oracle source and target databases 4-17

database resources: a given number of processes and a given amount ofshared

memory. You can control these resources by specifying the followingparameters in

the INTEGRATEDPARAMSlist of theExtract TRANLOGOPTIONS parameter:

■ To control the amount of shared memory used by thelogmining server, specify

the max_sga_size parameter with a value in megabytes.

■ To control the number of processes used by the logminingserver, specify the

parallelismparameter.

For example, you can specify that the logmining server uses 200 MB ofmemory with a

parallelism of 3 by specifying the following:

TRANLOGOPTIONSINTEGRATEDPARAMS (max_sga_size 200, parallelism 3)

The shared memory that is used by the logmining server comes from theStreams pool

portion of the System Global Area (SGA) in the database. Therefore, youmust set

streams_pool_sizehigh enough tokeep enough memory available for the number of

Extract processes that you expect to run in integrated capture modeagainst a given

database instance. Note that Streams pool is also used by other componentsof the

database (like AQ), so make certain to take them into account while sizingthe Streams

pool for Oracle GoldenGate.

By default, one integrated capture Extract requests the logmining serverto run with

max_sga_sizeof 1GB and a parallelism of 2. Thus, if you are running threeExtracts

in integrated capture mode in the same database instance, you need atleast 3 GB of

memory allocated to the Streams pool. As best practice, keep 25 percent ofthe Streams

pool available. For example, if there are three Extracts in integratedcapture mode, set

stream_pool_sizeto thefollowing:

3 GB +(3 GB * 0.25) = 3.75 GB

Performance testing also confirmed that the logmining server runs fasterwhen _log_

buffer_sizeis set to 128(the default is 8) when the source database runs in a system

with high redo volume. To set this parameter, use the following command.

SQL>alter system set _log_buffer_size=128;

4.11 Configuring additional process groupsfor best performance

Develop business rules that specify the acceptable amount of lag betweenthe time

when transactions are generated by your source applications and when thosechanges

are applied to the target database. These rules determine the number ofparallel

Extract and Replicat processes that are required to enable OracleGoldenGate to

perform at its best.

Gather the size and activity rates of all of the tables that you intend toreplicate with

Oracle GoldenGate, and then:

■ Assign one Extract group to the tables with low activityrates.

■ Assign a dedicated Extract group to tables with highactivity rates.

Configure these Extract groups to work with dedicated data pumps andReplicat

groups. Once you have a basic set of parameter files for one Extract andReplicat

process, you can:

■ copy them to the names of the new process groups.

■ edit the copies to produce the parameter files for youradditional process groups.

Next steps in the deployment

4-18 Oracle GoldenGate for Oracle Installation and Setup Guide

For more information about configuring Oracle GoldenGate for bestperformance, see

the Oracle GoldenGate Windows and UNIX Troubleshooting and TuningGuide.

4.12 Next steps in the deployment

Because of its flexibility, Oracle GoldenGate offers numerous features andoptions that

must be considered before you start any processes. To further configureOracle

GoldenGate to suit your business needs, see the following:

■ To prepare the database and the redo logs, and to learnabout additional

parameters that may be required, see the remaining chapters in thismanual.

■ To configure Oracle GoldenGate to capture and apply DDLoperations, see

Chapter 7.

■ If either the source or target database is non-Oracle,follow the installation and

configuration instructions in the Oracle GoldenGate installation and setupguide

for that database, and then refer to the Oracle GoldenGate administrationand

reference documentation for further information.

■ For additional configuration guidelines to achievespecific replication topologies,

see the Oracle GoldenGate Windows and UNIX Administrator's Guide. This guide

includes instructions for the following configurations:

– Using Oracle GoldenGate for livereporting

– Using Oracle GoldenGate forreal-time data distribution

– Configuring Oracle GoldenGate forreal-time data warehousing

– Using Oracle GoldenGate to maintaina live standby database

– Using Oracle GoldenGate foractive-active high availability

That guide also contains information about:

– Oracle GoldenGate architecture

– Oracle GoldenGate commands

– Oracle GoldenGate initial loadmethods

– Configuring security

– Using customization features

– Configuring data filtering andmanipulation

■ For syntax options and descriptions of Oracle GoldenGateGGSCI commands and

Oracle GoldenGate parameters shown in this guide, see the OracleGoldenGate

Windows and UNIX Reference Guide.

4.13 When to start replicating transactionalchanges

You must start replication when the source and target data is in asynchronized state,

where the corresponding rows in the source and target tables containidentical data

values. Unless you are starting with brand new source and target databaseswith no

current user activity, you will need to activate change synchronization tocapture

ongoing transactional changes while an initial load is being applied tothe target. The

initial load captures a point-in-time snapshot of the source data andapplies it to the

target, while Oracle GoldenGate maintains any changes that are made afterthat point.

After you satisfy the requirements for configuring the database and theOracle

GoldenGate processes (including DDL support if required), see "Instantiating and

Testing your configuration

Configuring OracleGoldenGate on Oracle source and target databases 4-19

starting Oracle GoldenGate replication" on page 8-1 to perform an initialload, start

replicating changes, and handle post-load collisions.

4.14 Testing your configuration

It is important to test your configuration in a test environment beforedeploying it live

on your production machines. This is especially important in anactive-active or high

availability configuration, where trusted source data may be touched bythe

replication processes. Testing enables you to find and resolve anyconfiguration

mistakes or data issues without the need to interrupt user activity forre-loads on the

target or other troubleshooting activities.

Testing your configuration

4-20 Oracle GoldenGate for Oracle Installation and Setup Guide

5

Preparing thedatabase for Oracle GoldenGate 5-1

5Preparingthe database for Oracle

GoldenGate

This chapter contains steps to take so that the source and target Oracledatabases with

which Oracle GoldenGate interacts is configured properly to supportcapture and

replication. Some steps apply to just a source system, some just to atarget, and some

to both. You will be adding new parameters to the basic parameter filethat you

created in "Configuring Oracle GoldenGate on Oracle source and targetdatabases" on

page 4-1.

The procedures to prepare the database are:

■ Preparing integrity constraints in source and targettables

■ Configuring logging properties

■ Limiting row changes in tables that do not have a uniquerow identifier

■ Supporting the conversion of character sets

■ Setting fetch options

■ Handling special data types

■ Handling other database properties

■ Using Oracle GoldenGate with Oracle Exadata

5.1 Preparing integrity constraints in sourceand target tables

Triggers, cascade constraints, and unique identifiers must be properlyconfigured in

an Oracle GoldenGate environment. Review the following guidelines andimplement

the ones that are relative to your configuration, before you start Extractor Replicat to

process data.

5.1.1 Disabling triggers and referentialcascade constraints on target tables

Triggers and cascade contraints must be disabled on Oracle target tables. Oracle

GoldenGate provides some options to handle triggers or cascade constraints

automatically, depending on the Oracle version:

■ DBOPTIONS with SUPPRESSTRIGGERS: Supported for Oracle 10.2.0.5 andlater patches

to 10.2.0.5, and for Oracle 11.2.0.2 and later 11gR2 versions. Thisparameter causes

Replicat to disable the work performed by triggers during its session. Itdoes not

disable a trigger, but instead prevents the trigger body from executing.The WHEN

portion of the trigger must still compile and execute correctly to avoiddatabase

errors.

Preparing integrity constraints in source and targettables

5-2 Oracle GoldenGate for Oracle Installation and Setup Guide

■ DBOPTIONS with DEFERREFCONST: Delays the checking andenforcement of cascade

update and cascade delete constraints until the Replicat transactioncommits.

■ For other Oracle versions, you must disable triggers andintegrity constraints or

alter them manually to ignore the Replicat database user.

Constraints must be disabled because Oracle GoldenGate replicates DML thatresults

from a trigger or a cascade constraint. If the same trigger or constraintgets activated

on the target table, it becomes redundant because of the replicatedversion, and the

database returns an error. Consider the following example, where thesource tables are

emp_src and salary_src and the target tables are emp_targ and salary_targ.

1. A delete is issued for emp_src.

2. It cascades a delete to salary_src.

3. Oracle GoldenGate sends both deletesto the target.

4. The parent delete arrives first andis applied to emp_targ.

5. The parent delete cascades a deleteto salary_targ.

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

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

5.1.2 Deferring constraint checking on targettables

You may need to defer constraint checking on the target.

1. If constraints are DEFERRABLE on the source, the constraints onthe target must also

be DEFERRABLE. You can use one of the followingparameter statements to defer

constraint checking until a Replicat transaction commits:

■ Use SQLEXEC at the rootlevel of the Replicat parameter file to defer the

constraints for an entire Replicat session.

SQLEXEC(“alter session set constraint deferred”)

■ Use the Replicat parameter DBOPTIONS with the DEFERREFCONST option to delay

constraint checking for each Replicat transaction.

2. You might need to configure Replicatto overcome integrity errors caused by

transient primary-key duplicates. Transient primary-key duplicates areduplicates

that occur temporarily during the execution of a transaction, but areresolved by

transaction commit time. This kind of operation typically uses a SET x = x+n

formula or some other manipulation that shifts values so that a new valueequals

an existing one.

The following illustrates a sequence of value changes that can cause atransient

primary-key duplicate if constraints are not deferred. The example assumesthe

primary key column is CODE and the currentkey values (before the updates) are 1,

2, and 3.

updateitem set code = 2 where code = 1;

updateitem set code = 3 where code = 2;

updateitem set code = 4 where code = 3;

In this example, when Replicat applies the first update to the target,there is an

ORA-00001 (unique constraint) error because the key value of 2 alreadyexists in the

table. The Replicat transaction returns constraint violation errors. Bydefault, Replicat

does not handle these violations and abends.

Preparing integrity constraints in source and targettables

Preparing thedatabase for Oracle GoldenGate 5-3

5.1.2.1 Handling transient primary-keyduplicates in versions earlier than 11.2.0.2

To handle transient primary-key duplicates in versions earlier than11.2.0.2, use the

Replicat parameter HANDLETPKUPDATE. In this configuration, Replicat handles transient

primary-key updates by temporarily deferring contraints. To support this

functionality, you must create or alter the constraints as DEFERRABLE INITIALLY

IMMEDIATEon the targettables. If the constraints are not DEFERRABLE, Replicat handles

the errors according to rules that are specified with the HANDLECOLLISIONS and

REPERRORparameters, ifthey exist, or else it abends.

5.1.2.2 Handling transient primary-keyduplicates in version 11.2.0.2 or later

For versions later than 11.2.0.2, Replicat by default tries to resolvetransient

primary-key duplicates automatically by using a workspace in OracleWorkspace

Manager. In this configuration, Replicat can defer the constraint checkinguntil commit

time without requiring the constraints to be explicitly defined asdeferrable.

The requirements for automatic handling of transient primary-keyduplicates are:

■ Grant the Replicat database user access to the followingOracle Streams function:

DBMS_XSTREAM_GG.ENABLE_TDUP_WORKSPACE()

■ The target tables cannot have deferrable constraints;otherwise Replicat returns an

error and abends.

To handle tables with deferrable constraints, make certain the constraintsare

DEFERRABLEINITIALLY IMMEDIATE, and use the HANDLETPKUPDATEparameter inthe MAP

statement that maps that table. The HANDLETPKUPDATE parameter overrides the default

of handling the duplicates automatically.

The use of a workspace affects the following Oracle GoldenGate errorhandling

parameters:

■ HANDLECOLLISIONS

■ REPERROR

When Replicat enables a workspace in Oracle Workspace Manager, it ignoresthe error

handling that is specified by Oracle GoldenGate parameters such as

HANDLECOLLISIONSand REPERROR. Instead, Replicat aborts itsgrouped transaction (if

BATCHSQLis ebabled),and then retries the update in normal mode by using the active

workspace. If ORA-00001 occurs again, Replicat rolls back the transactionand then

retries the transaction with error-handling rules in effect again.

A workspace cannot be used if the operation that contains a transientprimary-key

duplicate also has updates to any out-of-line columns, such as LOB andXMLType.

Therefore, these cases are not supported, and any such cases can result inundetected

data corruption on the target. An example of this is:

update Tset PK = PK + 1, C_LOB = "ABC";

5.1.3 Ensuring row uniqueness in source andtarget tables

Oracle GoldenGate requires a unique row identifier on the source andtarget tables to

locate the correct target rows for replicated updates and deletes. Unlessa KEYCOLS

Note: If Replicat encounters ORA-00001 fora non-update record, the

error-handling parameters such as HANDLECOLLISIONS and REPERROR

handle it.

Configuring logging properties

5-4 Oracle GoldenGate for Oracle Installation and Setup Guide

clause is used in the TABLE or MAP statement, Oracle GoldenGate selectsa row

identifier to use in the following order of priority:

1. Primary key

2. First unique key alphanumericallywith no virtual columns, no UDTs, no

function-based columns, and no nullable columns. A key cannot contain acolumn

that is part of an invisible index.

3. First unique key alphanumericallywith no virtual columns, no UDTs, and no

function-based columns, but can include nullable columns. A key cannotcontain a

column that is part of an invisible index.

4. If none of the preceding key typesexist (even though there might be other types of

keys defined on the table) Oracle GoldenGate constructs a pseudo key ofall

columns that the database allows to be used in a unique key, excludingvirtual

columns, UDTs, function-based columns, and any columns that are explicitly

excluded from the Oracle GoldenGate configuration.

If a table does not have an appropriate key, or if you prefer the existingkey(s) not to

be used, you can define a substitute key if the table has columns thatalways contain

unique values. You define this substitute key by including a KEYCOLS clause within the

Extract TABLE parameter and the Replicat MAP parameter. The specified key will

override any existing primary or unique key that Oracle GoldenGate finds.For more

information, see the Oracle GoldenGate Windows and UNIX ReferenceGuide.

5.2 Configuring logging properties

Oracle GoldenGate relies on the redo logs to capture the data and metadatathat it

needs to replicate source transactions. The Oracle redo logs must beconfigured

properly before you start Oracle GoldenGate processing. Because redovolume is

increased as the result of this required logging, you might want to waituntil just

before you start Oracle GoldenGate processing to enable the logging.

You will enable some or all of the following supplemental logging types:

■ Enabling FORCELOGGING

■ Enabling schema-level supplemental logging

■ Enabling table-level supplemental logging

5.2.1 Enabling FORCELOGGING

Perform the following steps to put the database in forced logging mode.This mode

overrides all tablespace and segment settings, ensuring that alltransactions and loads

are logged so that no source data in the Extract configuration getsmissed.

1. Log in to SQL*Plus as a user with ALTER SYSTEM privilege, and then issue the

following command to determine whether the database is in forced loggingmode.

Note: If there are other, non-usable keyson a table or if there are no

keys at all on the table, Oracle GoldenGate logs an appropriate

message to the report file. Constructing a key from all of the columns

impedes the performance of Oracle GoldenGate on the source system.

On the target, this key causes Replicat to use a larger, less efficient

WHERE clause.

Configuring logging properties

Preparing thedatabase for Oracle GoldenGate 5-5

If the result is YES, forcedlogging is enabled and meets the Oracle GoldenGate

requirement. If the result is NO, continue withthese steps to enable forced logging.

SELECTforce_logging FROM v$database;

2. Enable forced logging.

ALTERDATABASE FORCE LOGGING;

3. Verify that forced logging isenabled.

SELECTforce_logging FROM v$database;

The output must be YES. Thisstatement can take a considerable time for

completion, because it waits for all unlogged direct writes to complete. Afterthe

command completes, go to the next step to switch log files.

4. Switch the log files.

ALTERSYSTEM SWITCH LOGFILE;

5.2.2 Enabling schema-level supplementallogging

If you will be using the Oracle GoldenGate DDL replication feature,perform the

following steps to enable schema-level supplemental logging of the sourcetables. The

command you will use, ADD SCHEMATRANDATA, logs all valid keys atomically when each

DDL operation occurs. ADD SCHEMATRANDATA enables this logging for all of the current

and future tables of a given schema. See the ADD SCHEMATRANDATA command in the

Oracle GoldenGate Windows and UNIX Reference Guide for additional usage

considerations.

1. (Solaris systems) Apply Oracle Patch10423000 to the source Oracle database if the

version is earlier than 11.2.0.2.

2. Run GGSCI on the source system.

3. Issue the DBLOGIN command as a user that has privilegeto enable schema-level

supplemental logging.

DBLOGINUSERID user, PASSWORD password [encryption options]

See the Oracle GoldenGate Windows and UNIX Reference Guide for password

encryption options for DBLOGIN.

4. Issue the ADD SCHEMATRANDATA command for each schema for whichyou want to

capture data changes.

ADDSCHEMATRANDATA schema

As an example, the following commands enable supplemental logging for the

finance and hr schemas.

ADDSCHEMATRANDATA finance

ADDSCHEMATRANDATA hr

5.2.3 Enabling table-level supplementallogging

Perform the following steps to enable table-level supplemental logging ofkey values

for use by Oracle GoldenGate. The command you will issue, ADD TRANDATA, also

provides a COLS option to log non-key columns foruse in a KEYCOLS clause or for

filtering or manipulation.

1. Run GGSCI on the source system.

Limiting row changes in tables that do not have a uniquerow identifier

5-6 Oracle GoldenGate for Oracle Installation and Setup Guide

2. Issue the DBLOGIN command as a user that has privilegeto enable table-level

supplemental logging.

DBLOGINUSERID user, PASSWORD password [encryption options]

See the Oracle GoldenGate Windows and UNIX Reference Guide for password

encryption options for DBLOGIN.

3. Issue the ADD TRANDATA command.

ADDTRANDATA table [, COLS columns] [, NOKEY]

Where:

■ table is the owner and name of the table.You can use a wildcard for the table

name, but not the owner name.

■ COLS columns logs non-key columns that arerequired for a KEYCOLS clause or

for filtering and manipulation.

■ NOKEY prevents thelogging of the primary key or unique key. Requires a

KEYCOLS clause in the TABLE and MAP parameters and a COLS clause in the ADD

TRANDATAcommand to logthe KEYCOLS columns.

4. If using ADD TRANDATA with the COLS option, create a unique index forthose

columns on the target to optimize row retrieval. If you are logging thosecolumns

as a substitute key for a KEYCOLS clause, make anote to add the KEYCOLS clause to

the TABLE and MAP statements when you configure the Oracle GoldenGate

processes.

See the ADD TRANDATA command in the Oracle GoldenGate Windowsand UNIX

Reference Guide for additional usage considerations.

5.3 Limiting row changes in tables that donot have a unique row

identifier

If a target Oracle table does not have a primary key or a unique key,duplicate rows

can exist. In this case, Oracle GoldenGate could update or delete too manytarget rows,

causing the source and target data to go out of synchronization withouterror

messages to alert you.

To limit the number of rows that are updated, use the DBOPTIONS parameter with the

LIMITROWSoption in theReplicat parameter file. LIMITROWS can increase the

performance of Oracle GoldenGate on the target system because only one rowis

processed.

5.4 Supporting the conversion of charactersets

When replicating from a source Windows-based or UNIX-based database to atarget

Oracle database that has another character set, Replicat allows Oracle toperform the

character-set conversion. When replicating from a z/OS system, Replicatperforms the

conversion.

To support the conversion of character sets by an Oracle target database,the NLS_LANG

environment variable must be set to the character set of the sourcedatabase on the

target system. You can use the Replicat parameter SETENV to set NLS_LANG for the

Replicat client session, instead of setting it at the system level. Whenset from the

parameter file, it is less likely to be changed than at the system level.(Note: Oracle

Setting fetch options

Preparing thedatabase for Oracle GoldenGate 5-7

GoldenGate programmatically sets NLS_LANG to the sourcedatabase character set on

the source.)

5.4.1 Setting NLS_LANG with SETENV

These instructions set NLS_LANG from theReplicat parameter file.

1. Use the following syntax to set NLS_LANG with the SETENV parameter.

SETENV(NLS_LANG = NLS_LANGUAGE_NLS_TERRITORY.NLS_CHARACTERSET)

The following is an example from the UNIX platform:

SETENV(NLS_LANG = “AMERICAN_AMERICA.AL32UTF8”)

2. Stop and then start the OracleGoldenGate Manager process so that the processes

recognize the new variable.

5.4.2 Viewing globalization settings

To determine the globalization settings of the database and whether it isusing byte or

character semantics, use the following commands in SQL*Plus:

SHOWPARAMETER NLS_LANGUAGE

SHOWPARAMETER NLS_TERRITORY

SELECTname, value$ from SYS.PROPS$ WHERE name = 'NLS_CHARACTERSET';

SHOWPARAMETER NLS_LENGTH_SEMANTICS

The VIEW REPORT command in GGSCI shows the currentdatabase language and

character settings and indicates whether or not NLS_LANG is set.

5.4.3 Getting more information aboutglobalization support

For more information about support for character sets by OracleGoldenGate, see the

Oracle GoldenGate Windows and UNIX Administrator's Guide.

5.5 Setting fetch options

To process certain update records, Extract fetches additional row datafrom the source

database. Oracle GoldenGate fetches data for the following:

■ User-defined types

■ Nested tables

■ XMLType objects

By default, Oracle GoldenGate uses Flashback Query to fetch the valuesfrom the undo

(rollback) tablespaces. That way, Oracle GoldenGate can reconstruct aread-consistent

row image as of a specific time or SCN to match the redo record.

For best fetch results, configure the source database as follows:

1. Set a sufficient amount of redoretention by setting the Oracle initialization

parameters UNDO_MANAGEMENTand UNDO_RETENTION as follows (in seconds).

UNDO_MANAGEMENT=AUTO

UNDO_RETENTION=86400

UNDO_RETENTIONcan be adjustedupward in high-volume environments.

Setting fetch options

5-8 Oracle GoldenGate for Oracle Installation and Setup Guide

2. Calculate the space that is requiredin the undo tablespace by using the following

formula.

undo space = UNDO_RETENTION * UPS + overhead

Where:

■ undo space is the number of undo blocks.

■ UNDO_RETENTION is the value of the UNDO_RETENTION parameter (in seconds).

■ UPS is the number of undo blocks foreach second.

■ overhead is the minimal overhead for metadata(transaction tables, etc.).

Use the system view V$UNDOSTAT to estimate UPS and overhead..

3. For tables that contain LOBs, do one of the following:

■ Set the LOB storage clauseto RETENTION. This is the default for tablesthat are

created when UNDO_MANAGEMENTis set to AUTO.

■ If using PCTVERSION instead of RETENTION, set PCTVERSION to an initial value of

25. You can adjust it based on the fetch statistics that are reported withthe

STATS EXTRACTcommand (see Table 5–1). If the value of the STAT_OPER_

ROWFETCHCURRENTBYROWID or STAT_OPER_ROWFETCH_CURRENTBYKEYfield in

these statistics is high, increase PCTVERSION in increments of 10 until the

statistics show low values.

4. Grant the following privileges tothe Oracle GoldenGate Extract user:

GRANTFLASHBACK ANY TABLE TO db_user

Or ...

GRANTFLASHBACK ON owner.table TO db_user

Oracle GoldenGate provides the following parameters to manage fetching.

Table 5–1 Oracle GoldenGate parameters andcommands to manage fetching

Parameter or Command Description

STATSEXTRACT command with

REPORTFETCHoption

Shows Extract fetch statistics on demand.

STATOPTIONSparameter with

REPORTFETCHoption

Sets the STATS EXTRACT command so that it always showsfetch statistics.

MAXFETCHSTATEMENTS

parameter

Controls the number of open cursors for prepared queries that Extractmaintains

in the source database, and also for SQLEXEC operations.

MAXFETCHSTATEMENTS

parameter

Controls the default fetch behavior of Extract: whether Extract performs a

flashback query or fetches the current image from the table.

FETCHOPTIONSparameter with

the USELATESTVERSIONor

NOUSELATESTVERSIONoption

Handles the failure of an Extract flashback query, such as if the undoretention

expired or the structure of a table changed. Extract can fetch the currentimage

from the table or ignore the failure.

REPFETCHEDCOLOPTIONS

parameter

Controls the response by Replicat when it processes trail records thatinclude

fetched data or column-missing conditions.

Handling special data types

Preparing thedatabase for Oracle GoldenGate 5-9

5.6 Handling special data types

This section applies whether Extract operates in classic or integratedcapture mode,

unless otherwise noted. It addresses special configuration requirementsfor the

following Oracle data types:

■ Multibyte character types

■ Oracle Spatial objects

■ TIMESTAMP

■ Large Objects (LOB)

■ XML

■ User defined types

5.6.1 Multibyte character types

Multi-byte characters are supported as part of a supported character set.If the

semantics setting of an Oracle source database is BYTE and the setting of an Oracle

target is CHAR, use the Replicat parameter SOURCEDEFS in your configuration, and place

a definitions file that is generated by the DEFGEN utility on the target.These steps are

required to support the difference in semantics, whether or not the sourceand target

data definitions are identical. Replicat refers to the definitions file todetermine the

upper size limit for fixed-size character columns.

For more information about character-set support, see the OracleGoldenGate Windows

and UNIX Administrator's Guide.

For information about SOURCEDEFS and the DEFGEN utility, see the Oracle GoldenGate

Windows and UNIX Administrator's Guide.

5.6.2 Oracle Spatial objects

To replicate tables that contain one or more columns of SDO_GEORASTER object type

from an Oracle source to an Oracle target, follow these instructions toconfigure Oracle

GoldenGate to process them correctly.

1. Create a TABLE statement and a MAP statement for the georaster tablesand also for

the related raster data tables.

2. If the METADATA attribute of the SDO_GEORASTER data type in any of the values

exceeds 1 MB, use the DBOPTIONS parameter with the XMLBUFSIZE option to

increase the size of the memory buffer that stores the embedded SYS.XMLTYPE

attribute of the SDO_GEORASTER data type. If the buffer is too small, Extract abends.

For more information about XMLBUFSIZE, see DBOPTIONS in the Oracle GoldenGate

Windows and UNIX Reference Guide.

3. To ensure the integrity of thetarget georaster tables and the spatial data, keep the

trigger enabled on both source and target.

4. Use the REPERROR option of the MAP parameter to handle the “ORA-01403No data

found” error that occurs as a result of keeping the trigger enabled on thetarget. It

occurs when a row in the source georaster table is deleted, and thetrigger

cascades the delete to the raster data table. Both deletes are replicated.The

replicated parent delete triggers the cascaded (child) delete on thetarget. When

the replicated child delete arrives, it is redundant and generates theerror. To use

REPERROR, do the following:

Handling special data types

5-10 Oracle GoldenGate for Oracle Installation and Setup Guide

■ Use a REPERROR statement ineach MAP statement that contains a rasterdata

table.

■ Use Oracle error 1403 as the SQL error.

■ Use any of the response options as the error handling.

A sufficient way to handle the errors on raster tables caused by activetriggers on

target georaster tables is to use REPERROR with DISCARD to discard the cascaded delete

that triggers them. The trigger on the target georaster table performs thedelete to the

raster data table, so the replicated one is not needed.

MAPgeo.st_rdt, TARGET geo.st_rdt, REPERROR (-1403, DISCARD) ;

If you need to keep an audit trail of the error handling, use REPERROR with EXCEPTION

to invoke exceptions handling. For this, you create an exceptions tableand map the

source raster data table twice:

■ once to the actual target raster data table (with REPERROR handling the 1403 errors).

■ again to the exceptions table, which captures the 1403error and other relevant

information by means of a COLMAP clause.

For more information about using an exceptions table, see the OracleGoldenGate

Windows and UNIX Administrator's Guide.

For more information about REPERROR options, seethe Oracle GoldenGate Windows and

UNIX Reference Guide.

5.6.3 TIMESTAMP

To replicate timestamp data, follow these guidelines.

1. To prevent Oracle GoldenGate fromabending on TIMESTAMP WITHTIME ZONE as

TZR, use the Extract parameter TRANLOGOPTIONS with one of the following:

■ INCLUDEREGIONID to replicate TIMESTAMP WITH TIME ZONE as TZR from an

Oracle source to an Oracle target of the same version or later.

■ INCLUDEREGIONIDWITHOFFSET to replicate TIMESTAMP WITH TIMEZONE as TZR

from an Oracle source that is at least v10g to an earlier Oracle target,or from

an Oracle source to a non-Oracle target.

These options allow replication to Oracle versions that do not support TIMESTAMP

WITHTIME ZONE as TZR and to database systems that onlysupport time zone as a

UTC offset. For more information, see TRANLOGOPTIONS in the Windows and UNIX

Reference Guide.

2. Because the Oracle databasenormalizes TIMESTAMP WITHLOCAL TIME ZONE data

to the local time zone of the database that receives it, the timestamps donot

transfer correctly between databases that are in different time zones. Forexample,

data that reflects 5:00 a.m. EST on a source server in New York Citybecomes 5:00

a.m. PST on a target server in San Francisco, when it should be 2:00 a.m.in San

Francisco time to reflect the three-hour difference in time zones.

To adjust the timestamp to the target time zone for all of the recordsthat are

applied by Replicat , place the following parameter statement after the USERID

parameter, but before the first MAP statement, inthe Replicat parameter file:

SQLEXEC"ALTER SESSION SET TIME_ZONE = ‘value of source_timezone’"

Where: value of source_timezone is the offset from the source timezone. For

example, using the previous example, the value would be ‘-03:00.’ Use aplus (+)

Handling special data types

Preparing thedatabase for Oracle GoldenGate 5-11

or minus (-) sign, depending on whether the target is ahead of, or behind,the

source time.

5.6.4 Large Objects (LOB)

The following are some configuration guidelines for LOBs in both classiccapture and

integrated capture mode.

1. Store large objects out of row ifpossible.

2. Replicat writes LOB data to a targetdatabase in fragments. To minimize the effect

of this I/O on the system, Replicat enables Oracle’s LOB cachingmechanism,

caches the fragments in a buffer, and performs a write only when thebuffer is full.

For example, if the buffer is 25,000 bytes in size, Replicat only performsI/O four

times given a LOB of 100,000 bytes.

■ To optimize the buffer size to the size of your LOB data,use the DBOPTIONS

parameter with the LOBWRITESIZE option. The higher the value, the fewer the

I/O calls made by Replicat to write one LOB.

■ To disable Oracle’s LOB caching, use the DBOPTIONS parameter with the

DISABLELOBCACHINGoption. WhenLOB caching is disabled, whatever is sent

by Replicat to Oracle in one I/O call is written directly to the databasemedia.

3. If CLOB columns can store binary data, setthe NLS_LANG system environment

variable and the NLS_LANGUAGE database parameter to the same value.

4. (Applies only to integrated capture)Integrated capture captures LOBs from the

redo log. For UPDATE operations on a LOB document, onlythe changed portion of

the LOB is logged. To force whole LOB documents to be written to the trailwhen

only the changed portion is logged, use the TRANLOGOPTIONS parameter with the

FETCHPARTIALLOBoption in theExtract parameter file. When Extract receives

partial LOB content from the logmining server, it fetches the full LOBimage

instead of processing the partial LOB. Use this option when replicating toa

non-Oracle target or in other conditions where the full LOB image isrequired. For

more information about TRANLOGOPTIONS, see the Oracle GoldenGate Windows and

UNIX Reference Guide.

5.6.5 XML

The following are tools for working with XML within Oracle GoldenGateconstraints.

■ Although both classic and integrated capture modes do notsupport the capture of

changes made to an XML schema, you may be able to evolve the schemas andthen

resume replication of them without the need for a resynchronization. See

"Supporting changes to XML schemas" on page C-1.

■ (Applies only to integrated capture) Integrated capturecaptures XML from the

redo log. For UPDATE operations on an XML document, onlythe changed portion

of the XML is logged if it is stored as OBJECT RELATIONAL or BINARY. To force

whole XML documents to be written to the trail when only the changedportion is

logged, use the TRANLOGOPTIONS parameter with the FETCHPARTIALXML option in

the Extract parameter file. When Extract receives partial XML content fromthe

logmining server, it fetches the full XML document instead of processingthe

partial XML. Use this option when replicating to a non-Oracle target or inother

conditions where the full XML image is required. For more informationabout

TRANLOGOPTIONS, see the Oracle GoldenGate Windowsand UNIX Reference Guide.

Handling other database properties

5-12 Oracle GoldenGate for Oracle Installation and Setup Guide

5.6.6 User defined types

Extract fetches UDTs (except for object tables) from the database. Formore

information, see "Setting fetch options" on page 5-7.

5.7 Handling other database properties

The following table shows database properties that may affect OracleGoldenGate and

the parameters that you can use to resolve or work around the condition.

5.8 Using Oracle GoldenGate with OracleExadata

Oracle GoldenGate supports Oracle Exadata Database Machine as follows:

Table 5–2 Handling other database properties

Database Property Concern/Resolution

Table with unused

columns

By default, unused columns are not supported. To support them, use the DBOPTIONS

parameter with the ALLOWUNUSEDCOLUMN option to force Extract to generate a warning

and continue processing. The same unused column must exist in the targettable, or a

source definitions file must be created for Replicat with the DEFGENutility. You can

include the appropriate ALTER TABLE...SET UNUSED statements in a DDL replication

configuration.

Table with interval

partitioning

To support tables with interval partitioning, make certain that the WILDCARDRESOLVE

parameter remains at its default of DYNAMIC.

Table with virtual columns Virtual columns are not logged, and Oracle doesnot permit DML on virtual columns.

You can, however, capture this data and map it to a target column that isnot a virtual

column by doing the following:

Include the table in the Extract TABLE statement anduse the FETCHCOLS option of

TABLE to fetch the value from the virtualcolumn in the database.

In the Replicat MAP statement, map the source virtualcolumn to the non-virtual target

column.

Table with inherently

updateable view

To replicate to an inherently updateable view, define a key on the uniquecolumns in

the updateable view by using a KEYCOLS clause in thesame MAP statement in which

the associated source and target tables are mapped.

Redo logs or archives in

different locations

The TRANLOGOPTIONS parameter contains options to handleenvironments where the

redo logs or archives are stored in a different location than the databasedefault or on

a different platform from that on which Extract is running.

TRUNCATEoperations Toreplicate TRUNCATE operations, choose one of twooptions:

Standalone TRUNCATEsupport bymeans of the GETTRUNCATES parameter replicates

TRUNCATETABLE, but no other TRUNCATE options.

The full DDL support replicates TRUNCATE TABLE, ALTER TABLETRUNCATE PARTITION,

and other DDL. To install this support, see "Installing OracleGoldenGate DDL

support for an Oracle database" on page 3-1.

Sequences To replicate DDL for sequences (CREATE, ALTER, DROP, RENAME), use OracleGoldenGate

DDL support.

To replicate just sequence values, use the SEQUENCE parameter in the Extract

parameter file. This does not require the Oracle GoldenGate DDLsupport

environment. See SEQUENCE in the OracleGoldenGate Windows and UNIX Reference

Guide for additional requirements.

Using Oracle GoldenGate with Oracle Exadata

Preparing thedatabase for Oracle GoldenGate 5-13

■ Oracle GoldenGate can capture from Exadata in eitherclassic capture or

integrated capture mode, but to capture from Exadata with EHCC compression

enabled, Extract must be in integrated capture mode.

■ Oracle GoldenGate can replicate data from any supporteddatabase to Exadata.

In general, the configuration of Oracle GoldenGate to operate with Exadatais the same

as any other Oracle GoldenGate configuration. These instructions highlight

configuration requirements that are different from the standard OracleGoldenGate

installation.

5.8.1 Migrating to Oracle Exadata

Oracle GoldenGate supports the logical migration of data to Exadata withunload and

reload performed through SQL. To migrate from other databases to ExadataDatabase

Machine, you can do one of the following:

■ Migrate to Exadata by using an initial load

■ Migrate to Exadata by using an active-passiveconfiguration

5.8.1.1 Migrate to Exadata by using aninitial load

One way to migrate from your original database to Exadata is to perform asimple

initial load from one system to the other. This is a uni-directionalinitial

synchronization of the source and target tables, while Oracle GoldenGatecaptures any

ongoing transactions that must remain active. Install Oracle GoldenGate onboth

systems, and follow the configuration, database setup, and initial loadinstructions in

this guide. For additional initial load options, see the Oracle GoldenGateWindowsand

UNIX Administrator's Guide.

5.8.1.2 Migrate to Exadata by using anactive-passive configuration

You can use an active-passive bi-directional configuration to migrate toExadata. The

active database is the primary database from which the data isbeing migrated, and the

passive database is the Exadata machine. Inthis configuration, the Exadata machine

can work in tandem with the original system until testing is completed andyou switch

operations over to the Exadata machine.

No special setup is needed if using integrated capture to deploy thisconfiguration.

However, to use classic capture mode, include the following TRANLOGOPTIONS

statements in the Extract parameter file on the Exadata machine:

■ TRANLOGOPTIONS with DBLOGREADER: Uses the Oracle database server toaccess the

log files, instead of connecting to the Oracle ASM instance, for improvedread

performance. This option is supported for Oracle 10.2.0.5, and for Oracle11.1.0.7

and later 11g R2 versions (but not Oracle 11g R1 versions).

■ TRANLOGOPTIONS with ASMUSER: Logs into ASM to access the logfiles. This option

provides a backup in the event that the source database becomesunavailable, so

that Extract can continue to read the log files directly in ASM.

Each of these should be a separate TRANLOGOPTIONS parameter statement: comment out

the ASMUSER one until it is needed in a databaseserver failure. For syntax for these

parameters and other options for tuning ASM interactivity, see TRANLOGOPTIONS in the

Oracle GoldenGate Windows and UNIX Reference Guide.

To deploy a migration to Exadata using an active-passive configuration:

■ Install Oracle GoldenGate on both systems, and follow theconfiguration, database

setup, and initial load instructions in this guide.

Using Oracle GoldenGate with Oracle Exadata

5-14 Oracle GoldenGate for Oracle Installation and Setup Guide

■ For the specifics of configuring the active-passivetopology, see the Oracle

GoldenGate Windows and UNIX Administrator's Guide.

5.8.2 Replicating to Exadata with EHCCenabled

To ensure successful delivery of insert operations to Oracle Exadata withHybrid

Columnar Compression (EHCC), use the INSERTAPPEND parameter in the Replicat

parameter file. INSERTAPPEND causes Replicat to use an APPEND hint forinserts so they

remain compressed. Without this hint, the record will be inserteduncompressed. For

more information about INSERTAPPEND, see the Oracle GoldenGate Windows and UNIX

Reference Guide.

6

Additionalconfiguration steps when using classic capture 6-1

6Additionalconfiguration steps when using

classic capture

This chapter contains additional configuration and preparationrequirements that are

specific only to Extract when operating in classic capture mode. Other preparation steps

are also required. See the following topics:

"System requirements and preinstallation instructions" on page 1-1

"Installing Oracle GoldenGate" on page 2-1

"Installing Oracle GoldenGate DDL support for an Oracledatabase" on page 3-1

"Preparing the database for Oracle GoldenGate" on page 5-1

"Configuring Oracle GoldenGate on Oracle source and targetdatabases" on page 4-1

"Configuring DDL synchronization for an Oracle database" on page 7-1

To instantiate Oracle GoldenGate processing, see the following topics:

"Instantiating and starting Oracle GoldenGate replication" on page 8-1

"Controlling processes" on page 9-1

Additional topics may apply:

"Supporting changes to XML schemas" on page C-1

"Preparing DBFS for active-active propagation with OracleGoldenGate" on page D-1

For more information about classic capture, see "Deciding which capturemethod to

use" on page 4-3.

6.1 Configuring Oracle TDE data in classiccapture mode

The following special configuration steps are required to support TDE whenExtract is

in classic capture mode.

6.1.1 Overview of TDE support in classiccapture

TDE support when Extract is in classic capture mode requires the exchangeof two

kinds of keys:

■ The encrypted key can be a table key (column-levelencryption), an encrypted redo

log key (tablespace-level encryption), or both. A key is shared betweenthe Oracle

database and Extract.

Configuring Oracle TDE data in classic capture mode

6-2 Oracle GoldenGate for Oracle Installation and Setup Guide

■ The decryption key is a password known as the sharedsecret that is storedsecurely

in the Oracle and Oracle GoldenGate domains. Only a party that haspossession of

the shared secret can decrypt the table and redo log keys.

The encrypted keys are delivered to the Extract process by means ofbuilt-in PL/SQL

code. Extract uses the shared secret to decrypt the data. Extract neverhandles the

wallet master key itself, nor is it aware of the master key password.Those remain

within the Oracle database security framework.

Extract never writes the decrypted data to any file other than a trailfile, not even a

discard file (specified with the DISCARDFILE parameter). The word “ENCRYPTED” will be

written to any discard file that is in use.

The impact of this feature on Oracle GoldenGate performance should mirrorthat of

the impact of decryption on database performance. Other than a slightincrease in

Extract startup time, there should be a minimal affect on performance fromreplicating

TDE data.

6.1.2 Requirements for capturing TDE inclassic capture mode

The following are requirements for Extract to support TDE capture:

■ To maintain high security standards, the OracleGoldenGate Extract process

should run as part of the oracle user (the userthat runs the Oracle database). That

way, the keys are protected in memory by the same privileges as the oracle user.

■ The Extract process must run on the same machine as thedatabase installation.

6.1.3 Required database patches

To support TDE on Oracle 10.2.0.5 or 11.2.0.2, download and apply OraclePatch

10395645 to the source database. Oracle 11.2.0.3 patchset includes thispatch. If you

cannot find this patch on the My Oracle Support website

(https://support.oracle.com), submit a service request (SR) andrequest a

backport.

6.1.4 Configuring TDE support

The following outlines the steps that the Oracle Security Officer and theOracle

GoldenGate Administrator take to establish communication between theOracle server

and the Extract process.

6.1.4.1 Agree on a shared secret that meetsOracle standards

Agree on a shared secret (password) that meets or exceedsOracle password standards.

This password must not be known by anyone else. For guidelines on creatingsecure

passwords, see Oracle Database Security Guide.

6.1.4.2 Oracle DBA tasks

1. Log in to SQL*Plus as a user withthe SYSDBA system privilege. For example:

Note: These steps assume that TDE isconfigured correctly within

the Oracle database and that you have configured your software

keystore or hardware security module (HSM) to work correctly with

TDE. For more information about configuring TDE, see the Oracle

Database Advanced Security Administrator’sGuide.

Configuring Oracle TDE data in classic capture mode

Additionalconfiguration steps when using classic capture 6-3

sqlplussys/as sysdba

Connected.

Enterpassword: password

2. Run the prvtclkm.plb file that is installed in the Oracleadmin directory. The

prvtclkm.plbfile createsthe DBMS_INTERNAL_CLKMPL/SQL package,which

enables Oracle GoldenGate to extract encrypted data from an Oracledatabase.

@?/app/oracle/product/orcl111/rdbms/admin/prvtclkm.plb

3. Grant EXEC privilege on DBMS_INTERNAL_CLKM PL/SQL package to the Extract

database user.

GRANTEXECUTE ON DBMS_INTERNAL_CLKM TO psmith;

4. Exit SQL*Plus.

6.1.4.3 Oracle Security Officer tasks

1. Create an entry for ORACLEGG in the wallet. ORACLEGG must be the name of the key.

Note: Do not supply the shared secret on the command line; supply it when

prompted.

mkstore-wrl ./ -createEntry ORACLE.SECURITY.CL.ENCRYPTION.ORACLEGG

OracleSecret Store Tool : Version 11.2.0.3.0 - Production

Copyright(c) 2004, 2011, Oracle and/or its affiliates. All rights reserved.

Yoursecret/Password is missing in the command line

Enteryour secret/Password: sharedsecret

Re-enteryour secret/Password: sharedsecret

Enterwallet password: wallet_password

2. Verify the ORACLEGG entry.

mkstore-wrl . -list

OracleSecret Store Tool : Version 11.2.0.3.0 - Production

Copyright(c) 2004, 2011, Oracle and/or its affiliates. All rights reserved.

Enterwallet password: wallet_password

OracleSecret Store entries:

ORACLE.SECURITY.CL.ENCRYPTION.ORACLEGG

3. Log in to SQL*Plus as a user withthe SYSDBA system privilege.

4. Close and then re-open the wallet.

SQL>alter system set encryption wallet close identified by "wallet_password";

Systemaltered.

SQL>alter system set encryption wallet open identified by "wallet_password";

Systemaltered.

5. Switch log files.

altersystem switch logfile;

Systemaltered.

6. If this is an Oracle RAC environmentand you are using copies of the wallet on

each node, make the copies now and then reopen each wallet.

Note: Oracle recommends using one walletin a shared location, with

synchronized access among all Oracle RAC nodes.

Configuring Oracle TDE data in classic capture mode

6-4 Oracle GoldenGate for Oracle Installation and Setup Guide

6.1.4.4 Oracle GoldenGate Administrator tasks

1. Run GGSCI.

2. Issue the ENCRYPT PASSWORD command to encrypt the shared secretso that it is

obfuscated within the Extract parameter file. This is a securityrequirement.

ENCRYPTPASSWORD sharedsecret{AES128 | AES192| AES256} ENCRYPTKEY keyname

Where:

■ sharedsecret is the clear-text shared secret.This value is case-sensitive.

■ {AES128 | AES192 | AES256} specifies Advanced Encryption Standard (AES)

encryption. Specify one of the values, which represents the desired keylength.

■ keyname is the logical name of theencryption key in the ENCKEYS lookup file.

Oracle GoldenGate uses this key to look up the actual key in the ENCKEYS file.

To create a key and ENCKEYS file, see theOracle GoldenGate Windows and

UNIX Administrator's Guide.

Example:

ENCRYPTPASSWORD sharedsecret AES256 ENCRYPTKEY mykey1

3. In the Extract parameter file, usethe DBOPTIONS parameter with the

DECRYPTPASSWORDoption. Asinput, supply the encrypted shared secret and the

decryption key.

DBOPTIONSDECRYPTPASSWORD sharedsecret {AES128 | AES192 | AES256} ENCRYPTKEY

keyname

Where:

■ sharedsecret is the encrypted shared secret.

■ {AES128 | AES192 | AES256} must be same value that was used for ENCRYPT

PASSWORD.

■ keyname is the logical name of theencryption key in the ENCKEYS lookup file.

Example:

DBOPTIONSDECRYPTPASSWORD AACAAAAAAAAAAAIALCKDZIRHOJBHOJUH AES256

ENCRYPTKEYmykey1

4. Log in to SQL*Plus as a user withthe SYSDBA system privilege.

5. Close and then re-open the wallet.

SQL>alter system set encryption wallet close identified by "wallet_password";

Systemaltered.

SQL>alter system set encryption wallet open identified by "wallet_password";

Systemaltered.

6.1.5 Recommendations for maintaining datasecurity after decryption

Extract decrypts the TDE data and writes it to the trail as clear text. Tomaintain data

security throughout the path to the target database, it is recommendedthat you also

deploy Oracle GoldenGate security features to:

■ encrypt the data in the trails

■ encrypt the data in transit across TCP/IP

Configuring Oracle TDE data in classic capture mode

Additionalconfiguration steps when using classic capture 6-5

For more information, see the security chapter in the Windowsand UNIX

Administrator's Guide.

6.1.6 Performing DDL while TDE capture isactive

If DDL will ever be performed on a table that has column-level encryption,or if table

keys will ever be re-keyed, you must either quiesce the table while theDDL is

performed or enable Oracle GoldenGate DDL support. It is more practical tohave the

DDL environment active so that it is ready, because a re-key usually is aresponse to a

security violation and must be performed immediately. To install theOracle

GoldenGate DDL environment, see the instructions in this guide. Toconfigure Oracle

GoldenGate DDL support, see the Windows and UNIXAdministrator's Guide. For

tablespace-level encryption, the Oracle GoldenGate DDL support is notrequired.

6.1.7 Updating the Oracle shared secret inthe parameter file

Use this procedure to update and encrypt the TDE shared secret within theExtract

parameter file.

1. Run GGSCI.

2. Stop the Extract process.

STOPEXTRACT group

3. Modify the ORACLEGG entry in the Oracle wallet. ORACLEGG must remain the name

of the key. For instructions, see the Oracle Database AdvancedSecurity

Administrator’s Guide.

4. Issue the ENCRYPT PASSWORD command to encrypt the new sharedsecret.

ENCRYPTPASSWORD sharedsecret{AES128 | AES192| AES256} ENCRYPTKEY keyname

Where:

■ sharedsecret is the clear-text shared secret.This value is case-sensitive.

■ {AES128 | AES192 | AES256} specifies Advanced Encryption Standard (AES)

encryption. Specify one of the values, which represents the desired keylength.

■ keyname is the logical name of the encryptionkey in the ENCKEYS lookup file.

Example:

ENCRYPTPASSWORD sharedsecret AES256 ENCRYPTKEY mykey1

5. In the Extract parameter file, usethe DBOPTIONS parameter with the

DECRYPTPASSWORDoption. Asinput, supply the encrypted shared secret and the

Oracle GoldenGate-generated or user-defined decryption key.

DBOPTIONSDECRYPTPASSWORD sharedsecret {AES128 | AES192 | AES256} ENCRYPTKEY

keyname

Where:

■ sharedsecret is the encrypted shared secret.

■ {AES128 | AES192 | AES256} must be same value that was used for ENCRYPT

PASSWORD.

■ keyname is the logical name of theencryption key in the ENCKEYS lookup file.

Example:

Using Oracle GoldenGate in an Oracle RAC environment

6-6 Oracle GoldenGate for Oracle Installation and Setup Guide

DBOPTIONSDECRYPTPASSWORD AACAAAAAAAAAAAIALCKDZIRHOJBHOJUH AES256

ENCRYPTKEYmykey1

6. Log in to SQL*Plus as a user withthe SYSDBA system privilege.

7. Close and then re-open the wallet.

SQL>alter system set encryption wallet close identified by "wallet_password";

Systemaltered.

SQL>alter system set encryption wallet open identified by "wallet_password";

Systemaltered.

8. Start Extract.

STARTEXTRACT group

6.2 Using Oracle GoldenGate in an Oracle RACenvironment

The following general guidelines apply to Oracle RAC when Extract isoperating in

classic capture mode.

■ During operations, if the primary database instanceagainst which Oracle

GoldenGate is running stops or fails for any reason, Extract abends. Toresume

processing, you can restart the instance or mount the Oracle GoldenGatebinaries

to another node where the database is running and then restart the Oracle

GoldenGate processes. Stop the Manager process on the original node before

starting Oracle GoldenGate processes from another node.

■ Whenever the number of redo threads changes, the Extractgroup must be

dropped and re-created. For the recommended procedure, see the Oracle

GoldenGate Windows and UNIX Administrator's Guide.

■ Extract ensures that transactions are written to thetrail file in commit order,

regardless of the RAC instance where the transaction originated. WhenExtract is

capturing in archived-log-only (ALO) mode, where one or more RAC instances

may be idle, you may need to perform archive log switching on the idlenodes to

ensure that operations from the active instances are recorded in the trailfile in a

timely manner. You can instruct the Oracle RDBMS to do this log archiving

automatically at a preset interval by setting the archive_lag_target parameter.

For example, to ensure that logs are archived every fifteen minutes,regardless of

activity, you can issue the following command in all instances of the RACsystem:

SQL>alter system set archive_lag_target 900

■ To process the last transaction in a RAC cluster beforeshutting down Extract,

insert a dummy record into a source table that Oracle GoldenGate isreplicating,

and then switch log files on all nodes. This updates the Extractcheckpoint and

confirms that all available archive logs can be read. It also confirmsthat all

transactions in those archive logs are captured and written to the trailin the

correct order.

The following table shows some Oracle GoldenGate parameters that are ofspecific

benefit in Oracle RAC.

Capturing from an Oracle ASM instance when in classiccapture mode

Additionalconfiguration steps when using classic capture 6-7

6.3 Capturing from an Oracle ASM instancewhen in classic capture

mode

This topic covers additional configuration requirements that apply whenOracle

GoldenGate operates against transaction logs that are stored in OracleAutomatic

Storage Management (ASM). Oracle GoldenGate requires a connection to theASM

instance to be able to read the logs.

6.3.1 Accessing the transaction logs in ASM

Extract must be configured to read logs that are stored in ASM. Dependingon the

ASM version, the following options are available:

6.3.1.1 Optimal ASM connection from thedatabase server

Use the TRANLOGOPTIONS parameter with the DBLOGREADER option in the Extract

parameter file if the ASM instance is one of the following versions:

■ Oracle 10.2.0.5 or later 10g R2 versions

■ Oracle 11.2.0.2 or later 11g R2 versions

A newer ASM API is available in those releases (but not in Oracle 11g R1versions)

that uses the database server to access the redo and archive logs. Whenused, this API

enables Extract to use a read buffer size of up to 4 MB in size. A largerbuffer may

improve the performance of Extract when redo rate is high. You can use the

DBLOGREADERBUFSIZEoption of TRANLOGOPTIONS to specify a buffer size.

6.3.1.2 ASM direct connection

If the ASM version is not one of those listed in Section 6.3.1.1, do the following:

1. Create a user for the Extractprocess to access the ASM instance directly. Assign

this user SYS or SYSDBA privileges in the ASM instance.Oracle GoldenGate does

not support using operating-system authentication for the ASM user. See

Table 6–2 for additional details.

Table 6–1 Oracle GoldenGate parameters forOracle RAC

Parameter Description

THREADOPTIONSparameter withthe

INQUEUESIZEand OUTQUEUESIZE

options

Sets the amount of data that Extract queues in memory before sending it to

the target system. Tuning these parameters might increase Extract

performance on Oracle RAC.

TRANLOGOPTIONSparameter withthe

PURGEORPHANEDTRANSACTIONS|

NOPURGEORPHANEDTRANSACTIONSand

TRANSCLEANUPFREQUENCYoptions

Controls how Extract handles orphaned transactions, which can occur

when a node fails during a transaction and Extract cannot capture the

rollback. Although the database performs the rollback on the failover

node, the transaction would otherwise remain in the Extract transaction

list indefinitely and prevent further checkpointing for the Extract thread

that was processing the transaction. By default, Oracle GoldenGate purges

these transactions from its list after they are confirmed as orphaned.This

functionality can also be controlled on demand with the SEND EXTRACT

command in GGSCI.

Ensuring data availability

6-8 Oracle GoldenGate for Oracle Installation and Setup Guide

2. Specify the ASM user with the TRANLOGOPTIONS parameter with the ASMUSER

option.

For syntax, additional information, and related parameters, see TRANLOGOPTIONS in the

Oracle GoldenGate Windows and UNIX Reference Guide.

6.3.2 Ensuring ASM connectivity

To ensure that the Oracle GoldenGate Extract process can connect to an ASMinstance,

list the ASM instance in the tnsnames.ora file. The recommended method for

connecting to an ASM instance when Oracle GoldenGate is running on thedatabase

host machine is to use a bequeath (BEQ) protocol. The BEQ protocol doesnot require a

listener. If you prefer to use the TCP/IP protocol, verify that the Oraclelistener is

listening for new connections to the ASM instance. The listener.ora file must contain

an entry similar to the following.

SID_LIST_LISTENER_ASM=

(SID_LIST=

(SID_DESC=

(GLOBAL_DBNAME= ASM)

(ORACLE_HOME= /u01/app/grid)

(SID_NAME= +ASM1)

)

)

6.4 Ensuring data availability

To ensure the continuity and integrity of capture processing when Extractoperates in

classic capture mode, enable archive logging. The archive logs provide asecondary

data source should the online logs recycle before Extract is finished withthem. The

archive logs for open transactions must be retained on the system in caseExtract needs

to recapture data from them to perform a recovery.

Table 6–2 Extract database privileges — ASMinstance

ASM password configuration1

1 To view how thecurrent ASM password file is configured, log on to the ASM instance and issuethe

following command in SQL*Plus:

SQL>SELECT name, value FROM v$parameter

WHEREname = 'remote_login_passwordfile';

Permitted user

ASM instance and the database share a

password file

You can use the Oracle GoldenGate source

database user if you grant that user SYSDBA, or

you can use any other database user that has

SYSDBA privileges.

ASM instance and the source database have

separate password files

You can overwrite the ASM password file

with the source database password file,

understanding that this procedure changes the

SYS password in the ASM instance to the

value that is contained in the database

password file, and it also grants ASM access to

the other users in the database password file.

Save a copy of the ASM file before overwriting

it.

Note: A BEQ connection does not work whenusing a remote Extract

configuration. Use TNSNAMES with the TCP/IPprotocol.

Ensuring data availability

Additionalconfiguration steps when using classic capture 6-9

In a RAC configuration, Extract must have access to the online andarchived logs for

all nodes in the cluster, including the one where Oracle GoldenGate isinstalled.

6.4.1 Log retention requirements per Extractrecovery mode

The following summarizes the different recovery modes that Extract mightuse and

their log-retention requirements:

■ By default, the Bounded Recovery mode is in effect, andExtract requires access to

the logs only as far back as twice the Bounded Recovery interval that isset with

the BR parameter. This interval is anintegral multiple of the standard Extract

checkpoint interval, as controlled by the CHECKPOINTSECS parameter. These two

parameters control the Oracle GoldenGate Bounded Recovery feature, which

ensures that Extract can recover in-memory captured data after a failure,no

matter how old the oldest open transaction was at the time of failure. Formore

information about this requirement, see the BR parameter documentation in the

Oracle GoldenGate Windows and UNIX Reference Guide.

■ In the unlikely event that the Bounded Recovery mechanismfails when Extract

attempts a recovery, Extract reverts to normal recovery mode and must have

access to the archived log that contains the beginning of the oldest open

transaction in memory at the time of failure and all logs thereafter.

6.4.2 Log retention options

Depending on the version of Oracle, there are different options forensuring that the

required logs are retained on the system.

6.4.2.1 Oracle Enterprise Edition 10.2 andlater

For these versions, Extract can be configured to work with Oracle RecoveryManager

(RMAN) to retain the logs that Extract needs for recovery. You enable thisfeature

when you issue the REGISTER EXTRACT command before creating your Extract

processes (see "Configuring Extract for change capture" on page 4-10).

To use this feature, the Extract database user must have the followingprivileges, in

addition to the basic privileges listed in "Assigning a database userfor Oracle

GoldenGate" on page 4-6.

WARNING: If you cannot enable archivelogging, there is a high

risk that you will need to completelyresynchronize the source and

target objects and reinstantiate replicationshould there be a failure

that causes an Extract outage whiletransactions are still active. If

you must operate this way, configure theonline logs according to

the following guidelines to retain enoughdata for Extract to capture

what it needs before the online logs recycle.Allow for Extract

backlogs caused by network outages and otherexternal factors, as

well as long-running transactions.

Ensuring data availability

6-10 Oracle GoldenGate for Oracle Installation and Setup Guide

When log retention is enabled, Extract retains enough logs to perform aBounded

Recovery, but you can configure Extract to retain enough logs through RMANfor a

normal recovery by using the TRANLOGOPTIONS parameter with the LOGRETENTION

option set to SR. There also is an option to disablethe use of RMAN log retention.

Review the options of LOGRETENTION in the Oracle GoldenGate Windows and UNIX

Reference Guide before you configure Extract. If youset LOGRETENTION to DISABLED, see

"Determining how much data to retain" on page 6-11.

The RMAN log retention feature creates an underlying (but non-functioning)Oracle

Streams Capture process for each Extract group. The name of the Capture isbased on

the name of the associated Extract group. The log retention feature canoperate

concurrently with other local Oracle Streams installations. When youcreate an Extract

group, the logs are retained from the current database SCN.

To have even more integration of Oracle GoldenGate capture with the Oracledatabase

engine, you can use integrated capture if the source database is Oracle11.2.0.3 or later.

In integrated capture mode, log retention is enabled automatically, andExtract

receives data changes directly from a database logmining server instead ofreading the

redo logs directly. See "About integrated capture" on page 4-4.

Table 6–3 Extract database privileges —Logretention in Oracle EE 10.2 and later

Oracle EE version Privileges

10.2 1. Run package to grant Oracle Streamsadmin privilege.

execdbms_streams_auth.grant_admin_privilege('user')

2. Grant INSERT into logmnr_restart_ckpt$.

grantinsert on system.logmnr_restart_ckpt$ to user;

3. Grant UPDATE on streams$_capture_process.

grantupdate on sys.streams$_capture_process to user;

4. Grant the 'become user' privilege.

grantbecome user to user;

11.1 and 11.2.0.1 1. Run package to grant Oracle Streamsadmin privilege.

execdbms_streams_auth.grant_admin_privilege('user')

2. Grant the 'become user' privilege.

grantbecome user to user;

11.2.0.3 and later Run package to grant Oracle Streams admin privilege.

execdbms_goldengate_auth.grant_admin_privilege('user')

Note: To support RMAN log retention onOracle RAC, you must

download and install the database patch that is provided in BUGFIX

11879974 before you add the Extract groups.

Note: If the Oracle Flashback storage areais full, RMAN purges the

archive logs even when needed by Extract. This limitation exists so

that the requirements of Extract (and other Oracle replication

components) do not interfere with the availability of redo to the

database.

Ensuring data availability

Additionalconfiguration steps when using classic capture 6-11

6.4.2.2 All other Oracle versions

For versions of Oracle other than Enterprise Edition 10.2 and later, youmust manage

the log retention process with your preferred administrative tools. Followthe

directions in "Determining how much data to retain" on page 6-11.

6.4.3 Determining how much data to retain

When managing log retention, try to ensure rapid access to the logs thatExtract would

require to perform a normal recovery (not a Bounded Recovery). See "Log retention

requirements per Extract recovery mode" on page 6-9. If you must move thearchives

off the database system, the TRANLOGOPTIONS parameter provides a way to specify an

alternate location. See "Specifying the archive location" on page 6-11.

The recommended retention period is at least 24 hours worth of transactiondata,

including both online and archived logs. To determine the oldest log thatExtract

might need at any given point, issue the SEND EXTRACT command with the SHOWTRANS

option. You might need to do some testing to determine the best retentiontime given

your data volume and business requirements.

If data that Extract needs during processing was not retained, either inonline or

archived logs, one of the following corrective actions might be required:

■ Alter Extract to capture from a later point in time forwhich log data is available

(and accept possible data loss on the target).

■ Resynchronize the source and target data, and then startthe Oracle GoldenGate

environment over again.

6.4.4 Purging log archives

Make certain not to use backup or archive options that cause old archivefiles to be

overwritten by new backups. Ideally, new backups should be separate fileswith

different names from older ones. This ensures that if Extract looks for aparticular log,

it will still exist, and it also ensures that the data is available incase it is needed for a

support case.

6.4.5 Specifying the archive location

If the archived logs reside somewhere other than the Oracle defaultdirectory, specify

that directory with the ALTARCHIVELOGDEST option of the TRANLOGOPTIONS parameter in

the Extract parameter file.

You might also need to use the ALTARCHIVEDLOGFORMAT option of TRANLOGOPTIONS if

the format that is specified with the Oracle parameter LOG_ARCHIVE_FORMAT contains

sub-directories. ALTARCHIVEDLOGFORMAT specifies an alternate format that removes the

sub-directory from the path. For example, %T/log_%t_%s_%r.arc would be changed to

log_%t_%s_%r.arc. As an alternative to using ALTARCHIVEDLOGFORMAT, you can create

the sub-directory manually, and then move the log files to it.

6.4.6 Mounting logs that are stored on otherplatforms

If the online and archived redo logs are stored on a different platformfrom the one

that Extract is built for, do the following:

■ NFS-mount the archive files.

■ Map the file structure to the structure of the sourcesystem by using the LOGSOURCE

and PATHMAP options of the Extract parameter TRANLOGOPTIONS. For more

information, see the Oracle GoldenGate Windows and UNIX ReferenceGuide.

Configuring Oracle GoldenGate to read only the archivedlogs

6-12 Oracle GoldenGate for Oracle Installation and Setup Guide

6.5 Configuring Oracle GoldenGate to readonly the archived logs

You can configure Extract to read exclusively from the archived logs. Thisis known as

Archived Log Only (ALO) mode. In this mode, Extractreads exclusively from archived

logs that are stored in a specified location. ALO mode enables Extract touse

production logs that are shipped to a secondary database (such as astandby) as the

data source. The online logs are not used at all. Oracle GoldenGateconnects to the

secondary database to get metadata and other required data as needed. Asan

alternative, ALO mode is supported on the production system.

6.5.1 Limitations and requirements of ALOmode

Observe the following guidelines when using Extract in ALO mode.

■ Log resets (RESETLOG) cannot bedone on the source database after the standby

database is created.

■ ALO cannot be used on a standby database if theproduction system is Oracle

RAC and the standby database is non-RAC. In addition to both systems being

Oracle RAC, the number of nodes on each system must be identical.

■ ALO on Oracle RAC requires a dedicated connection to thesource server. If that

connection is lost, Oracle GoldenGate processing will stop.

■ On Oracle RAC, the directories that contain the archivelogs must have unique

names across all nodes; otherwise, Extract may return “out of order SCN”errors.

■ ALO mode does not support archive log files in ASM mode.The archive log files

must be outside the ASM environment for Extract to read them.

■ The LOGRETENTION parameter defaults to DISABLED when Extract isin ALO mode.

You can override this with a specific LOGRETENTION setting, if needed.

6.5.2 Configuring Extract for ALO mode

To configure Extract for ALO mode, follow these steps as part of theoverall process

for configuring Oracle GoldenGate, as documented in "Configuring Oracle

GoldenGate on Oracle source and target databases" on page 4-1.

1. Enable supplemental logging at thetable level and the database level for the tables

in the source database. (See "Configuring logging properties" on page 5-4.)

2. When Oracle GoldenGate is running ona different server from the source

database, make certain that SQL*Net is configured properly to connect to aremote

server, such as providing the correct entries in a TNSNAMES file. Extract must have

permission to maintain a SQL*Net connection to the source database.

3. Use a SQL*Net connect string in thefollowing:

■ The USERID parameter inthe parameter file of every Oracle GoldenGate

process that connects to that database.

■ The DBLOGIN command inGGSCI.

Example USERID statement:

USERIDggext@ora01, PASSWORD ggs123

Note: ALO mode is not compatible withExtract operating in

integrated capture mode.

Avoiding log-read bottlenecks

Additionalconfiguration steps when using classic capture 6-13

4. Use the Extract parameter TRANLOGOPTIONS with the ARCHIVEDLOGONLY option. This

option forces Extract to operate in ALO mode against a primary or logicalstandby

database, as determined by a value of PRIMARY or LOGICAL STANDBY in the db_role

column of the v$databaseview. Thedefault is to read the online logs.

TRANLOGOPTIONSwith ARCHIVEDLOGONLY is not needed if using ALO modeagainst a

physical standby database, as determined by a value of PHYSICAL STANDBY in the

db_role column of v$database. Extract automatically operates inALO mode if it

detects that the database is a physical standby.

5. Other TRANLOGOPTIONS options might be required for yourenvironment. For

example, depending on the copy program that you use, you might need to usethe

COMPLETEARCHIVEDLOGONLYoption toprevent Extract errors.

6. Use the MAP parameter for Extract to map the table names to thesource object IDs.

For more information, see the Oracle GoldenGate Windowsand UNIX Reference

Guide.

7. Add the Extract group by issuing theADD EXTRACT command with a timestamp as

the BEGIN option, or by using ADD EXTRACT with the SEQNO and RBA options. It is

best to give Extract a known start point at which to begin extractingdata, rather

than by using the NOW argument. Thestart time of NOW corresponds to the time of

the current online redo log, but an ALO Extract cannot read the online logs,so it

must wait for that log to be archived when Oracle switches logs. Thetiming of the

switch depends on the size of the redo logs and the volume of databaseactivity, so

there might be a lag between when you start Extract and when data startsbeing

captured. This can happen in both regular and RAC database configurations.

6.6 Avoiding log-read bottlenecks

When Oracle GoldenGate captures data from the redo logs, I/O bottleneckscan occur

because Extract is reading the same files that are being written by thedatabase logging

mechanism. Performance degradation increases with the number of Extractprocesses

that read the same logs. You can:

■ Try using faster drives and a faster controller. BothExtract and the database

logging mechanism will be faster on a faster I/O system.

■ Store the logs on RAID 0+1. Avoid RAID 5, which performschecksums on every

block written and is not a good choice for high levels of continuous I/O.For more

information, see the Oracle documentation or search related web sites.

Note: If you have a standby server that islocal to the server that

Oracle GoldenGate is running on, you do not need to use a connect

string in USERID. You can just supply the user loginname.

Avoiding log-read bottlenecks

6-14 Oracle GoldenGate for Oracle Installation and Setup Guide

7

Configuring DDLsynchronization for an Oracle database 7-1

7ConfiguringDDL synchronization for an

Oracle database

This chapter contains information to help you understand and configure DDLsupport

in Oracle GoldenGate.

7.1 Overview of DDL synchronization

Oracle GoldenGate supports the synchronization of DDL operations from one

database to another. DDL synchronization can be active when:

■ business applications are actively accessing and updatingthe source and target

objects.

■ Oracle GoldenGate transactional data synchronization isactive.

The components that support the replication of DDL and the replication of

transactional data changes (DML) are independent of each other. Therefore,you can

synchronize:

■ just DDL changes

■ just DML changes

■ both DDL and DML

For a list of supported objects and operations for DDL support for Oracle,see the

Oracle GoldenGate Oracle Installation and Setup Guide.

7.2 Limitations of Oracle GoldenGate DDLsupport

This topic contains some limitations of the DDL feature. For anyadditional limitations

that were found after this documentation was published, see the OracleGoldenGate

release notes or the readme file that comes with the software.

7.2.1 DDL statement length

Oracle GoldenGate measures the length of a DDL statement in bytes, not incharacters.

The supported length is approximately 2 MB, allowing for some internaloverhead that

can vary in size depending on the name of the affected object and its DDLtype, among

other characteristics. If the DDL is longer than the supported size,Extract will issue a

warning and ignore the DDL operation.

The ignored DDL is saved in the marker table. You can capture Oracle DDL

statements that are ignored, as well as any other Oracle DDL statement, byusing the

Limitations of Oracle GoldenGate DDL support

7-2 Oracle GoldenGate for Oracle Installation and Setup Guide

ddl_ddl2file.sqlscript, whichsaves the DDL operation to a text file in the USER_

DUMP_DESTdirectory ofOracle. The script prompts for the following input:

■ The name of the schema that contains the OracleGoldenGate DDL objects, which

is specified in the GLOBALS file.

■ The Oracle GoldenGate marker sequence number, which isrecorded in the Extract

report file when DDLOPTIONS with the REPORT option is used in the Extract

parameter file.

■ A name for the output file.

7.2.2 Supported topologies

Oracle GoldenGate supports DDL synchronization only in a like-to-likeconfiguration.

The source and target object definitions must be identical.

Oracle GoldenGate does not support DDL on a standby database.

Oracle GoldenGate supports DDL replication in all supporteduni-directional

configurations, and in bi-directional configurations between two, and onlytwo,

systems. For special considerations in an Oracle active-activeconfiguration, see

"Propagating DDL in an active-active (bi-directional)configurations" on page 7-26.

7.2.3 Filtering, mapping, and transformation

DDL operations cannot be transformed by any Oracle GoldenGate process.However,

source DDL can be mapped and filtered to a different target object by aprimary

Extract or a Replicat process. Mapping or filtering of DDL by a data-pumpExtract is

not permitted, and the DDL is passed as it was received from the primaryExtract. This

is known as PASSTHRUmode.

For example, ALTERTABLE TableA is processed bya data pump as ALTERTABLE

TableA. It cannot be mapped by thatprocess as ALTER TABLETableB, regardless ofany

TABLE statements that specify otherwise.

7.2.4 Renames

RENAME operations on tables are convertedto the equivalent ALTERTABLE RENAME. For

example RENAME tab1 TOtab2 would bechanged to ALTER TABLE tab1RENAME TO

tab2. The reason for this conversion isthat RENAME does not support the use of a

schema name, but ALTER TABLE RENAME does. Oracle GoldenGate makes the

conversion so that a schema name can be included in the target DDLstatement. The

conversion is reported in the Replicat process report file.

RENAME operations on sequences and viewscannot be converted to an ALTER statement,

because there is no such statement in Oracle for sequences and views.Consequently,

sequence renames are always replicated on the target with the same ownerand object

name as in the source DDL and cannot be mapped to something different.

7.2.5 Interactions between fetches from atable and DDL

Oracle GoldenGate supports some data types by identifying the modified rowfrom

the redo stream and then querying the underlying table to fetch thechanged columns.

For instance, in classic capture, partial updates on LOBs (modificationsdone via dbms_

lobpackage) are supportedby identifying the modified row and the LOB column

from the redo log, and then querying for the LOB column value for the rowfrom the

base table. A similar technique is employed to support User Defined Types(both in

classic and integrated capture).

Limitations of Oracle GoldenGate DDL support

Configuring DDLsynchronization for an Oracle database 7-3

Such fetch-based support is implemented by issuing a flashback query tothe database

based on the SCN (System Change Number) at which the transactioncommitted. The

flashback query feature has certain limitations. Certain DDL operationsact as barriers

such that flashback queries to get data prior to these DDLs do notsucceed. Examples

of such DDL are "ALTER TABLE MODIFY COLUMN" and "ALTER TABLE DROP COLUMN".

Thus, in cases where there is Extract capture lag, an intervening DDL maycause fetch

requests for data prior to the DDL to fail. In such cases, Extract fallsback and fetches

the current snapshot of the data for the modified column. There are twolimitations to

this approach: First, the DDL could have modified the column that Extractneeds to

fetch (for example, suppose the intervening DDL added a new attribute tothe UDT

that is being captured). Second, the DDL could have modified one of thecolumns that

Extract uses as a logical row identifier.

To prevent fetch-related inconsistencies such as these, take the followingprecautions

while modifying columns.

1. Pause all DML to the table.

2. Wait for Extract to finish capturingall remaining redo, and wait for Replicat to

finish processing the captured data from trail. To determine whetherReplicat is

finished, issue the following command in GGSCI until you see a messagethat

there is no more data to process.

INFOREPLICAT group

3. Execute the DDL on the source.

4. Resume source DML operations.

7.2.6 Comments in SQL

If a source DDL statement contains a comment in the middle of an objectname, that

comment will appear at the end of the object name in the target DDLstatement. For

example:

Source:

CREATETABLE hr./*comment*/emp ...

Target:

CREATETABLE hr.emp /*comment*/ ...

This does not affect the integrity of DDL synchronization. Comments in anyother area

of a DDL statement remain in place when replicated.

7.2.7 Compilation errors

If a CREATE operation on a trigger, procedure,function, or package results in

compilation errors, Oracle GoldenGate executes the DDL operation on thetarget

anyway. Technically, the DDL operations themselves completed successfullyand

should be propogated to allow dependencies to be executed on the target,for example

in recursive procedures.

7.2.8 Interval partitioning

DDL replication is unaffected by interval partitioning, because the DDL isimplicit.

Configuration guidelines for DDL support

7-4 Oracle GoldenGate for Oracle Installation and Setup Guide

7.3 Configuration guidelines for DDL support

The following are guidelines to take into account when configuring Oracle

GoldenGate processes to support DDL replication.

7.3.1 Database privileges

See "Assigninga database user for Oracle GoldenGate" on page 4-6 for database

privileges that are required for Oracle GoldenGate to support DDL captureand

replication.

7.3.2 Parallel processing

If using parallel Extract and/or Replicat processes, keep related DDL andDML

together in the same process stream to ensure data integrity. Configurethe processes

so that:

■ all DDL and DML for any given object are processed by thesame Extract group

and by the same Replicat group.

■ all objects that are relational to one another areprocessed by the same process

group.

For example, if ReplicatA processes DML for Table1, then itshould also process the

DDL for Table1. If Table2 has a foreign key to Table1, then its DML and DDL

operations also should be processed by ReplicatA.

If an Extract group writes to multiple trails that are read by differentReplicat groups,

Extract sends all of the DDL to all of the trails. Use each Replicat groupto filter the

DDL by using the filter options of the DDL parameter in the Replicat parameter file.

7.3.3 DDL and DML in data pumps

If using a data pump, configure DML for PASSTHRU mode if the objects are using DDL

support. DDL is passed through a data pump in PASSTHRU mode, so the same must be

true of the DML. Any filtering, mapping, or transformation of the DML mustbe done

by the primary Extract or by Replicat. However, tables that do not use DDLsupport

can be configured in NOPASSTHRU mode to allow data filtering, and manipulation by a

data pump.

To configure tables for PASSTHRU, NOPASSTHRU, or both, do the following:

1. In the parameter file of the datapump, place the PASSTHRUparameterbefore all of

the TABLE statements that contain tables thatuse DDL support.

2. In the same parameter file, you canplace the NOPASSTHRU parameter before any

TABLE statements that contain tables thatdo not use DDL support, if you want

data filtering, mapping, or transformation to be performed for them.

3. Do not use any of the DDL configurationparameters for a data pump: DDL,

DDLOPTIONS, DDLSUBST, PURGEDDLHISTORY, PURGEMARKERHISTORY, DDLERROR, or any

of the Oracle GoldenGate tracing parameters with DDL-related options.

For more information about PASSTHRU and NOPASSTHRU, see the Oracle GoldenGate

Windows and UNIX Reference Guide.

7.3.4 Object names

Oracle GoldenGate preserves the database-defined object name, case, andcharacter

set. This support preserves single-byte and multibyte names, symbols, andaccent

Configuration guidelines for DDL support

Configuring DDLsynchronization for an Oracle database 7-5

characters at all levels of the database hierarchy. For more informationabout support

for object names, see the Oracle GoldenGate Windows and UNIXAdministrator's Guide.

You can use the question mark (?) and asterisk (*) wildcards to specify object namesin

configuration parameters that support DDL synchronization. For moreinformation

about support for wildcards, see the Oracle GoldenGate Windowsand UNIX

Administrator's Guide. To process wildcards correctly,the WILDCARDRESOLVE parameter

is set to DYNAMIC by default. If WILDCARDRESOLVE is set to anything else, the Oracle

GoldenGate process that is processing DDL operations will abend and writethe error

to the process report.

7.3.5 Data definitions

Because DDL support requires a like-to-like configuration, the ASSUMETARGETDEFS

parameter must be used in the Replicat parameter file. Replicat will abendif objects

are configured for DDL support and the SOURCEDEFS parameter is being used. For

more information about ASSUMETARGETDEFS, see the Oracle GoldenGate Windows and

UNIX Reference Guide.

7.3.6 Truncates

TRUNCATEstatements canbe supported as follows:

■ As part of the Oracle GoldenGate full DDL support, whichsupports TRUNCATE

TABLE, ALTER TABLE TRUNCATE PARTITION, and other DDL. This is controlledby

the DDL parameter (see "Enabling DDL support" on page 7-9.)

■ As standalone TRUNCATE support. Thissupport enables you to replicate TRUNCATE

TABLE, but no other DDL. The GETTRUNCATES parameter controls the standalone

TRUNCATEfeature. Formore information, see the Oracle GoldenGate Windows and

UNIX Reference Guide.

To avoid errors from duplicate operations, only one of these features canbe active at

the same time.

7.3.7 Initial synchronization

To configure DDL replication, start with a target database that issynchronized with

the source database. DDL support is compatible with the Replicat initialload method.

Before executing an initial load, disable DDL extraction and replication.DDL

processing is controlled by the DDL parameter in the Extract and Replicatparameter

files.

After initial synchronization of the source and target data, use all ofthe source

sequence values at least once with NEXTVAL before you run the sourceapplications.

You can use a script that selects NEXTVAL from every sequence in the system.This must

be done while Extract is running.

7.3.8 Data continuity after CREATE or RENAME

To replicate DML operations on new Oracle tables resulting from a CREATE or RENAME

operation, the names of the new tables must be specified in TABLE and MAP statements

in the parameter files. You can use wildcards to make certain that theyare included.

To create a new user with CREATE USER and then move new or renamed tables into

that schema, the new user name must be specified in TABLE and MAP statements. To

create a new user fin2 and move new orrenamed tables into that schema, the

Understanding DDL scopes

7-6 Oracle GoldenGate for Oracle Installation and Setup Guide

parameter statements could look as follows, depending on whether you wantthe fin2

objects mapped to the same, or different, schema on the target:

Extract:

TABLEfin2.*;

Replicat:

MAPfin2*, TARGET different_schema.*;

7.4 Understanding DDL scopes

Database objects are classified into scopes. A scope is a category thatdefines how DDL

operations on an object are handled by Oracle GoldenGate. The scopes are:

■ MAPPED

■ UNMAPPED

■ OTHER

The use of scopes enables granular control over the filtering of DDLoperations, string

substitutions, and error handling.

7.4.1 Mapped scope

Objects that are specified in TABLE and MAP statements are of MAPPED scope. Extraction

and replication instructions in those statements apply to both data (DML)and DDL on

the specified objects, unless override rules are applied.

For objects in TABLE and MAP statements, the DDL operations listed in the following

table are supported.

Table 7–1 Objects that can be mapped in MAPand TABLE statements

Operations On any of these Objects1

CREATE

ALTER

DROP

RENAME

COMMENTON2

TABLE3

INDEX

TRIGGER

SEQUENCE

MATERIALIZEDVIEW

VIEW

FUNCTION

PACKAGE

PROCEDURE

SYNONYM

PUBLICSYNONYM4

GRANT

REVOKE

TABLE

SEQUENCE

MATERIALIZEDVIEW

ANALYZETABLE

INDEX

CLUSTER

Understanding DDL scopes

Configuring DDLsynchronization for an Oracle database 7-7

For Extract, MAPPED scope marks an object for DDLcapture according to the

instructions in the TABLE statement. ForReplicat, MAPPED scope marks DDL for

replication and maps it to the object specified by the schema and name inthe TARGET

clause of the MAP statement. To perform this mapping,Replicat issues ALTERSESSION

to set the schema of the Replicat session to the schema that is specifiedin the TARGET

clause. If the DDL contains unqualified objects, the schema that isassigned on the

target depends on circumstances described in "Correctly identifyingunqualified object

names in DDL" on page 7-9.

Assume the following TABLE and MAP statements:

Extract (source)

TABLEfin.expen;

TABLEhr.tab*;

Replicat (target)

MAPfin.expen, TARGET fin2.expen2;

MAPhr.tab*, TARGET hrBackup.bak_*;

Also assume a source DDL statement of:

ALTERTABLE fin.expen ADD notes varchar2(100);

In this example, because the source table fin.expen is in a MAP statement with a

TARGET clause that maps to a differentowner and table name, the target DDL

statement becomes:

ALTERTABLE fin2.expen2 ADD notes varchar2(100);

Likewise, the following source and target DDL statements are possible forthe second

set of TABLE and MAP statements in the example:

Source:

CREATETABLE hr.tabPayables ... ;

Target:

CREATETABLE hrBackup.bak_tabPayables ...;

When objects are of MAPPED scope, you canomit their names from the DDL

configuration parameters, unless you want to refine their DDL supportfurther. If you

ever need to change the object names in TABLE and MAP statements, the changes will

apply automatically to the DDL on those objects.

If you include an object in a TABLE statement, butnot in a MAP statement, the DDL for

that object is MAPPED in scope on the source but UNMAPPED in scope on the target.

7.4.1.1 Mapping Oracle cluster tables andUDTs

An Oracle clustered table or Oracle user defined type (UDT) cannot bemapped to a

different target name, but it can be mapped to a different target owner.Because these

1 TABLE and MAP do not support some special characters that could be usedin an object name affected by

these operations. Objects with non-supported special characters aresupported by the scopes of UNMAPPED

and OTHER.

2 Applies to COMMENT ON TABLE, COMMENT ON COLUMN

3 Includes AS SELECT

4 Table name mustbe qualified with schema name.

Understanding DDL scopes

7-8 Oracle GoldenGate for Oracle Installation and Setup Guide

special kinds of objects can consist of underlying tables that,themselves, could be a

mix of both MAPPED and UNMAPPED scope, name mapping cannot be used.

7.4.1.2 Mapping ALTER INDEX

An ALTERINDEX...RENAME command cannot be mapped to a different target index

name, but it can be mapped to a different target owner.

Valid example:

ALTERINDEX src.ind RENAME TO indnew;

This DDL can be mapped with wildcards as:

MAPsrc.* TARGET tgt.*;

Alternatively, it can be mapped explicitly as the following, making sureto use the

original index name in the source and target specifications:

MAPsrc.ind TARGET tgt.ind;

In either of the preceding cases, the target DDL will be:

ALTERINDEX tgt.ind RENAME TO indnew;

Invalid example:

A MAP statement such as the following isnot valid:

MAPsrc.ind TARGET tgt.indnew;

That statement maps the old name to the new name, and the target DDL willbecome:

ALTERINDEX tgt.indnew RENAME TO indnew;

7.4.2 Unmapped scope

If a DDL operation is supported for use in a TABLE or MAP statement, but its base object

name is not included in one of those parameters, it is of UNMAPPED scope.

An object name can be of UNMAPPED scope on thesource (not in an Extract TABLE

statement), but of MAPPED scope on thetarget (in a Replicat MAP statement), orthe other

way around. When Oracle DDL is of UNMAPPED scope in the Replicat configuration,

Replicat will by default do the following:

1. Set the current owner of theReplicat session to the owner of the source DDL

object.

2. Execute the DDL as that owner.

3. Restore Replicat as the currentowner of the Replicat session.

See also "Correctlyidentifying unqualified object names in DDL" on page 7-9.

7.4.3 Other scope

DDL operations that cannot be mapped are of OTHER scope. When DDL is of OTHER

scope in the Replicat configuration, it is applied to the target with thesame owner and

object name as in the source DDL.

An example of OTHER scope is a DDL operation that makesa system-specific reference,

such as DDL that operates on data file names.

Some other examples of OTHER scope:

Enabling DDL support

Configuring DDLsynchronization for an Oracle database 7-9

CREATEUSER joe IDENTIFIED by joe;

CREATEROLE ggs_gguser_role IDENTIFIED GLOBALLY;

ALTERTABLESPACE gg_user TABLESPACE GROUP gg_grp_user;

See also “Correctly identifying unqualified object names in DDL” on page9.

7.5 Correctly identifying unqualified objectnames in DDL

Extract captures the current schema (also called session schema) that isin effect when

a DDL operation is executed. This schema is used to resolve unqualifiedobject names

in the DDL.

Consider the following example:

CONNECTSCOTT/TIGER

CREATETABLE TAB1 (X NUMBER);

CREATETABLE SRC1.TAB2(X NUMBER) AS SELECT * FROM TAB1;

In both of those DDL statements, the unqualified table TAB1 is resolved as SCOTT.TAB1

based on the current schema SCOTT that is ineffect during the DDL execution.

There is another way of setting the current schema, which is to set the current_schema

for the session, as in the following example:

CONNECTSCOTT/TIGER

ALTERSESSION SET CURRENT_SCHEMA=SRC;

CREATETABLE TAB1 (X NUMBER);

CREATETABLE SRC1.TAB2(X NUMBER) AS SELECT * FROM TAB1;

In both of those DDL statements, the unqualified table TAB1 is resolved as SRC.TAB1

based on the current schema SRC that is ineffect during the DDL execution.

In both classic and integrated capture modes, Extract captures the currentschema that

is in effect during DDL execution, and it resolves the unqualified objectnames (if any)

by using the current schema. As a result, MAP statements specified for Replicat work

correctly for DDL with unqualified object names.

You can also map a source session schema to a different target sessionschema. Session

schema mapping is required for some DDL to succeed on the target in thepresence of

mapping, such as CREATE TABLE AS SELECT and in CREATE TABLE operations with the

REFERENCESclause. This mappingis global and overrides any other mappings that

involve the same schema names. To map session schemas, use the DDLOPTIONS

parameter with the MAPSESSIONSCHEMA option. For more information, see the Oracle

GoldenGate Windows and UNIX Reference Guide.

You can prevent explicit schema mapping with the NOEXPLICITSCHEMAMAPPING option

of the DDLOPTIONS parameter. See the DDLOPTIONS parameter documentation in the

Windows and UNIX Reference Guide.

7.6 Enabling DDL support

By default, the status of DDL replication support is as follows:

■ On the source, Oracle GoldenGate DDL support is disabledby default. You must

configure Extract to capture DDL by using the DDL parameter.

■ On the target, DDL support is enabled by default, tomaintain the integrity of

transactional data that is replicated. By default, Replicat will processall DDL

operations that the trail contains. If needed, you can use the DDL parameter to

configure Replicat to ignore or filter DDL operations.

Filtering DDL replication

7-10 Oracle GoldenGate for Oracle Installation and Setup Guide

7.7 Filtering DDL replication

For Oracle databases, you can use the following methods to filter DDLoperations so

that specific (or all) DDL is applied to the target database according toyour

requirements. By default, all DDL is passed to Extract by the DDL trigger.

■ Filter with PL/SQL code. This method makes use of an Oraclefunction that is called

by the DDL trigger when a DDL operation occurs, to compute whether or notto

send the DDL to Extract.

■ Filter with built-infilter rules: This method makes use of some procedures that you

run to build filter rules into the Oracle GoldenGate trigger logic. Thismethod

allows discreet control over the types of objects that are sent toExtract, and it

allows the ordering of rule evaluation.

■ Filter with the DDLparameter on the source, the target, or both. This method is

performed within Oracle GoldenGate, and both Extract and Replicat canexecute

filter criteria. Extract can perform filtering, or it can send all of theDDL to a trail,

and then Replicat can perform the filtering. Alternatively, you can filterin a

combination of different locations. The DDL parameter gives you control over

where the filtering is performed, and it also offers more filteringoptions than the

trigger method, including the ability to filter collectively based on theDDL scope

(for example, include all MAPPED scope).

■ Combine PL/SQL, built-inrules, and DDL parameter filtering. Any DDL that is passed

to Extract after it is filtered by the DDL trigger or filter rules can befiltered further

with the DDL parameter to meet specific needs.

7.7.1 Filtering with PL/SQL code

You can write PL/SQL code to pass information about the DDL to a functionthat

computes whether or not the DDL is passed to Extract. By sending fewer DDL

operations to Extract, you can improve capture performance.

1. Copy the ddl_filter.sql file that is in the OracleGoldenGate installation

directory to a test machine where you can test the code that you will bewriting.

2. Open the file for editing. Itcontains a PL/SQL function named filterDDL, which

you can modify to specify if/then filtercriteria. The information that is passed to

this function includes:

■ ora_owner: the owner ofthe DDL object

■ ora_name: the definedname of the object

■ ora_objtype: the type of object, such as TABLE or INDEX

■ ora_optype: the operation type, such as CREATE or ALTER

■ ora_login_user: The user that executed the DDL

■ retVal: can be eitherINCLUDE to include the DDL, or EXCLUDE to exclude the

DDL from Extract processing.

In the location after the 'compute retVal here' comment, write filter code for

each type of DDL that you want to be filtered. The following is anexample:

ifora_owner='SYS' then

retVal:='EXCLUDE';

end if;

ifora_objtype='USER' and ora_optype ='DROP' then

retVal:='EXCLUDE';

end if;

Filtering DDL replication

Configuring DDLsynchronization for an Oracle database 7-11

ifora_owner='JOE' and ora_name like 'TEMP%' then

retVal:='EXCLUDE';

end if;

In this example, the following DDL is excluded from being processed by theDDL

trigger:

■ DDL for objects owned by SYS

■ any DROP USER

■ any DDL on JOE.TEMP%

3. (Optional) To trace the filtering,you can add the following syntax to each if/then

statement in the PL/SQL:

ifora_owner='JOE' and ora_name like 'TEMP%' then

retVal:='EXCLUDE';

if"&gg_user" .DDLReplication.trace_level >= 1 then

"&gg_user".trace_put_line ('DDLFILTER', 'excluded JOE.TEMP%');

end if;

Where:

■ &gg_user is the schema of the Oracle GoldenGate DDL support objects.

■ .DDLReplication.trace_level is the level of DDL tracing. To use trigger

tracing, the TRACE or TRACE2 parameter must be used with the DDL or DDLONLY

option in the Extract parameter file. .DDLReplication.trace_level must be

set to >=1.

■ trace_put_line is a user-defined text string that Extract writes to the trace file

that represents the type of DDL that was filtered.

4. Save the code.

5. Stop DDL activity on the testsystem.

6. In SQL*Plus, compile the ddl_filter.sql file as follows, where schema_name is

the schema where the Oracle GoldenGate DDL objects are installed.

@ddl_filterschema_name

7. Test in the test environment to makecertain that the filtering works. It is

important to perform this testing, because any errors in the code couldcause

source and target DDL to become out of synchronization.

8. After a successful test, copy thefile to the Oracle GoldenGate installation directory

on the source production system.

9. Stop DDL activity on the sourcesystem.

10. Compile the ddl_filter.sql file as you did before.

@ddl_filterschema_name

11. Resume DDL activity on the sourcesystem.

Note: See the Oracle GoldenGate OracleInstallation and Setup Guide

for information on these objects.

Filtering DDL replication

7-12 Oracle GoldenGate for Oracle Installation and Setup Guide

7.7.2 Adding and dropping filter rules

You can add inclusion and exclusion rules to control the DDL operationsthat are sent

to Extract by the DDL trigger. By storing rules and sending fewer DDLoperations to

Extract, you can improve capture performance.

1. Use the DDLAUX.addRule() function to define your rulesaccording to the following

instructions. This function is installed in the Oracle GoldenGate DDLschema after

the DDL objects are installed with the ddl_setup.sql script.

2. To activate the rules, execute thefunction in SQL*Plus or enter a collection of rules

in a SQL file and execute that file in SQL*Plus.

7.7.2.1 DDLAUX.addRule() function definition

FUNCTIONaddRule( obj_name IN VARCHAR2 DEFAULT NULL,

base_obj_nameIN VARCHAR2 DEFAULT NULL,

owner_nameIN VARCHAR2 DEFAULT NULL,

base_owner_nameIN VARCHAR2 DEFAULT NULL,

base_obj_propertyIN NUMBER DEFAULT NULL,

obj_typeIN NUMBER DEFAULT NULL,

commandIN VARCHAR2 DEFAULT NULL,

inclusionIN boolean DEFAULT NULL ,

sno INNUMBER DEFAULT NULL)

RETURNNUMBER;

7.7.2.2 Parameters for DDLAUX.addRule()

The information passed to this function are the following parameters,which correlate

to the attributes of an object. All parameters are optional, and more thanone

parameter can be specified.

■ sno: Specifies aserial number that identifies the rule. The order of evaluation of

rules is from the lowest serial number to the highest serial number, untila match

is found. The sno can be used to place inclusion rulesahead of an exclusion rule,

so as to make an exception to the exclusion rule. Because this is afunction and not

a procedure, it returns the serial number of the rule, which should beused for the

drop rule specified with DDLAUX.dropRule(). The serial number is generated

automatically unless you specify one with this statement at the beginningof your

code: DECLARE snoNUMBER; BEGIN sno :=

For example:

DECLAREsno NUMBER; BEGIN sno := tkggadmin..DDLAUX.ADDRULE(obj_name => 'GGS%' ,

obj_type=> TYPE_TABLE); END

■ obj_name: Specifies theobject name

■ owner_name: Specifies the name of the object owner

■ base_obj_name: Specifies the base object name of the DDL object (such as the base

table if the object is an index)

■ base_owner_name: Specifies the base object owner name

■ base_obj_property: Specifies the base object property. See "Valid DDL

components for DDLAUX.addRule()" on page 7-13

■ obj_type: Specifies theobject type. See "Valid DDL components for

DDLAUX.addRule()" on page 7-13

■ command: Specifies thecommand. See "ValidDDL components for

DDLAUX.addRule()" on page 7-13

Filtering DDL replication

Configuring DDLsynchronization for an Oracle database 7-13

■ inclusion = TRUE: Indicates that the specified objects are to be capturedby the

DDL trigger. If this parameter is not specified, the rule becomes anexclusion rule,

and the specified objects are not captured. You can specify both anexclusion rule

and an inclusion rule. If a DDL does not match any of the rules, it isincluded

(passed to Extract) by default. Calling DDLAUX.addRule() without any parameters

generates an empty rule that excludes all DDL on all theobjects.

7.7.2.3 Valid DDL components forDDLAUX.addRule()

The following are the defined DDL object types, base object properties,and DDL

commands that can be specified in the function code.

Valid object types are:

TYPE_INDEX

TYPE_TABLE

TYPE_VIEW

TYPE_SYNONYM

TYPE_SEQUENCE

TYPE_PROCEDURE

TYPE_FUNCTION

TYPE_PACKAGE

TYPE_TRIGGER

Valid base object properties are:

TB_IOT

TB_CLUSTER

TB_NESTED

TB_TEMP

TB_EXTERNAL

Valid commands are:

CMD_CREATE

CMD_DROP

CMD_TRUNCATE

CMD_ALTER

7.7.2.4 Examples of rule-based triggerfiltering

The following example excludes all temporary tables, except tables withnames that

start with IMPTEMP.

1.DDLAUX.ADDRULE(obj_name => 'IMPTEMP%', base_obj_property => TB_TEMP,obj_type

=>TYPE_TABLE, INCLUSION => TRUE);

2.DDLAUX.ADDRULE(base_obj_property => TB_TEMP, obj_type => TYPE_TABLE);

The following example excludes all tables with name 'GGS%'

DECLARE snoNUMBER; BEGIN sno := DDLAUX.ADDRULE(obj_name => 'GGS%' , obj_type =>

TYPE_TABLE);END

The following example excludes all temporary tables.

DDLAUX.ADDRULE(base_obj_property=> TB_TEMP, obj_type => TYPE_TABLE);

Note: Since the IMPTEMP% tables must be included, that ruleshould

come first.

Filtering DDL replication

7-14 Oracle GoldenGate for Oracle Installation and Setup Guide

The following example excludes all indexes on TEMP tables.

DDLAUX.ADDRULE(base_obj_property=> TB_TEMP, obj_type => TYPE_INDEX);

The following example excludes all objects in schema TKGGADMIN.

DDLAUX.ADDRULE(obj_owner=> 'TKGGADMIN');

The following example excludes all objects in TRUNCATE operations made to TEMP

tables.

DDLAUX.ADDRULE(base_obj_property=> TB_TEMP, obj_type => TYPE_TABLE, command =>

CMD_TRUNCATE)

7.7.2.5 Dropping filter rules

Use the DDLAUX.dropRule()function withthe drop rule. This function is installed in

the Oracle GoldenGate DDL schema after the DDL objects are installed withthe ddl_

setup.sqlscript. Asinput, specify the serial number of the rule that you want to drop.

FUNCTIONdropRule(sno IN NUMBER) RETURN BOOLEAN;

7.7.3 Filtering with the DDL parameter

The DDL parameter is the main OracleGoldenGate parameter for filtering DDL within

the Extract and Replicat processes.

When used without options, the DDL parameterperforms no filtering, and it causes all

DDL operations to be propagated as follows:

■ As an Extract parameter, it captures all supported DDLoperations that are

generated on all supported database objects and sends them to the trail.

■ As a Replicat parameter, it replicates all DDL operationsfrom the Oracle

GoldenGate trail and applies them to the target. This is the same as thedefault

behavior without this parameter.

When used with options, the DDL parameter actsas a filtering agent to include or

exclude DDL operations based on:

■ scope

■ object type

■ operation type

■ object name

■ strings in the DDL command syntax or comments, or both

Only one DDL parameter can be used in a parameterfile, but you can combine multiple

inclusion and exclusion options to filter the DDL to the required level.

■ DDL filteringoptions are valid for a primary Extract that captures from the

transaction source, but not for a data-pump Extract.

■ When combined, multiple filter option specifications arelinked logically as AND

statements.

■ All filter criteria specified with multiple options mustbe satisfied for a DDL

statement to be replicated.

■ When using complex DDL filtering criteria, it isrecommended that you test your

configuration in a test environment before using it in production.

Filtering DDL replication

Configuring DDLsynchronization for an Oracle database 7-15

Syntax:

DDL [

{INCLUDE| EXCLUDE}

[,MAPPED | UNMAPPED | OTHER | ALL]

[,OPTYPE type]

[,OBJTYPE ‘type’]

[,OBJNAME name]

[, INSTR‘string’]

[,INSTRCOMMENTS ‘comment_string’]

[,STAYMETADATA]

[,EVENTACTIONS (action specification)

]

[...]

WARNING: Do not include any OracleGoldenGate-installed DDL

objects in a DDL parameter, in a TABLE parameter,or in a MAP

parameter, nor in a TABLEEXCLUDE or MAPEXCLUDE parameter.Make

certain that wildcard specifications in thoseparameters do not

include Oracle GoldenGate-installed DDLobjects. These objects

must not be part of the Oracle GoldenGateconfiguration, but the

Extract process must be aware of operationson them, and that is

why you must not explicitly exclude them fromthe configuration

with an EXCLUDE, TABLEEXCLUDE, or MAPEXCLUDE parameterstatement.

Note: Before you create a DDL parameter statement, it might helpto

review "HowDDL is evaluated for processing" on page 7-29.

Filtering DDL replication

7-16 Oracle GoldenGate for Oracle Installation and Setup Guide

Table 7–2 DDL inclusion and exclusion options

Option Description

INCLUDE| EXCLUDE Use INCLUDE and EXCLUDE to identify the beginning of aninclusion or exclusion

clause.

■ An inclusion clause contains filtering criteria thatidentifies the DDL that this

parameter will affect.

■ An exclusion clause contains filtering criteria thatexcludes specific DDL from

this parameter.

The inclusion or exclusion clause must consist of the INCLUDE or EXCLUDE keyword

followed by any valid combination of other options of the parameter thatis being

applied.

If you use EXCLUDE, you must create a corresponding INCLUDE clause. For example, the

following is invalid:

DDLEXCLUDE OBJNAME hr.*

However, you can use either of the following:

DDLINCLUDE ALL, EXCLUDE OBJNAME hr.*

DDLINCLUDE OBJNAME fin.* EXCLUDE OBJNAME fin.ss

An EXCLUDE takes priority over any INCLUDEs that contain the same criteria. Youcan

use multiple inclusion and exclusion clauses.

MAPPED |UNMAPPED |

OTHER |ALL

Use MAPPED, UNMAPPED, OTHER, and ALL to apply INCLUDE or EXCLUDE based on the DDL

operation scope.

■ MAPPED applies INCLUDE or EXCLUDE to DDL operations that are of MAPPED scope.

MAPPED filtering is performed beforefiltering that is specified with other DDL

parameter options.

■ UNMAPPED applies INCLUDE or EXCLUDE to DDL operations that are of UNMAPPED

scope.

■ OTHER applies INCLUDE or EXCLUDE to DDL operations that are of OTHER scope.

■ ALL applies INCLUDE or EXCLUDE to DDL operations of all scopes.

OPTYPE type Use OPTYPE to apply INCLUDE or EXCLUDE to a specific type of DDL operation,such as

CREATE, ALTER, and RENAME. For type, use any DDL command that is validfor the

database. For example, to include ALTER operations, the correct syntax is:

DDLINCLUDE OPTYPE ALTER

OBJTYPE ‘type’ Use OBJTYPE to apply INCLUDE or EXCLUDE to a specific type of databaseobject. For

type, use any object type that is valid for the database,such as TABLE, INDEX, and

TRIGGER. For an Oracle materialized viewand materialized views log, the correct

types are snapshot and snapshot log, respectively. Enclose the name ofthe object

type within single quotes. For example:

DDLINCLUDE OBJTYPE ‘INDEX’

DDLINCLUDE OBJTYPE ‘SNAPSHOT’

For Oracle object type USER, do not usethe OBJNAME option, because OBJNAME expects

owner.objectwhereas USER only has a schema.

Filtering DDL replication

Configuring DDLsynchronization for an Oracle database 7-17

OBJNAME name Use OBJNAME to apply INCLUDE or EXCLUDE to the fully qualified name of anobject, for

example owner.table_name. You can use a wildcard only forthe object name.

Example:

DDLINCLUDE OBJNAME accounts.*

Do not use OBJNAME for the Oracle USER object, because OBJNAME expects

owner.object, whereas USER only has a schema.

When using OBJNAME with MAPPED in a Replicat parameter file, thevalue for OBJNAME

must refer to the name specified with the TARGET clause of the MAP statement. For

example, given the following MAP statement, thecorrect value is OBJNAMEfin2.*.

MAPfin.exp_*, TARGET fin2.*;

In the following example, a CREATE TABLE statement executes as follows on the

source:

CREATETABLE fin.exp_phone;

That same statement executes as follows on the target:

CREATETABLE fin2.exp_phone;

If a target owner is not specified in the MAP statement, Replicat maps it to the database

user that is specified with the USERID parameter.

For DDL that creates derived objects, such as a trigger, the value for OBJNAME must be

the name of the base object, not the name of the derived object.

For example, to include the following DDL statement, the correct value is

hr.accounts, not hr.insert_trig.

CREATETRIGGER hr.insert_trig ON hr.accounts;

For RENAME operations, the value for OBJNAME must be the new table name. For

example, to include the following DDL statement, the correct value is hr.acct.

ALTERTABLE hr.accounts RENAME TO acct;

INSTR ‘string’ Use INSTR to apply INCLUDE or EXCLUDE to DDL statements that contain aspecific

character string within the command syntax itself, but not withincomments. For

example, the following excludes DDL that creates an index.

DDLINCLUDE ALL EXCLUDE INSTR ‘CREATE INDEX’

Enclose the string within single quotes. The string search is not casesensitive.

INSTR does not support single quotationmarks (‘ ’) that are within the string, nor

does it support NULL values.

INSTRCOMMENTS‘comment_

string’

Use INSTRCOMMENTS to apply INCLUDE or EXCLUDE to DDL statements that contain a

specific character string within a comment, but not within the DDL commanditself.

By using INSTRCOMMENTS, you can use comments as afiltering agent.

For example, the following excludes DDL statements that include “source”in the

comments.

DDLINCLUDE ALL EXCLUDE INSTRCOMMENTS ‘SOURCE ONLY’

In this example, DDL statements such as the following are not replicated.

CREATEUSER john IDENTIFIED BY john /*source only*/;

Enclose the string within single quotes. The string search is not casesensitive. You

can combine INSTR and INSTRCOMMENTS to filter on a string in the commandsyntax of

a DDL statement, and also on the comments in that statement.

INSTRCOMMENTSdoes notsupport single quotation marks (‘ ’) that arewithin the

string, nor does it support NULL values.

Table 7–2 (Cont.) DDL inclusion and exclusionoptions

Option Description

Filtering DDL replication

7-18 Oracle GoldenGate for Oracle Installation and Setup Guide

INSTRWORDS‘wordlist’ Use INSTRWORDS to apply INCLUDE or EXCLUDE to DDL statements that contain the

specified words.

For wordlist, supply thewords in any order, within single quotes. To include

spaces, put the space (and the word, if applicable) in double quotes.Double quotes

also can be used to enclose sentences.

All specified words must be present in the DDL for INSTRWORDS to take effect.

Example:

ALTERTABLE INCLUDE INSTRWORDS ‘ALTER CONSTRAINT “ xyz”

This example will match both of the following statements:

ALTERTABLE ADD CONSTRAINT xyz CHECK

ALTERTABLE DROP CONSTRAINT xyz

INSTRWORDSdoes notsupport single quotation marks (‘ ’) that arewithin the string,

nor does it support NULL values.

Table 7–2 (Cont.) DDL inclusion and exclusionoptions

Option Description

Filtering DDL replication

Configuring DDLsynchronization for an Oracle database 7-19

INSTRCOMMENTSWORDS

‘word list’

Works the same way as INSTRWORDS, but onlyapplies to comments within a DDL

statement, not the DDL syntax itself. By using INSTRCOMMENTS, you can use comments

as a filtering agent.

INSTRCOMMENTSWORDSdoes notsupport single quotation marks (‘ ’) that are within

the string, nor does it support NULL values.

You can combine INSTRWORDSand INSTRCOMMENTSWORDS to filter on a string in the

command syntax and in the comments of the same DDL statement.

STAYMETADATAValid forExtract and Replicat. Prevents metadata from being replicated.

When Extract first encounters DML on a table, it retrieves the metadatafor that table.

When DDL is encountered on that table, the old metadata is invalidated.The next

DML on that table is matched to the new metadata so that the target tablestructure

always is up-to-date with that of the source.

However, if you know that a particular DDL operation will not affect thetable’s

metadata, you can use STAYMETADATA so that the current metadata is not retrieved or

replicated. This is a performance improvement that has benefit for suchoperations as

imports and exports, where such DDL as truncates and the disabling ofconstraints

are often performed. These operations do not affect table structure, as itrelates to the

integrity of subsequent data replication, so they can be ignored in suchcases. For

example ALTER TABLE ADDFOREIGN KEY does not affecttable metadata.

An example of how this can be applied selectively is as follows:

DDLINCLUDE ALL INCLUDE STAYMETADATA OBJNAME xyz

This example states that all DDL is to be included for replication, butonly DDL that

operates on object xyz will be subjectto STAYMETADATA.

STAYMETADATAalso can beused the same way in an EXCLUDE clause.

STAYMETADATAmust be usedthe same way on the source and target to ensure

metadata integrity.

When STAYMETADATA is in use, a message is added to thereport file. DDL reporting is

controlled by the DDLOPTIONS parameter with the REPORT option.

This same functionality can be applied globally to all DDL that occurs onthe source

by using the @ddl_staymetadatascripts:

■ @ddl_staymetadata_on globally turns off metadata versioning.

■ @ddl_staymetadata_off globally enables metadata versioning again.

This option should be used with the assistance of Oracle GoldenGatetechnical

support staff, because it might not always be apparent which DDL affectsobject

metadata. If improperly used, it can break the integrity of thereplication

environment.

Table 7–2 (Cont.) DDL inclusion and exclusionoptions

Option Description

Special filter cases

7-20 Oracle GoldenGate for Oracle Installation and Setup Guide

7.7.4 Combining DDL parameter options

The following is an example of how to combine the options of the DDL parameter.

DDL&

INCLUDEUNMAPPED &

OPTYPEalter &

OBJTYPE ‘table’&

OBJNAMEusers.tab* &

INCLUDEMAPPED OBJNAME * &

EXCLUDEMAPPED OBJNAME temporary.tab"

The combined filter criteria in this statement specify the following:

■ INCLUDE all ALTER TABLE statements for tables that are notmapped with a TABLE or

MAP statement (UNMAPPED scope), but only if those tables areowned by “users” and

their names start with “tab,”

■ and INCLUDE all DDLoperation types for all tables that are mapped with a TABLE

or MAP statement (MAPPED scope),

■ and EXCLUDE all DDLoperation types for all tables that are MAPPED in scope, but

only if those tables are owned by “temporary” and only if their names begin with

“tab.”

7.8 Special filter cases

The following are special cases that you should be aware of when creating yourfilter

conditions.

7.8.1 DDL EXCLUDE ALL

DDLEXCLUDE ALL is a specialprocessing option that maintains up-to-date object

metadata for Oracle GoldenGate, while blocking the replication of the DDLoperations

EVENTACTIONS(action

specification)

Causes the Extract or Replicat process take a defined action based on aDDL record in

the transaction log or trail, which is known as the eventrecord. The DDL eventis

triggered if the DDL record is eligible to be written to the trail byExtract or a data

pump, or to be executed by Replicat, as determined by the other filteringoptions of

the DDL parameter. You can use this systemto customize processing based on

database events.

For actionspecification see EVENTACTIONS under the MAP and TABLE parameters.

Guidelines for using EVENTACTIONS on DDL records:

■ CHECKPOINTBEFORE: Since each DDL record is autonomous, the DDL record is

guaranteed to be the start of a transaction; therefore, the CHECKPOINT BEFORE

event action is implied for a DDL record.

■ IGNORE: This optionis not valid for DDL records. Because DDL operations are

autonomous, ignoring a record is equivalent to ignoring the entiretransaction.

EVENTACTIONSdoes notsupport the following DDL objects because they are derived

objects:

■ indexes

■ triggers

■ synonyms

■ RENAME on a table and ALTER TABLE RENAME

Table 7–2 (Cont.) DDL inclusion and exclusionoptions

Option Description

How Oracle GoldenGate handles derived object names

Configuring DDLsynchronization for an Oracle database 7-21

themselves. You can use DDL EXCLUDE ALL when using a method other than Oracle

GoldenGate to apply DDL to the target, but you want Oracle GoldenGate toreplicate

data changes to the target objects. It provides the current metadata toOracle

GoldenGate as objects change, thus preventing the need to stop and startthe Oracle

GoldenGate processes. The following special conditions apply to DDL EXCLUDE ALL:

■ DDL EXCLUDE ALL does not require the use of an INCLUDE clause.

■ When using DDL EXCLUDE ALL, you can set the WILDCARDRESOLVE parameter to

IMMEDIATEto allowimmediate DML resolution if required.

To prevent all DDL metadata and operations from being replicated, omit theDDL

parameter entirely. The DDL trigger will continue to record the DDLoperations to the

history table, unless disabled manually.

7.8.2 Implicit DDL

User-generated DDL operations can generate implicit DDL operations. Forexample,

the following statement causes the Oracle DDL trigger to process twodistinct DDL

operations.

CREATETABLE customers (custID number, name varchar2(50), address varchar2(75),

address2varchar2(75), city varchar2(50), state (varchar2(2), zip number, contact

varchar2(50),areacode number(3), phone number(7), primary key (custID));

The first (explicit) DDL operation is the CREATE TABLE statement itself.

The second DDL operation is an implicit CREATE UNIQUE INDEX statement that creates

the index for the primary key. This operation is generated by the databaseengine, not

a user application.

Guidelines for filtering implicit DDL

When the DDL parameter is used to filter DDLoperations, Oracle GoldenGate filters

out any implicit DDL by default, because the explicit DDL will generatethe implicit

DDL on the target. For example, the target database will create theappropriate index

when the CREATE TABLE statement in the preceding exampleis applied by Replicat.

However, when the DDL trigger is used to filter DDL operations, you musthandle the

implicit DDL in your filter rules based on the following:

■ If your filtering rules exclude the explicit DDL frombeing propagated, you must

also create a rule to exclude the implicit DDL. For example, if youexclude the

CREATETABLE statement inthe following example, but do not exclude the implicit

CREATEUNIQUE INDEX statement, thetarget database will try to create the index on

a non-existent table.

CREATETABLE customers (custID number, name varchar2(50), address varchar2(75),

address2varchar2(75), city varchar2(50), state (varchar2(2), zip number,

contactvarchar2(50), areacode number(3), phone number(7), primary key

(custID));

■ If your filtering rules permit the propagation of theexplicit DDL, you do not need

to exclude the implicit DDL. It will be handled correctly by OracleGoldenGate

and the target database.

7.9 How Oracle GoldenGate handles derivedobject names

DDL operations can contain a base object name and also a derivedobject name. A base

object is an object that contains data. A derived object is an object thatinherits some

How Oracle GoldenGate handles derived object names

7-22 Oracle GoldenGate for Oracle Installation and Setup Guide

attributes of the base object to perform a function related to thatobject. DDL

statements that have both base and derived objects are:

■ RENAME and ALTER RENAME

■ CREATE and DROP on an index, synonym, or trigger

Consider the following DDL statement:

CREATEINDEX hr.indexPayrollDate ON TABLE hr.tabPayroll (payDate);

In this case, the table is the base object. Its name (hr.tabPayroll) is the base name and

is subject to mapping with TABLE or MAP under the MAPPED scope. The derived object is

the index, and its name (hr.indexPayrollDate) is the derived name.

You can map a derived name in its own TABLE or MAP statement, separately from that

of the base object. Or, you can use one MAP statement to handle both. In the case of MAP,

the conversion of derived object names on the target works as follows.

7.9.1 MAP exists for base object, but notderived object

If there is a MAP statement for the base object, butnot for the derived object, the result

is an implicitmapping of the derivedobject. Assuming the DDL statement includes

MAPPED, Replicat gives the derived objectthe same target owner as that of the base

object. The name of the derived object stays the same as in the sourcestatement. For

example, assume the following:

Extract (source)

Tablehr.tab*;

Replicant (target)

MAPhr.tab*, TARGET hrBackup.*;

Assume the following source DDL statement:

CREATEINDEX hr.indexPayrollDate ON TABLE hr.tabPayroll (payDate);

The CREATE INDEX statement is executed by Replicat onthe target as follows:

CREATEINDEX hrBackup.indexPayrollDate ON TABLE hrBackup.tabPayroll (payDate);

The rule for the implicit mapping is based the typical practice of givingderived objects

the same owner as the base object. It ensures the correct name conversioneven if the

name of the derived object is not fully qualified in the source statement.Also, when

indexes are owned by the same target owner as the base object, an implicitmapping

eliminates the need to map derived object names explicitly.

7.9.2 MAP exists for base and derived objects

If there is a MAP statement for the base object andalso one for the derived object, the

result is an explicit mapping. Assuming the DDL statement includes MAPPED, Replicat

converts the owner and name of each object according to its own TARGET clause. For

example, assume the following:

Extract (source)

TABLEhr.tab*;

TABLEhr.index*;

Replicat (target)

How Oracle GoldenGate handles derived object names

Configuring DDLsynchronization for an Oracle database 7-23

MAPhr.tab*, TARGET hrBackup.*;

MAPhr.index*, TARGET hrIndex.*;

Assume the following source DDL statement:

CREATEINDEX hr.indexPayrollDate ON TABLE hr.tabPayroll (payDate);

The CREATE INDEX statement is executed by Replicat onthe target as follows:

CREATEINDEX hrIndex.indexPayrollDate ON TABLE hrBackup.tabPayroll

(payDate);

Use an explicit mapping when the index on the target must be owned by adifferent

owner from that of the base object, or when the name on the target must bedifferent

from that of the source.

7.9.3 MAP exists for derived object, but notbase object

If there is a MAP statement for the derived object,but not for the base object, Replicat

does not perform any name conversion for either object. The target DDLstatement is

the same as that of the source. To map a derived object, the choices are:

■ Use an explicit MAP statement forthe base object.

■ If names permit, map both base and derived objects in thesame MAP statement by

means of a wildcard.

■ Create a MAP statement foreach object, depending on how you want the names

converted.

7.9.4 New tables as derived objects

The following explains how Oracle GoldenGate handles new tables that arecreated

from:

■ RENAME and ALTER RENAME

■ CREATE TABLE AS SELECT

7.9.4.1 RENAME and ALTER TABLE RENAME

In RENAME and ALTER TABLE RENAME operations, the base object isalways the new table

name. In the following example, the base object name is considered to be “index_

paydate.”

ALTERTABLE hr.indexPayrollDate RENAME TO index_paydate;

or...

RENAMEhr.indexPayrollDate TO index_paydate;

The derived object name is “hr.indexPayrollDate.”

7.9.4.2 CREATE TABLE AS SELECT

CREATETABLE AS SELECT statements include SELECT statements and INSERT

statements that affect any number of underlying objects. On the target,Oracle

GoldenGate obtains the data for the AS SELECT clause from the target database.

How Oracle GoldenGate handles derived object names

7-24 Oracle GoldenGate for Oracle Installation and Setup Guide

The objects in the AS SELECT clause must exist in the target database, and their names

must be identical to the ones on the source.

In a MAP statement, Oracle GoldenGate onlymaps the name of the new table (CREATE

TABLEname) to the TARGET specification, but does not map thenames of the underlying

objects from the AS SELECT clause. There could be dependencies on those objects that

could cause data inconsistencies if the names were converted to the TARGET

specification.

The following shows an example of a CREATE TABLE AS SELECT statement on the

source and how it would be replicated to the target by Oracle GoldenGate.

CREATETABLE a.tab1 AS SELECT * FROM a.tab2;

The MAP statement for Replicat is asfollows:

MAPa.tab*, TARGET a.x*;

The target DDL statement that is applied by Replicat is the following:

CREATETABLE a.xtab1 AS SELECT * FROM a.tab2;

The name of the table in the AS SELECT * FROM clause remains as it was on the source:

tab2 (rather than xtab2).

To keep the data in the underlying objects consistent on source andtarget, you can

configure them for data replication by Oracle GoldenGate. In the precedingexample,

you could use the following statements to accommodate this requirement:

Source

TABLEa.tab*;

Target

MAPEXCLUDEa.tab2

MAPa.tab*, TARGET a.x*;

MAPa.tab2, TARGET a.tab2;

See also "Correctlyidentifying unqualified object names in DDL" on page 7-9.

7.9.5 Disabling the mapping of derivedobjects

Use the DDLOPTIONS parameter with the NOMAPDERIVED option to prevent the

conversion of the name of a derived object according to a TARGET clause of a MAP

statement that includes it. NOMAPDERIVED overrides any explicit MAP statements that

contain the name of the base or derived object. Source DDL that containsderived

objects is replicated to the target with the same owner and object namesas on the

source.

The following table shows the results of MAPDERIVED compared to NOMAPDERIVED, based

on whether there is a MAP statement justfor the base object, just for the derived object,

or for both.

Note: For this reason, Oracle XMLType tables created from a CTAS

(CREATE TABLE ASSELECT) statementcannot be supported. For

XMLType tables, the row object IDs mustmatch between source and

target, which cannot be maintained in this scenario. XMLType tables

created by an empty CTAS statement (thatdoes not insert data in the

new table) can be maintained correctly.

Using DDL string substitution

Configuring DDLsynchronization for an Oracle database 7-25

The following examples illustrate the results of MAPDERIVED as compared to

NOMAPDERIVED.

In Table 7–4, both trigger and table are ownedby rpt on the target because both base

and derived names are converted by means of MAPDERIVED.

In Table 7–5, the trigger is owned by fin, because conversion is prevented bymeans of

NOMAPDERIVED.

7.10 Using DDL string substitution

You can substitute strings within a DDL operation while it is beingprocessed by

Oracle GoldenGate. This feature provides a convenience for changing andmapping

directory names, comments, and other things that are not directly relatedto data

structures. For example, you could substitute one tablespace name foranother, or

substitute a string within comments. String substitution is controlled bythe DDLSUBST

parameter. For more information, see the Oracle GoldenGate Windowsand UNIX

Reference Guide.

Table 7–3 [NO]MAPDERIVED results on targetbased on mapping configuration

Base Object Derived Object

MAP/NOMAP

DERIVED?

Derived object

converted per a

MAP?

Derived object

gets owner of

base object?

mapped1

1 Mapped meansincluded in a MAP statement.

mapped MAPDERIVED yes no

mapped not mapped MAPDERIVED no yes

not mapped mapped MAPDERIVED no no

not mapped not mapped MAPDERIVED no no

mapped mapped NOMAPDERIVED no no

mapped not mapped NOMAPDERIVED no no

not mapped mapped NOMAPDERIVED no no

not mapped not mapped NOMAPDERIVED no no

Table 7–4 Default mapping of derived objectnames (MAPDERIVED)

MAP statement

Source DDL statement

captured by Extract

Target DDL statement

applied by Replicant

MAPfin.*, TARGET rpt.*; CREATE TRIGGER fin.act_trig ON

fin.acct;

CREATETRIGGER rpt.act_trig ON

rpt.acct;

Table 7–5 Mapping of derived object nameswhen using NOMAPDERIVED

MAP statement

Source DDL statement

captured by Extract

Target DDL statement

applied by Replicant

MAPfin.*, TARGET rpt.*; CREATE TRIGGER fin.act_trig ON

fin.acct;

CREATETRIGGER fin.act_trig ON

rpt.acct;

Note: In the case of a RENAME statement, the new table name is

considered to be the base table name, and the old table name is

considered to be the derived table name.

Controlling the propagation of DDL that is executed byReplicat

7-26 Oracle GoldenGate for Oracle Installation and Setup Guide

7.11 Controlling the propagation of DDL thatis executed by Replicat

Extract and Replicat both issue DDL operations.

■ Extract issues ALTER TABLE statements to create log groups,

■ Replicat applies replicated DDL statements to the target.

To identify Oracle GoldenGate DDL operations, the following comment ispart of each

Extract and Replicat DDL statement:

/*GOLDENGATE_DDL_REPLICATION */

The DDLOPTIONS parameter controls whether or notReplicat’s DDL is propagated.

■ The GETREPLICATES and IGNOREREPLICATESoptions controlwhether Replicat’s

DDL operations are captured by Extract or ignored. The default is

IGNOREREPLICATES.

■ The GETAPPLOPS and IGNOREAPPLOPS options control whether DDL from

applications other than Replicat (the business applications) are capturedor

ignored.

By default, Extract ignores DDL that is applied to the local database by alocal

Replicat, so that the DDL is not sent back to its source, but Extractcaptures all other

DDL that is configured for replication. The following is the default DDLOPTIONS

configuration.

DDLOPTIONSGETAPPLOPS, IGNOREREPLICATES

This behavior can be modified. See the following topics:

■ "Propagating DDL in an active-active(bi-directional) configurations" on page 7-26

■ "Propagating DDL in a cascading configuration" on page 7-28

7.11.1 Propagating DDL in an active-active(bi-directional) configurations

Oracle GoldenGate supports active-active DDL replication between twosystems. For

an active-active bi-directional replication, the following must beconfigured in the

Oracle GoldenGate processes:

1. DDL that is performed by a businessapplication on one system must be replicated

to the other system to maintain synchronization. To satisfy thisrequirement,

include the GETAPPLOPSoption in the DDLOPTIONS statement in the Extract

parameter files on both systems.

2. DDL that is applied by Replicat onone system must be captured by the local

Extract and sent back to the other system. To satisfy this requirement,use the

GETREPLICATESoption in the DDLOPTIONS statement in the Extract parameterfiles

on both systems.

Note: Before you create a DDLSUBST parameter statement, it might

help to review "How DDL is evaluated for processing" on page 7-29 in

this chapter.

Controlling the propagation of DDL that is executed byReplicat

Configuring DDLsynchronization for an Oracle database 7-27

3. Each Replicat must be configured toupdate its object metadata cache whenever

the remote Extract sends over a captured Replicat DDL statement. Tosatisfy this

requirement, use the UPDATEMETADATA option in the DDLOPTIONSstatement inthe

Replicat parameter files on both systems.

The resultant DDLOPTIONSstatementsshould look as follows:

Extract (primary and secondary)

DDLOPTIONSGETREREPLICATES, GETAPPLOPS

Replicat (primary and secondary)

DDLOPTIONSUPDATEMETADATA

Note: An internal Oracle GoldenGate tokenwill cause the actual

Replicat DDL statement itself to be ignored to prevent loopback. The

purpose of propagating Replicat DDL back to the original system is so

that the Replicat on that system can update its object metadata cache,

in preparation to receive incoming DML, which will have the new

metadata. See Figure 7–1.

WARNING: Before you allow new DDL orDML to be issued for

the same object(s) as the original DDL, allowtime for the original

DDL to be replicated to the remote system andthen captured again

by the Extract on that system. This willensure that the operations

arrive in correct order to the Replicat onthe original system, to

prevent DML errors caused by metadatainconsistencies. See

Figure 7–1 formore information.

Adding supplemental log groups automatically

7-28 Oracle GoldenGate for Oracle Installation and Setup Guide

Figure 7–1 Path of DDL in round trip toupdate Replicat object metadata cache

7.11.2 Propagating DDL in a cascadingconfiguration

In a cascading configuration, use the following setting for DDLOPTIONS in the Extract

parameter file on each intermediary system. This configuration forcesExtract to

capture the DDL from Replicat on an intermediary system and cascade it tothe next

system downstream.

DDLOPTIONSGETREPLICATES, IGNOREAPPLOPS

7.12 Adding supplemental log groupsautomatically

You can use the DDLOPTIONS parameter with the ADDTRANDATA option to:

■ enable Oracle’s supplemental logging automatically fornew tables created with a

CREATETABLE.

■ update Oracle’s supplemental logging for tables affectedby an ALTER TABLE to

add or drop columns.

■ update Oracle’s supplemental logging for tables that arerenamed.

■ update Oracle’s supplemental logging for tables where uniqueor primary keys are

added or dropped.

By default, the ALTER TABLE that adds the supplemental logging is not replicated to the

target unless the GETREPLICATES parameter is in use.

For more information about this option, see the Oracle GoldenGate Windowsand UNIX

Reference Guide.

How DDL is evaluated for processing

Configuring DDLsynchronization for an Oracle database 7-29

7.13 Removing comments from replicated DDL

You can use the DDLOPTIONS parameter with the REMOVECOMMENTS BEFORE and

REMOVECOMMENTSAFTER options toprevent comments that were used in the source

DDL from being included in the target DDL. By default, comments are notremoved,

so that they can be used for string substitution.

For more information about this option, see the Oracle GoldenGate Windowsand UNIX

Reference Guide.

7.14 Replicating an IDENTIFIED BY password

Use the DDLOPTIONS parameter with the DEFAULTUSERPASSWORD and

REPLICATEPASSWORD| NOREPLICATEPASSWORD options to control how the password of

a replicated {CREATE| ALTER} USER name IDENTIFIED BY password statement is

handled. These options must be used together.

For more information about these options, see the Oracle GoldenGate Windowsand

UNIX Reference Guide.

7.15 How DDL is evaluated for processing

The following explains how Oracle GoldenGate processes DDL statements onthe

source and target systems. It shows the order in which different criteriain the Oracle

GoldenGate parameters are processed, and it explains the differencesbetween how

Extract and Replicat each process the DDL.

Extract

1. Extract captures a DDL statement.

2. Extract separates comments, if any,from the main statement.

3. Extract searches for the DDL parameter. (This example assumes itexists.)

4. Extract searches for the IGNOREREPLICATES parameter. If it is present, and if

Replicat produced this DDL on this system, Extract ignores the DDLstatement.

(This example assumes no Replicat operations on this system.)

5. Extract determines whether the DDLstatement is a RENAME. If so, the rename is

flagged internally.

6. Extract gets the base object nameand, if present, the derived object name.

7. If the statement is a RENAME, Extract changes it to ALTER TABLE RENAME.

8. Extract searches for the DDLOPTIONS REMOVECOMMENTS BEFORE parameter. If it is

present, Extract removes the comments from the DDL statement, but storesthem

in case there is a DDL INCLUDE or DDL EXCLUDE clause that uses INSTR or

INSTRCOMMENTS.

9. Extract determines the DDL scope: MAPPED, UNMAPPED or OTHER:

■ It is MAPPED if theoperation and object types are supported for mapping, and

the base object name and/or derived object name (if RENAME) is in a TABLE

parameter.

■ It is UNMAPPED if theoperation and object types are not supported for mapping,

and the base object name and/or derived object name (if RENAME) is not in a

TABLE parameter.

■ Otherwise the operation is identified as OTHER.

How DDL is evaluated for processing

7-30 Oracle GoldenGate for Oracle Installation and Setup Guide

10. Extract checks the DDL parameter for INCLUDE and EXCLUDE clauses, and it evaluates

the DDL parameter criteria in those clauses.All options must evaluate to TRUE in

order for the INCLUDE or EXCLUDE to evaluate to TRUE. The following occurs:

■ If an EXCLUDE clauseevaluates to TRUE, Extract discards the DDL statement

and evaluates another DDL statement. In this case, the processing stepsstart

over.

■ If an INCLUDE clauseevaluates to TRUE, or if the DDL parameter does not have

any INCLUDE or EXCLUDE clauses, Extract includes the DDLstatement, and the

processing logic continues.

11. Extract searches for a DDLSUBST parameter and evaluates the INCLUDE and EXCLUDE

clauses. If the criteria in those clauses add up to TRUE, Extract performs string

substitution. Extract evaluates the DDL statement against each DDLSUBST

parameter in the parameter file. For all true DDLSUBST specifications, Extract

performs string substitution in the order that the DDLSUBST parameters are listed in

the file.

12. Now that DDLSUBT has been processed, Extract searchesfor the REMOVECOMMENTS

AFTER parameter. If it is present, Extractremoves the comments from the DDL

statement.

13. Extract searches for DDLOPTIONS ADDTRANDATA. If it is present, and if theoperation

is CREATE TABLE, Extract issues the ALTER TABLE name ADD SUPPLEMENTAL LOG

GROUP command on the table.

14. Extract writes the DDL statement tothe trail.

Replicat

1. Replicat reads the DDL statementfrom the trail.

2. Replicat separates comments, if any,from the main statement.

3. Replicat searches for DDLOPTIONS REMOVECOMMENTS BEFORE. If it is present, Replicat

removes the comments from the DDL statement.

4. Replicat evaluates the DDLsynchronization scope to determine if the DDL

qualifies for name mapping. Anything else is of OTHER scope.

5. Replicat evaluates the MAP statements in the parameter file. Ifthe source base

object name for this DDL (as read from the trail) appears in any of the MAP

statements, the operation is marked as MAPPED in scope. Otherwise it is marked as

UNMAPPEDin scope.

6. Replicat replaces the source baseobject name with the base object name that is

specified in the TARGET clause of the MAP statement.

7. If there is a derived object,Replicat searches for DDLOPTIONS MAPDERIVED. If it is

present, Replicat replaces the source derived name with the target derivedname

from the MAP statement.

8. Replicat checks the DDL parameter for INCLUDE and EXCLUDE clauses, and it

evaluates the DDL parameter criteria contained inthem. All options must evaluate

to TRUE in order for the INCLUDE or EXCLUDE to evaluate to TRUE. The following

occurs:

■ If any EXCLUDE clauseevaluates to TRUE, Replicat discards the DDLstatement

and starts evaluating another DDL statement. In this case, the processingsteps

start over.

Handling DDL trigger errors

Configuring DDLsynchronization for an Oracle database 7-31

■ If any INCLUDE clauseevaluates to TRUE, or if the DDL parameter does not have

any INCLUDE or EXCLUDE clauses, Replicat includes the DDLstatement, and the

processing logic continues.

9. Replicat searches for the DDLSUBST parameter and evaluates the INCLUDE and

EXCLUDE clauses. If the options in thoseclauses add up to TRUE, Replicat performs

string substitution. Replicat evaluates the DDL statement against each DDLSUBST

parameter in the parameter file. For all true DDLSUBST specifications, Replicat

performs string substitution in the order that the DDLSUBST parameters are listed in

the file.

10. Now that DDLSUBT has been processed, Replicatsearches for the REMOVECOMMENTS

AFTER parameter. If it is present,Replicat removes the comments from the DDL

statement.

11. Replicat executes the DDL statementon the target database.

12. If there are no errors, Replicatprocesses the next DDL statement. If there are

errors, Replicat performs the following steps.

13. Replicat analyzes the INCLUDE and EXCLUDE rules in the Replicat DDLERROR

parameters in the order that they appear in the parameter file. IfReplicat finds a

rule for the error code, it applies the specified error handling;otherwise, it applies

DEFAULT handling.

14. If the error handling does notenable the DDL statement to succeed, Replicat does

one of the following: abends, ignores the operation, or discards it asspecified in

the rules.

7.16 Handling DDL processing errors

Use the DDLERROR parameter to handle errors onobjects found by Extract for which

metadata cannot be found, and for Replicat errors that occur when DDL isapplied to

the target database. With DDLERROR options, youcan handle most errors in a default

manner, for example to stop processing, and also handle other errors in aspecific

manner. You can use multiple instances of DDLERROR in the same parameter file to

handle all errors that are anticipated.

For options and usage, see the Oracle GoldenGate Windowsand UNIX Reference Guide.

7.17 Handling DDL trigger errors

Use the params.sql non-executable script to handlefailures of the Oracle GoldenGate

DDL trigger in relation to whether the source DDL fails or succeeds. The params.sql

script is in the root Oracle GoldenGatedirectory. The parameters to use are the

following:

■ ddl_fire_error_in_trigger: If set to TRUE, failures of the Oracle GoldenGate

DDL trigger are raised with a Oracle GoldenGate error message and adatabase

error message to the source end-user application. The source operationsfails.

If set to FALSE, no errors are raised, and amessage is written to the trigger trace file

in the Oracle GoldenGate directory. The source operation succeeds, but noDDL is

replicated. The target application will eventually fail if subsequent datachanges

do not match the old target object structure. The default is FALSE.

Note: If there are multiple targets forthe same source in a MAP

statement, the processing logic executes for each one.

Viewing DDL report information

7-32 Oracle GoldenGate for Oracle Installation and Setup Guide

■ _ddl_cause_error: If set to TRUE, tests the error response of the trigger by

deliberately causing an error. To generate the error, Oracle GoldenGateattempts

to SELECT zero rows without exceptionhandling. Revert this flag to the default of

FALSE after testing is done.

7.18 Viewing DDL report information

By default, Oracle GoldenGate shows basic statistics about DDL at the endof the

Extract and Replicat reports. To enable expanded DDL reporting, use the DDLOPTIONS

parameter with the REPORT option.Expanded reporting includes the following

information about DDL processing:

■ A step-by-step history of the DDL operations that wereprocessed by Oracle

GoldenGate.

■ The DDL filtering and processing parameters that arebeing used.

Expanded DDL report information increases the size of the report file, butit might be

useful in certain situations, such as for troubleshooting or to determinewhen an

ADDTRANDATAto addsupplemental logging was applied.

To view a report, use the VIEW REPORT command in GGSCI.

VIEWREPORT group

7.18.1 Extract DDL reporting

The Extract report lists the following:

■ The entire syntax of each captured DDL operation, thestart and end SCN, the

Oracle instance, the DDL sequence number (from the SEQNO column of the history

table), and the size of the operation in bytes.

■ A subsequent entry that shows how processing criteria wasapplied to the

operation, for example string substitution or INCLUDE and EXCLUDE filtering.

■ Another entry showing whether the operation was writtento the trail or excluded.

The following, taken from an Extract report, shows an included operationand an

excluded operation. There is a report message for the included operation,but not for

the excluded one.

2011-01-2015:11:41 GGS INFO 2100 DDL found, operation [create table myTable

(

myIdnumber (10) not null,

myNumbernumber,

myStringvarchar2(100),

myDatedate,

primarykey (myId)

) ],start SCN [1186754], commit SCN [1186772] instance [test11g (1)], DDL seqno

[4134].

2011-01-2015:11:41 GGS INFO 2100 DDL operation included [INCLUDE OBJNAME

myTable*],optype [CREATE], objtype [TABLE], objname [QATEST1.MYTABLE].

2011-01-2015:11:41 GGS INFO 2100 DDL operation written to extract trail

file.

2011-01-2015:11:42 GGS INFO 2100 Successfully added TRAN DATA for table

with thekey, table [QATEST1.MYTABLE], operation [ALTER TABLE"QATEST1"."MYTABLE"

ADDSUPPLEMENTAL LOG GROUP "GGS_MYTABLE_53475" (MYID) ALWAYS /*GOLDENGATE_DDL_

REPLICATION*/ ].

Viewing DDL report information

Configuring DDLsynchronization for an Oracle database 7-33

2011-01-2015:11:43 GGS INFO 2100 DDL found, operation [create table

myTableTemp(

vidvarchar2(100),

someDatedate,

primarykey (vid)

) ],start SCN [1186777], commit SCN [1186795] instance [test11g (1)], DDL seqno

[4137].

2011-01-2015:11:43 GGS INFO 2100 DDL operation excluded [EXCLUDE OBJNAME

myTableTempOPTYPE CREATE], optype [CREATE], objtype [TABLE], objname

[QATEST1.MYTABLETEMP].

7.18.2 Replicat DDL reporting

The Replicat report lists:

■ The entire syntax and source Oracle GoldenGate SCN ofeach DDL operation that

Replicat processed from the trail. You can use the source SCN for tracking

purposes, especially when there are restores from backup and Replicat is

positioned backward in the trail.

■ A subsequent entry that shows the scope of the operation(MAPPED, UNMAPPED,

OTHER) and how object names were mappedin the target DDL statement, if

applicable.

■ Another entry that shows how processing criteria wasapplied.

■ Additional entries that show whether the operationsucceeded or failed, and

whether or not Replicat applied error handling rules.

The following excerpt from a Replicat report illustrates a sequence ofsteps, including

error handling:

2011-01-2015:11:45 GGS INFO 2104 DDL found, operation [drop table

myTableTemp], Source SCN [1186713.0].

2011-01-2015:11:45 GGS INFO 2100 DDL is of mapped scope, after mapping new

operation[drop table "QATEST2"."MYTABLETEMP" ].

2011-01-2015:11:45 GGS INFO 2100 DDL operation included [include objname

myTable*],optype [DROP], objtype [TABLE], objname [QATEST2.MYTABLETEMP].

2011-01-2015:11:45 GGS INFO 2100 Executing DDL operation.

2011-01-2015:11:48 GGS INFO 2105 DDL error ignored for next retry: error

code[942], filter [include objname myTableTemp], error text [ORA-00942: table or

viewdoes not exist], retry [1].

2011-01-2015:11:48 GGS INFO 2100 Executing DDL operation , trying again due

toRETRYOP parameter.

2011-01-2015:11:51 GGS INFO 2105 DDL error ignored for next retry: error

code[942], filter [include objname myTableTemp], error text [ORA-00942: table or

viewdoes not exist], retry [2].

2011-01-2015:11:51 GGS INFO 2100 Executing DDL operation, trying again due

toRETRYOP parameter.

Viewing metadata in the DDL history table

7-34 Oracle GoldenGate for Oracle Installation and Setup Guide

2011-01-2015:11:54 GGS INFO 2105 DDL error ignored for next retry: error

code[942], filter [include objname myTableTemp], error text [ORA-00942: table or

viewdoes not exist], retry [3].

2011-01-2015:11:54 GGS INFO 2100 Executing DDL operation, trying again due

toRETRYOP parameter.

2011-01-2015:11:54 GGS INFO 2105 DDL error ignored: error code [942],

filter[include objname myTableTemp], error text [ORA-00942: table or view does

notexist].

7.18.3 Statistics in the process reports

You can send current statistics for DDL processing to the Extract andReplicat reports

by using the SEND command in GGSCI.

SEND{EXTRACT | REPLICAT} group REPORT

The statistics show totals for:

■ All DDL operations

■ Operations that are MAPPED in scope

■ Operations that are UNMAPPED in scope

■ Operations that are OTHER in scope

■ Operations that were excluded (number of operations minusincluded ones)

■ Errors (Replicat only)

■ Retried errors (Replicat only)

■ Discarded errors (Replicat only)

■ Ignored operations (Replicat only)

7.19 Viewing metadata in the DDL historytable

Use the DUMPDDL command in GGSCI to view theinformation that is contained in the

DDL history table. This information is stored in proprietary format, butyou can export

it in human-readable form to the screen or to a series of SQL tables thatyou can query.

The information in the DDL history table is the same as that used by theExtract

process. For more information, see the Oracle GoldenGate Windowsand UNIX

Reference Guide.

7.20 Tracing DDL processing

If you open a support case with Oracle GoldenGate Technical Support, youmight be

asked to turn on tracing. The following parameters control DDL tracing.

■ TLTRACE controlsExtract tracing

■ TRACE and TRACE2 control Replicat tracing.

These parameters have options to isolate the tracing of DDL from thetracing of DML.

For more information, see the Oracle GoldenGateWindows and UNIX ReferenceGuide.

7.21 Tracing the DDL trigger

To trace the activity of the Oracle GoldenGate DDL trigger, use thefollowing tools.

Tracing the DDL trigger

Configuring DDLsynchronization for an Oracle database 7-35

■ ggs_ddl_trace.log trace file: Oracle GoldenGate creates a trace file in theUSER_

DUMP_DESTdirectory ofOracle. On RAC, each node has its own trace file that

captures DDL tracing for that node. You can query the trace file asfollows:

selectvalue from sys.v_$parameter where name = 'user_dump_dest';

■ ddl_tracelevel script: Edit and run this script to set the trace level. A value of

None generates no DDL tracing, except forfatal errors and installation logging. The

default value of 0 generatesminimal tracing information. A value of 1 or 2

generates a much larger amount of information in the trace file. Do notuse 1 or 2

unless requested to do so by a Oracle GoldenGate Technical Support analystas

part of a support case.

■ ddl_cleartrace script: Run this script on a regular schedule to prevent the trace

file from consuming excessive disk space as it expands. It deletes thefile, but

Oracle GoldenGate will create another one. The DDL trigger stops writingto the

trace file when the Oracle directory gets low on space, and then resumeswriting

when space is available again. This script is in the Oracle GoldenGatedirectory.

Back up the trace file before running the script.

Tracing the DDL trigger

7-36 Oracle GoldenGate for Oracle Installation and Setup Guide

8

Instantiating andstarting Oracle GoldenGate replication 8-1

8Instantiatingand starting Oracle GoldenGate

replication

This chapter contains instructions for configuring an initial load oftarget data, adding

the required processes to instantiate replication, and perform theinstantiation. The

expected outcome of these steps is that source-target data is madeconsistent (known

as the initial synchronization), and that Oracle GoldenGate captures anddelivers

ongoing transactional changes so that consistency is maintained goingforward.

8.1 Overview of basic Oracle GoldenGateinstantiation steps

These instructions show you how to instantiate the basic replicationenvironment that

you configured in Chapter 4. These steps are:

■ Satisfying prerequisites for instantiation

■ Making the instantiation procedure more efficient

■ Configuring the initial load

■ Registering Extract with the mining database

■ Adding change-capture and change-delivery processes

■ Performing the target instantiation

■ Monitoring processing after the instantiation

■ Backing up the Oracle GoldenGate environment

8.2 Satisfying prerequisites forinstantiation

These steps must be taken before starting any Oracle GoldenGate processesor native

database load processes.

8.2.1 Configure change capture and delivery

By the time you are ready to instantiate the replication environment, allof your

Extract and Replicat process groups must be configured with completedparameter

files as directed in Chapter 4.

In addition, all of the other setup requirements in this manual must besatisfied.

8.2.2 Add collision handling

If the source database will remain active during the initial load,collision-handling

logic must be added to the Replicat parameter file. This logic handlesconflicts that

Making the instantiation procedure more efficient

8-2 Oracle GoldenGate for Oracle Installation and Setup Guide

occur because static data is being loaded to the target tables whileOracle GoldenGate

replicates transactional changes to those tables.

To handle collisions, add the HANDLECOLLISIONS parameter to the Replicat parameter

file to resolve:

■ INSERT operations forwhich the row already exists

■ UPDATE and DELETE operations for which the row doesnot exist

For more information about HANDLECOLLISIONS, see the Oracle GoldenGate

Windows and UNIX Reference Guide.

8.2.3 Disable DDL processing

Before executing an initial load, disable DDL extraction and replication.DDL

processing is controlled by the DDL parameter inthe Extract and Replicat parameter

files. See Chapter 7 for more information about DDL support.

8.2.4 Prepare the target tables

The following are suggestions that can make the load go faster and helpyou to avoid

errors.

■ Data: Make certain that the targettables are empty. Otherwise, there may be

duplicate-row errors or conflicts between existing rows and rows that arebeing

loaded.

■ Constraints: If you have not done so already,disable foreign-key constraints and

check constraints. Foreign-key constraints can cause errors, and checkconstraints

can slow down the loading process. See also "Preparing integrityconstraints in

source and target tables" on page 5-1 for additional requirements.

■ Indexes: Remove indexes from the targettables. Indexes are not necessary for the

inserts performed by the initial load process and will slow it downsignificantly.

You can add back the indexes after the load is finished.

■ Keys: To use the HANDLECOLLISIONS function to reconcile incrementaldata changes

with the load, each target table must have a primary or unique key. If youcannot

create a key through your application, use the KEYCOLS option of the TABLE and MAP

parameters to specify columns as a substitute key for Oracle GoldenGate’s

purposes. If you cannot create keys, the affected source table must bequiesced for

the load.

8.3 Making the instantiation procedure moreefficient

The following are some suggestions for making the instantiation processmove more

efficiently.

8.3.1 Share parameters between process groups

Some of the parameters that you use in a change-synchronization parameterfile also

are required in an initial-load Extract and initial-load Replicatparameter file. To take

advantage of the commonalities, you can use any of the following methods:

■ Copy common parameters from one parameter file toanother.

■ Store the common parameters in a central file and use theOBEY parameter in each

parameter file to retrieve them.

Configuring the initial load

Instantiating andstarting Oracle GoldenGate replication 8-3

■ Create an Oracle GoldenGate macro for the commonparameters and then call the

macro from each parameter file with the MACRO parameter.

8.3.2 Use parallel processes

You can configure parallel initial-load processes to perform the initialload more

quickly. It is important to keep tables with foreign-key relationshipswithin the same

set of processes. You can isolate large tables from smaller ones by usingdifferent sets

of processes, or simply apportion the load across any number of processsets. To

configure parallel processes correctly, see the Windowsand UNIX Troubleshooting and

Tuning Guide.

8.4 Configuring the initial load

Oracle GoldenGate supports the following load methods specifically forOracle:

■ To load with a database utility

■ To load from an input file to SQL*Loader

■ To load with a database utility

Select a method and follow its configuration steps to create the loadprocesses and

parameter files.

8.4.1 To load with a database utility

Figure 8–1

This method uses a database copy utility to establish the target data. Youstart a

change-synchronization Extract group to extract ongoing data changes whilethe

database utility makes and applies a static copy of the data. When thecopy is finished,

you start the change-synchronization Replicat group to re-synchronize rowsthat were

changed while the copy was being applied. From that point forward, bothExtract and

Replicat continue running to maintain data synchronization.

No special configuration of any initial-load processes is needed for thismethod. You

just use the change-synchronization process groups that you configured in Chapter 4.

8.4.2 To direct bulk load to SQL*Loader

Configuring the initial load

8-4 Oracle GoldenGate for Oracle Installation and Setup Guide

With this method, you configure and run an Oracle GoldenGate initial-loadExtract to

extract complete source records and send them directly to an initial-loadReplicat task.

The initial-load Replicat task communicates with SQL*Loader to load dataas a

direct-path bulk load. Data mapping and transformation can be done byeither the

initial-load Extract or initial-load Replicat, or both. During the load,the

change-synchronization groups that you configured in Chapter 4 replicated

incremental changes, which are then reconciled with the results of theload.

Limitations:

■ This method does not support extraction of LOB or LONG data. As an alternative, see

“To load from an input file to SQL*Loader” on page 126.

■ This method does not support materialized views thatcontain LOBs, regardless of

their size. It also does not support data encryption.

To configure a direct bulk load to SQL*Loader

1. Grant LOCK ANY TABLE to the Replicat database user on thetarget Oracle database.

2. On the source and target systems,run GGSCI.

3. Start Manager on both systems.

STARTMANAGER

4. On the source system, create theinitial-load Extract.

ADDEXTRACT initial-loadExtract name, SOURCEISTABLE

Where:

■ initial-load Extract name is the name of the initial-loadExtract, up to eight

characters.

■ SOURCEISTABLE directs Extract to read complete records directly from the

source tables.

5. On the source system, create theinitial-load Extract parameter file.

EDITPARAMS initial-loadExtract name

6. Enter the initial-load Extractparameters in the order shown, starting a new line for

each parameter statement. Your input will be different. Refer to Table 8–1 for

descriptions.

EXTRACTinitext

USERIDogg, PASSWORD AACAAAAAAAAAAAJAUEUGODSCVGJEEIUGKJDJTFNDKEJFFFTC &

AES128,ENCRYPTKEY securekey1

RMTHOSTfin1, MGRPORT 7809 ENCRYPT AES192, KEYNAME securekey2

RMTTASKreplicat, GROUP initrep

TABLEhr.*;

Table 8–1 Initial-load Extract parameters todirect bulk load to SQL*Loader

Parameter Description

EXTRACT initial-load Extract

name

Specifies the name of the initial-load Extract, as stated

with ADD EXTRACT.

USERID user id, PASSWORD pw

[encryption options]

Specifies database credentials and encryption information,

if required. You can use the same user that you created for

the change-synchronization processes.

RMTHOST hostname, MGRPORT

portnumber[, ENCRYPT

algorithm KEYNAME keyname]

Specifies the target system, the port where Manager is

running, and optional encryption of data across TCP/IP.

Configuring the initial load

Instantiating andstarting Oracle GoldenGate replication 8-5

7. Save and close the file.

8. On the target system, create theinitial-load Replicat.

ADDREPLICAT initial-loadReplicat name,SPECIALRUN

Where:

■ initial-load Replicat name is the name of the initial-loadReplicat task.

■ SPECIALRUN identifies the initial-load Replicat as a one-time task, not a

continuous process.

9. On the target system, create theinitial-load Replicat parameter file.

EDITPARAMS initial-loadReplicat name

10. Enter the initial-load Replicatparameters in the order shown, starting a new line

for each parameter statement. See Table 8–2 for descriptions.

REPLICATinitrep

USERIDogg, PASSWORD AACAAAAAAAAAAAJAUEUGODSCVGJEEIUGKJDJTFNDKEJFFFTC &

AES128,ENCRYPTKEY securekey1

BULKLOAD

ASSUMETARGETDEFS

MAPhr.*, TARGET hr2.*;

RMTTASKreplicat, GROUP

initial-load Replicat name

Specifies the process type (must be Replicat) and the name

of the initial-load Replicat. Directs Manager on the target

system to dynamically start the initial-load Replicat as a

one-time task.

TABLE owner.table; Specifies the owner and a table ormultiple tables specified

with a wildcard for initial data extraction. To exclude any

objects from a wildcard specification, use the

TABLEEXCLUDEparameter.

Table 8–2 Initial-load Replicat parameters todirect bulk load to SQL*Loader

Parameter Description

REPLICAT initial-load

Replicat name

Specifies the name of the initial-load Replicat task, as stated with

ADDREPLICAT.

USERID user id, PASSWORD

pw [encryptionoptions]

Specifies database credentials and encryption information, if

required. You can use the same user that you created for the

change-synchronization processes.

BULKLOADDirectsReplicat to interface directly with the Oracle SQL*Loader

interface.

ASSUMETARGETDEFSAssumes thesource and target tables are identical, including

semantics. If source and target definitions are different, you

must create and specify a source-definitions file that both the

change-synchronization and initial-load processes will use. For

more information, see the Windows and UNIX Administrator's

Guide.

Table 8–1 (Cont.) Initial-load Extractparameters to direct bulk load to SQL*Loader

Parameter Description

Configuring the initial load

8-6 Oracle GoldenGate for Oracle Installation and Setup Guide

11. Save and close the parameter file.

12. Proceed to "Registering Extract withthe mining database" on page 8-8.

8.4.3 To load from an input file toSQL*Loader

Figure 8–2

With this method, an initial-load Extract extracts source records from thesource tables

and writes them to an extract file in external ASCII format. The files areread by

SQL*Loader. During the load, the change-synchronization groups that youconfigured

in Chapter 4 replicate incremental changes, which are then reconciled withthe results

of the load. As part of the load procedure, Oracle GoldenGate uses theinitial-load

Replicat to create run and control files required by the database utility.Any data

transformation must be performed by the initial-load Extract on the sourcesystem

because the control files are generated dynamically and cannot bepre-configured with

transformation rules.

To configure a load from file to SQL*Loader

1. On the source and target systems,run GGSCI.

2. Start Manager on both systems.

STARTMANAGER

3. On the source system, create theinitial-load Extract parameter file.

EDITPARAMS initial-loadExtract name

4. Enter the initial-load Extractparameters in the order shown, starting a new line for

each parameter statement. Your input will be different. Refer to Table 8–3 for

descriptions.

SOURCEISTABLE

USERIDogg, PASSWORD AACAAAAAAAAAAAJAUEUGODSCVGJEEIUGKJDJTFNDKEJFFFTC &

AES128,ENCRYPTKEY securekey1

RMTHOSTfin1, MGRPORT 7809 ENCRYPT AES192, KEYNAME securekey2

ENCRYPTTRAILAES192, KEYNAME mykey1

RMTFILE/ggs/dirdat/ie

MAP owner.table, TARGET

owner.table;

Specifies a relationship between a source and target table or

tables.

■ owner is the schema name.

■ table is the name of a table or a wildcarddefinition for

multiple tables. To exclude any objects from a wildcard

specification, use the MAPEXCLUDE parameter.

Table 8–2 (Cont.) Initial-load Replicatparameters to direct bulk load to SQL*Loader

Parameter Description

Configuring the initial load

Instantiating andstarting Oracle GoldenGate replication 8-7

FORMATASCII,SQLLOADER

TABLEhr.*;

5. Save and close the parameter file.

6. On the target system, create theinitial-load Replicat parameter file.

EDITPARAMS <initial-load Replicat name>

7. Enter the initial-load Replicatparameters in the order shown, starting a new line

for each parameter statement. See Table 8–4 for descriptions.

GENLOADFILESsqlldr.tpl

USERIDogg, PASSWORD AACAAAAAAAAAAAJAUEUGODSCVGJEEIUGKJDJTFNDKEJFFFTC &

AES128,ENCRYPTKEY securekey1

DECRYPTTRAILAES192, KEYNAME mykey1

EXTFILE/ggs/dirdat/ie

ASSUMETARGETDEFS

MAPhr.*, TARGET hr2.*;

Table 8–3 Initial-load Extract parameters toload from file to SQL*Loader

Parameter Description

SOURCEISTABLEDesignatesExtract as an initial load process that extracts records

directly from the source tables.

USERID user id, PASSWORD

pw [encryptionoptions]

Specifies database credentials and encryption information, if

required. You can use the same user that you created for the

change-synchronization processes.

RMTHOST hostname,

MGRPORT portnumber[,

ENCRYPT algorithm

KEYNAME keyname]

Specifies the target system, the port where Manager is running,

and optional encryption of data across TCP/IP.

ENCRYPTTRAILencryption

options

Encrypts the data in the remote file. For encryption options, see

the Oracle GoldenGate Windows and UNIX Reference Guide.

RMTFILE path name Specifies the absolute or full pathname of an extract file that

Extract creates and to which it writes the load data.

FORMATASCII,SQLLOADER Produces afixed-length, ASCII-formatted remote file that is

compatible with SQL*Loader. For information about limitations

and options of FORMATASCII, see the Oracle GoldenGate Windows

and UNIX Reference Guide.

TABLE owner.table; Specifies the owner and a table ormultiple tables specified with

a wildcard for initial data extraction. To exclude any objects

from a wildcard specification, use the TABLEEXCLUDE parameter.

Table 8–4 Initial-load Replicat parameters toload from file to SQL*Loader

Parameter Description

GENLOADFILEStemplate

file

Generates run and control files for the database utility. For

instructions on using this parameter, see the Oracle GoldenGate

Windows and UNIX Reference Guide

USERID user id, PASSWORD

pw [encryptionoptions]

USERID specifies database credentials andencryption

information, if required. You can use the same user that you

created for the change-synchronization processes.

DECRYPTTRAILencryption

options

Decrypts the data in the input extract file. For encryption

options, see the Oracle GoldenGate Windows and UNIX Reference

Guide

Registering Extract with the mining database

8-8 Oracle GoldenGate for Oracle Installation and Setup Guide

8. Save and close the parameter file.

9. Proceed to "Registering Extract withthe mining database".

8.5 Registering Extract with the miningdatabase

To create the database logmining server, you register each Extract processwith the

mining database. The creation of the logmining server extracts a snapshotof the

source database in the redo stream of the source database. To avoidunnecessary

logmining activity on the source, perform this procedure close in time towhen you

instantiate replication.

1. Log into the mining database. Thecommand to use differs, depending on whether

the database logmining server is to be created at a source mining databaseor a

downstream mining database.

Command for source deployment:

DBLOGINUSERID user, PASSWORD password [encryption options]

Command for downstream deployment:

MININGDBLOGINUSERID user, PASSWORD password [encryption options]

Where: encryption options specifies optional encryption options for the

password. For more information, see DBLOGIN in the Oracle GoldenGate Windows

and UNIX Reference Guide.

2. Register the Extract process withthe mining database. To register multiple

Extracts with a downstream database, issue the command for each one.

REGISTEREXTRACT group DATABASE

The register process may take a few to several minutes to complete, eventhough the

REGISTERcommand returnsimmediately.

EXTFILE path name |

EXTTRAILpathname

Specifies the extract file that you specified with the Extract

parameter RMTFILE.

ASSUMETARGETDEFSAssumes thesource and target tables are identical, including

semantics. If source and target definitions are different, you

must create and specify a source-definitions file that both the

change-synchronization and initial-load processes will use. For

more information, see the Oracle GoldenGate Windows and

UNIX Administrator's Guide.

MAP owner.table, TARGET

owner.table;

Specifies a relationship between a source and target table or

tables.

■ owner is the schema name.

■ table is the name of a table or a wildcarddefinition for

multiple tables. To exclude objects from a wildcard

specification, use the MAPEXCLUDE parameter.

Table 8–4 (Cont.) Initial-load Replicatparameters to load from file to SQL*Loader

Parameter Description

Adding change-capture and change-delivery processes

Instantiating andstarting Oracle GoldenGate replication 8-9

8.6 Adding change-capture and change-deliveryprocesses

These steps establish the Oracle GoldenGate Extract, data pump, andReplicat

processes that you configured in Chapter 4. Collectively known as the

“change-synchronization” processes, these are the processes that:

■ capture and apply ongoing source changes while the loadis being performed on

the target

■ reconcile any collisions that occur

8.6.1 Set the RMAN archive log deletionpolicy

Set the RMAN archivelog deletion policy to the following value:

CONFIGUREARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY

This must be done before you add the primary Extract.

8.6.2 Add the primary Extract

These steps add the primary Extract that captures change data.

1. Run GGSCI.

2. Issue the ADD EXTRACT command to add the primary Extractgroup.

ADDEXTRACT groupname

{,TRANLOG | , INTEGRATED TRANLOG}

{, BEGIN{NOW | yyyy-mm-dd[:hh:mi:[ss[.cccccc]]]} |

{,EXTSEQNO seqno, EXTRBA relative byte address}

[,THREADS n]

Where:

■ group name is the name of the Extract group.

■ TRANLOG specifies thetransaction log as the data source; for classic capture only.

■ INTEGRATED TRANLOG specifies that Extract receives logical change records

through a database logmining server; for integrated captureonly.

■ BEGIN specifies tobegin capturing data as of a specific time:

– NOW starts at the first record that is timestamped at thesame time that 3 is

issued.

– yyyy-mm-dd [:hh:mi:[ss[.cccccc]]] starts at an explicit timestamp. Logs

from this timestamp must be available.

■ EXTSEQNO seqno, EXTRBA relative byte address specifies to begin

capturing data at a specific location (log sequence number and RBA) in the

redo stream.

■ THREADS n is required inclassic capture mode for Oracle Real Application

Cluster (RAC), to specify the number of redo log threads being used by the

cluster. Extract reads and coordinates each thread to maintaintransactional

consistency. Not required for integrated capture.

Note: Perform these steps at or close tothe time that you are ready

to start the initial load and change capture. You will start these

processes during the initial load steps.

Adding change-capture and change-delivery processes

8-10 Oracle GoldenGate for Oracle Installation and Setup Guide

Example 8–1 Classic capture with timestampstart point

ADDEXTRACT finance, TRANLOG, BEGIN 2011-01-01 12:00:00.000000

Example 8–2 Integrated capture with ADDEXTRACT timestamp start point

ADDEXTRACT finance, INTEGRATED TRANLOG, BEGIN NOW

Example 8–3 Integrated capture with logsequence/RBA start point

ADDEXTRACT finance, INTEGRATED TRANLOG, EXTSEQNO 2952, EXTRBA 7598080

8.6.3 Add the local trail

These steps add the local trail to which the primary Extract writescaptured data.

In GGSCI on the source system, issue the ADD EXTTRAIL command:

ADDEXTTRAIL pathname, EXTRACT group name

Where:

■ EXTTRAIL specifies thatthe trail is to be created on the local system.

■ pathname is the relative or fully qualifiedname of the trail, including the

two-character name.

■ EXTRACT group name isthe name of the primary Extract group.

Example 8–4

ADDEXTTRAIL /ggs/dirdat/lt, EXTRACT finance

8.6.4 Add the data pump Extract group

These steps add the data pump that reads the local trail and sends thedata to the

target.

In GGSCI on the source system, issue the ADD EXTRACT command.

ADDEXTRACT groupname, EXTTRAILSOURCE trail name

Where:

■ group name is the name of the Extract group.

■ EXTTRAILSOURCE trail name is the relative or fully qualified name of the local

trail.

Example 8–5

ADDEXTRACT financep, EXTTRAILSOURCE c:\ggs\dirdat\lt

Note: This is the minimum required syntax.Additional options are

available. See the Oracle GoldenGate Windows and UNIX Reference

Guide.

Performing the target instantiation

Instantiating andstarting Oracle GoldenGate replication 8-11

8.6.5 Add the remote trail

These steps add the remote trail. Although it is read by Replicat, thistrail must be

associated with the data pump, so it must be added on the source system,not the

target.

In GGSCI on the source system, issue the following command:

ADDRMTTRAIL pathname,EXTRACT group name

Where:

■ RMTTRAIL specifies thatthe trail is to be created on the target system.

■ pathname is the relative or fully qualified name of thetrail, including the

two-character name.

■ EXTRACT group name is the name of the data-pump Extract group.

Example 8–6

ADDRMTTRAIL /ggs/dirdat/rt, EXTRACT financep

8.6.6 Add the Replicat group

These steps add the Replicat group that reads the remote trail (which getscreated

automatically on the target) and applies the data changes to the targetOracle database.

1. Run GGSCI on the target system.

2. Issue the ADD REPLICAT command.

ADDREPLICAT groupname, EXTTRAIL pathname

Where:

■ group name is the name of the Replicat group.

■ EXTTRAIL pathname is the relative or fully qualified name of the remote trail,

including the two-character name.

Example 8–7

ADDREPLICAT financer, EXTTRAIL c:\ggs\dirdat\rt

8.7 Performing the target instantiation

This procedure instantiates the target tables while Oracle GoldenGatecaptures

ongoing transactional changes on the source and stores them until they canbe applied

on the target. By the time you perform the instantiation of the targettables, the entire

Oracle GoldenGate environment should be configured for change capture and

delivery, as should the initial-load processes if using Oracle GoldenGateas an

initial-load utility.

8.7.1 To perform instantiation with adatabase utility

1. On the source and target systems,run GGSCI and start the Manager process.

STARTMANAGER

Performing the target instantiation

8-12 Oracle GoldenGate for Oracle Installation and Setup Guide

2. Start the primary change-captureExtract group.

STARTEXTRACT Extractgroup name

3. Start the data-pump Extract group.

STARTEXTRACT datapump name

4. If replicating sequence values:

■ Issue the DBLOGIN command as auser who has EXECUTE privilege on

update.Sequence.

DBLOGINUSERID DBLOGINuser, PASSWORD password [encryption options]

■ Issue the following command to update each sourcesequence and generate

redo. From the redo, Replicat performs initial synchronization of the

sequences on the target. You can use an asterisk wildcard for any or all

characters for the sequence name but not owner.

FLUSHSEQUENCE owner.sequence

5. Start making the copy with the databaseutility.

6. Wait until the copy is finished andrecord the time of completion.

7. On the target system, view theReplicat parameter file to make certain that the

HANDLECOLLISIONSparameter islisted. If not, add the parameter with the EDIT

PARAMS command.

VIEWPARAMS groupname

EDITPARAMS groupname

8. Start Replicat.

STARTREPLICAT groupname

9. Issue the INFO REPLICAT command, and continue to issue ituntil it shows that

Replicat posted all of the change data that was generated during theinitial load.

For example, if the initial-load Extract stopped at 12:05, make sureReplicat posted

data up to that time.

INFOREPLICAT groupname

10. Turn off HANDLECOLLISIONS for the change-delivery Replicat todisable initial-load

error handling.

SENDREPLICAT groupname,NOHANDLECOLLISIONS

11. Edit the change-delivery Replicatparameter file to remove the HANDLECOLLISIONS

parameter.

EDITPARAMS groupname

12. Save and close the parameter file.

Note: In a Windows cluster, start theManager resource from the

Cluster Administrator.

Note: The first time that Extract startsin a new Oracle GoldenGate

configuration, any open transactions will be skipped. Only

transactions that begin after Extract starts are captured.

Performing the target instantiation

Instantiating andstarting Oracle GoldenGate replication 8-13

From this point forward, Oracle GoldenGate continues to synchronize datachanges.

8.7.2 To perform instantiation with directbulk load to SQL*Loader

1. On the source system, run GGSCI.

2. Start the primary change-captureExtract group.

STARTEXTRACT groupname

3. Start the data-pump Extract group.

STARTEXTRACT datapump name

4. If replicating sequence values:

■ Issue the DBLOGIN command as auser who has EXECUTE privilege on

update.Sequence.

DBLOGINUSERID DBLOGINuser, PASSWORD password [encryption options]

■ Issue the following command to update each sourcesequence and generate

redo. From the redo, Replicat performs initial synchronization of the

sequences on the target. You can use an asterisk wildcard for any or all

characters for the sequence name but not owner.

FLUSHSEQUENCE owner.sequence

5. Start the initial-load Extract.

STARTEXTRACT initial-loadExtract name

6. On the target system, run GGSCI.

7. Issue the VIEW REPORT command to determine when theinitial load to

SQL*Loader is finished.

VIEWREPORT initial-loadExtract name

8. When the load is finished, start thechange-data Replicat group.

STARTREPLICAT groupname

9. Issue the INFO REPLICAT command, and continue to issue ituntil it shows that

Replicat posted all of the change data that was generated during theinitial load.

For example, if the initial-load Extract stopped at 12:05, make sureReplicat posted

data up to that time.

INFOREPLICAT groupname

10. Turn off HANDLECOLLISIONS for the change-delivery Replicat todisable initial-load

error handling.

SENDREPLICAT groupname,NOHANDLECOLLISIONS

11. Edit the change-delivery Replicatparameter file to remove the HANDLECOLLISIONS

parameter.

EDITPARAMS groupname

WARNING: Do not start theinitial-load Replicat. The Manager

process starts it automatically andterminates it when the load is

finished.

To perform instantiation from an input file to SQL*Loader

8-14 Oracle GoldenGate for Oracle Installation and Setup Guide

12. Save and close the parameter file.

From this point forward, Oracle GoldenGate continues to synchronize datachanges.

8.8 To perform instantiation from an inputfile to SQL*Loader

1. On the source system, run GGSCI.

2. Start the primary change-captureExtract group.

STARTEXTRACT groupname

3. Start the data-pump Extract group.

STARTEXTRACT datapump name

4. If replicating sequence values:

■ Issue the DBLOGIN command as auser who has EXECUTE privilege on

update.Sequence.

DBLOGINUSERID DBLOGINuser, PASSWORD password [encryption options]

■ Issue the following command to update each sourcesequence and generate

redo. From the redo, Replicat performs initial synchronization of the

sequences on the target. You can use an asterisk wildcard for any or all

characters for the sequence name but not owner.

FLUSHSEQUENCE owner.sequence

5. From the Oracle GoldenGateinstallation directory on the source system, start the

initial-load Extract from the command line of the operating system (notGGSCI).

UNIX and Linux:

$ /OGG directory/extract paramfile dirprm/initial-load Extract name.prm

reportfilepathname

Windows:

C:\> OGG directory\extract paramfile dirprm\initial-load Extract

name.prm reportfile path name

Where: initial-load Extract name is the name of the initial-load Extract and

path name is the relative or fully qualified path where you wantthe Extract report

file to be created.

6. Wait until the initial extractionfrom the source is finished. Verify its progress and

results by viewing the Extract report file from the command line.

7. On the target system, start theinitial-load Replicat.

UNIX and Linux:

$ /OGG directory/replicat paramfile dirprm/initial-load Replicat

name.prm reportfile path name

Windows:

C:\> OGG directory\replicat paramfile dirprm\initial-load Replicat

name.prm reportfile path name

Where: initial-loadExtract name is the name ofthe initial-load Replicat and

path name is the relative or fully qualified path where you wantthe Replicat

report file to be created.

Backing up the Oracle GoldenGate environment

Instantiating andstarting Oracle GoldenGate replication 8-15

8. When the initial-load Replicatstops, verify its results by viewing the Replicat

report file from the command line.

9. Using the ASCII-formatted file andthe run and control files that the initial-load

Replicat created, load the data with SQL*Loader.

10. When the load is finished, start thechange-delivery Replicat group.

STARTREPLICAT groupname

11. Issue the INFO REPLICAT command, and continue to issue ituntil it shows that

Replicat posted all of the change data that was generated during theinitial load.

For example, if the initial-load Extract stopped at 12:05, make sureReplicat posted

data up to that time.

INFOREPLICAT groupname

12. Turn off HANDLECOLLISIONS for the change-delivery Replicat todisable initial-load

error handling.

SENDREPLICAT groupname,NOHANDLECOLLISIONS

13. Edit the change-delivery Replicatparameter file to remove the HANDLECOLLISIONS

parameter.

EDITPARAMS groupname

14. Save and close the parameter file.

From this point forward, Oracle GoldenGate continues to synchronize datachanges.

8.9 Monitoring processing after theinstantiation

After the target is instantiated and replication is in effect, you can,and should, view

the status, lag, and overall health of the replication environment toensure that

processes are running properly, that there are no warnings in the OracleGoldenGate

error log, and that lag is at an acceptable level. You can view OracleGoldenGate

processes from:

■ GGSCI: See the Oracle GoldenGate Windowsand UNIX Administrator's Guide.

■ Oracle GoldenGate Monitor: See the administrationdocumentation and online help

for that product.

You also should verify that capture and delivery is being performed forall of the

appropriate tables, and that the data remains synchronized. You can usethe Oracle

GoldenGate Veridata product for this purpose.

8.10 Backing up the Oracle GoldenGateenvironment

After you start Oracle GoldenGate processing, an effective backup routineis critical to

preserving the state of processing in the event of a failure. Unless theOracle

GoldenGate working files can be restored, the entire replicationenvironment must be

re-instantiated, complete with new initial loads.

As a best practice, include the entire Oracle GoldenGate home installationin your

backup routines. There are too many critical sub-directories, as well asfiles and

programs at the root of the directory, to keep track of separately. In anyevent, the

most critical files are those that consume the vast majority of backupspace, and

therefore it makes sense just to back up the entire installation directoryfor fast, simple

recovery.

Backing up the Oracle GoldenGate environment

8-16 Oracle GoldenGate for Oracle Installation and Setup Guide

9

Controllingprocesses 9-1

9Controllingprocesses

The standard way to control online processes is through GGSCI. Foralternate

methods, see the Oracle GoldenGate Windows and UNIXAdministrator's Guide.

9.1 When to start processes

Typically, the first time that Oracle GoldenGate processes are started ina production

setting is during the initial synchronization process, assuming sourceuser applications

must remain active. While the target is loaded with the source data,Oracle

GoldenGate captures ongoing user changes and then reconciles them with theresults

of the load.

9.2 Starting processes after instantiation iscomplete

These instructions are for starting the processes on a daily basis, asneeded. They show

basic syntax. Additional syntax may be available and is documented in theOracle

GoldenGate Windows and UNIX Reference Guide.

To start Manager

1. From the Oracle GoldenGatedirectory, run GGSCI.

2. In GGSCI, issue the followingcommand.

STARTMANAGER

To start Extract or Replicat

START{EXTRACT | REPLICAT} group_name

Where group_nameis the name ofthe Extract or Replicat group or a wildcard set of

groups (for example, * or fin*).

Note: The first time that Extract startsin a new Oracle GoldenGate

configuration, any open transactions will be skipped. Only

transactions that begin after Extract starts are captured.

Note: When starting Manager from the commandline or GGSCI on

Windows Server 2008 with User Account Control enabled, you will

receive a UAC prompt requesting you to allow or deny the program

to run.

Starting processes after instantiation is complete

9-2 Oracle GoldenGate for Oracle Installation and Setup Guide

To stop Extract or Replicat gracefully

STOP{EXTRACT | REPLICAT} group_name

Where group_nameis the name ofthe Extract or Replicat group or a wildcard set of

groups (for example, * or fin*).

To stop Replicat forcefully

STOPREPLICAT group_name!

The current transaction is aborted and the process stops immediately. Youcannot stop

Extract forcefully.

To kill a process that STOP cannot stop

KILL{EXTRACT | REPLICAT} group_name

Killing a process does not shut it down gracefully, and checkpointinformation can be

lost.

To control multiple processes at once

command ER wildcardspecification

Where:

■ command is: KILL, START, or STOP

■ wildcard specification is a wildcard specification for thenames of the process

groups that you want to affect with the command. The command affects every

Extract and Replicat group that satisfies the wildcard. Oracle GoldenGatesupports

up to 100,000 wildcard entries.

To delete an Extract group

1. Run GGSCI.

2. Stop the process.

STOPEXTRACT group_name

3. Issue the following command.

DELETEEXTRACT group_name!

The ! argument deletes all Extract groupsthat satisfy a wildcard without

prompting.

To delete a Replicat group

1. Stop the process.

STOPREPLICAT group_name

2. If using a checkpoint table for thisgroup, issue the following command from

GGSCI to log into the database.

DBLOGINUSERID user, PASSWORD password [encryption options]

Where:

■ USERID user, PASSWORD password, specifies database logincredentials.

■ encryption options is one of the options that encryptthe password.

3. Issue the following command todelete the group.

DELETEREPLICAT group_name

Starting processes after instantiation is complete

Controllingprocesses 9-3

Deleting a process group preserves the parameter file. You can create thesame group

again, using the same parameter file, or you can delete the parameter fileto remove

the group’s configuration permanently.

Note: For additional commands and options,see the Oracle

GoldenGate Windows and UNIX Reference Guide.

Starting processes after instantiation is complete

9-4 Oracle GoldenGate for Oracle Installation and Setup Guide

10

Managing the OracleDDL replication environment 10-1

10Managingthe Oracle DDL replication

environment

This chapter contains instructions for making changes to the databaseenvironment or

the Oracle GoldenGate environment when the Oracle GoldenGate DDL objectsstill

exist on the system.

For instructions on configuring Oracle GoldenGate DDL support, see theOracle

GoldenGate Windows and UNIX Administrator's Guide.

10.1 Enabling and disabling the DDL trigger

You can enable and disable the trigger that captures DDL operationswithout making

any configuration changes within Oracle GoldenGate. The following scriptscontrol

the DDL trigger.

■ ddl_disable: Disables the trigger. No further DDL operations are captured or

replicated after you disable the trigger.

■ ddl_enable: Enables the trigger. When you enable the trigger, Oracle GoldenGate

starts capturing current DDL changes, but does not capture DDL that was

generated while the trigger was disabled.

Before running these scripts, disable all sessions that ever issued DDL,including those

of the Oracle GoldenGate processes, SQL*Plus, business applications, andany other

software that uses Oracle. Otherwise the database might generate anORA-04021 error.

Do not use these scripts if you intend to maintain consistent DDL on thesource and

target systems.

10.2 Maintaining the DDL marker table

You can purge rows from the marker table at any time. It does not keep DDLhistory.

To purge the marker table, use the Manager parameter PURGEMARKERHISTORY. Manager

gets the name of the marker table from one of the following:

1. The name given with the MARKERTABLE parameter in the GLOBALS file, if specified.

2. The default name of GGS_MARKER.

PURGEMARKERHISTORYprovidesoptions to specify maximum and minimum lengths of

time to keep a row, based on the last modification date. For moreinformation, see the

Oracle GoldenGate Windows and UNIX Reference Guide.

Deleting the DDL marker table

10-2 Oracle GoldenGate for Oracle Installation and Setup Guide

10.3 Deleting the DDL marker table

Do not delete the DDL marker table unless you want to discontinuesynchronizing

DDL. The marker table and the DDL trigger are interdependent. An attemptto drop

the marker table fails if the DDL trigger is enabled. This is a safetymeasure to prevent

the trigger from becoming invalid and missing DDL operations. If youremove the

marker table, the following error is generated:

"ORA-04098:trigger 'SYS.GGS_DDL_TRIGGER_BEFORE' is invalid and failed

re-validation"

The proper way to remove an Oracle GoldenGate DDL object depends on yourplans

for the rest of the DDL environment. To choose the correct procedure, seeone of the

following:

■ "Restoring an existing DDL environment to a cleanstate" on page 10-4

■ "Removing the DDL objects from the system" on page 10-6

10.4 Maintaining the DDL history table

You can purge the DDL history table to control its size, but do socarefully. The DDL

history table maintains the integrity of the DDL synchronizationenvironment. Purges

to this table cannot be recovered through the Oracle GoldenGate interface.

1. To prevent any possibility of DDLhistory loss, make regular full backups of the

history table.

2. To ensure the recoverability ofpurged DDL, enable Oracle Flashback for the

history table. Set the flashback retention time well past the point whereit could be

needed. For example, if your full backups are at most one week old, retaintwo

weeks of flashback. Oracle GoldenGate can be positioned backward into the

flashback for reprocessing.

3. If possible, purge the DDL historytable manually to ensure that essential rows are

not purged accidentally. If you require an automated purging mechanism,use the

PURGEDDLHISTORYparameter inthe Manager parameter file. You can specify

maximum and minimum lengths of time to keep a row. For more information,see

the Oracle GoldenGate Windows and UNIX Reference Guide.

10.5 Deleting the DDL history table

Do not delete the DDL history table unless you want to discontinuesynchronizing

DDL. The history table contains a record of DDL operations that wereissued.

The history table and the DDL trigger are interdependent. An attempt todrop the

history table fails if the DDL trigger is enabled. This is a safetymeasure to prevent the

trigger from becoming invalid and missing DDL operations. If you removethe history

table, the following error is generated:

"ORA-04098:trigger 'SYS.GGS_DDL_TRIGGER_BEFORE' is invalid and failed

re-validation"

Note: Temporary tables created by OracleGoldenGate to increase

performance might be purged at the same time as the DDL history

table, according to the same rules. The names of these tables are

derived from the name of the history table, and their purging is

reported in the Manager report file. This is normal behavior.

Applying Oracle GoldenGate patches and upgrades when DDLsupport is enabled

Managing the OracleDDL replication environment 10-3

The proper way to remove an Oracle GoldenGate DDL object depends on yourplans

for the rest of the DDL environment. To choose the correct procedure, seeone of the

following:

■ "Restoring an existing DDL environment to a cleanstate" on page 10-4

■ "Removing the DDL objects from the system" on page 10-6

10.6 Purging the DDL trace file

To prevent the DDL trace file from consuming excessive disk space, run theddl_

cleartracescript on aregular basis. This script deletes the trace file, but Oracle

GoldenGate will create it again.

The default name of the DDL trace file is ggs_ddl_trace.log. It is in the USER_DUMP_

DEST directory of Oracle. The ddl_cleartrace script is in the Oracle GoldenGate

directory.

10.7 Applying database patches and upgradeswhen DDL support is

enabled

Database patches and upgrades usually invalidate the Oracle GoldenGate DDLtrigger

and other Oracle GoldenGate DDL objects. Before applying a database patch,do the

following.

1. Log in to SQL*Plus as a user thathas SYSDBA privileges.

2. Disable the Oracle GoldenGate DDLtrigger by running the ddl_disable script in

SQL*Plus.

3. Apply the patch.

4. Enable the DDL trigger by runningthe ddl_enable script in SQL*Plus.

To avoid recompile errors after the patch or upgrade, which are caused ifthe trigger is

not disabled before the procedure, consider adding calls to @ddl_disable and @ddl_

enable at the appropriate locations withinyour scripts.

10.8 Applying Oracle GoldenGate patches andupgrades when DDL

support is enabled

Note: Database upgrades and patchesgenerally operate on Oracle

objects. Because Oracle GoldenGate filters out those objects

automatically, DDL from those procedures is not replicated when

replication starts again.

Note: If there are instructions like thesein the release notes or

upgrade instructions that accompany a release, follow those instead of

these. Do not use this procedure for an upgrade from an Oracle

GoldenGate version that does not support DDL statements that are

larger than 30K (pre-version 10.4). To upgrade in that case, follow the

instructions in "Restoring an existing DDL environment to a clean

state" on page 10-4.

Restoring an existing DDL environment to a clean state

10-4 Oracle GoldenGate for Oracle Installation and Setup Guide

Follow these steps to apply a patch or upgrade to the DDL objects. This procedure

may or may not preserve the current DDL synchronization configuration,depending

on whether the new build requires a clean installation.

1. Run GGSCI. Keep the session open forthe duration of this procedure.

2. Stop Extract to stop DDL capture.

STOPEXTRACT group

3. Stop Replicat to stop DDLreplication.

STOPREPLICAT group

4. Download or extract the patch orupgrade files according to the instructions

provided by Oracle GoldenGate.

5. Change directories to the OracleGoldenGate installation directory.

6. Log in to SQL*Plus as a user thathas SYSDBA privileges.

7. Disconnect all sessions that everissued DDL, including those of Oracle

GoldenGate processes, SQL*Plus, business applications, and any othersoftware

that uses Oracle. Otherwise the database might generate an ORA-04021error.

8. Run the ddl_disable script to disable the DDL trigger.

9. Run the ddl_setup script. You are prompted for thename of the Oracle

GoldenGate DDL schema. If you changed the schema name, use the new one.

10. Run the ddl_enable.sql script to enable the DDL trigger.

11. In GGSCI, start Extract to resumeDDL capture.

STARTEXTRACT group

12. Start Replicat to start DDLreplication.

START REPLICATgroup

10.9 Restoring an existing DDL environment toa clean state

Follow these steps to completely remove, and then reinstall, the OracleGoldenGate

DDL objects. This procedure creates a new DDL environment and removes any

current DDL history.

1. If you are performing this procedurein conjunction with the installation of a new

Oracle GoldenGate version, download and install the Oracle GoldenGatefiles, and

create or update process groups and parameter files as necessary.

2. (Optional) To preserve thecontinuity of source and target structures, stop DDL

activities and then make certain that Replicat finished processing all ofthe DDL

and DML data in the trail. To determine when Replicat is finished, issuethe

following command until you see a message that there is no more data toprocess.

INFOREPLICAT group

Note: Due to object interdependencies, allobjects must be removed

and reinstalled in this procedure.

Restoring an existing DDL environment to a clean state

Managing the OracleDDL replication environment 10-5

3. Run GGSCI.

4. Stop Extract to stop DDL capture.

STOPEXTRACT group

5. Stop Replicat to stop DDLreplication.

STOPREPLICAT group

6. Change directories to the OracleGoldenGate installation directory.

7. Log in to SQL*Plus as a user thathas SYSDBA privileges.

8. Disconnect all sessions that everissued DDL, including those of Oracle

GoldenGate processes, SQL*Plus, business applications, and any othersoftware

that uses Oracle. Otherwise the database might generate an ORA-04021error.

9. Run the ddl_disable script to disable the DDL trigger.

10. Run the ddl_remove script to remove the OracleGoldenGate DDL trigger, the

DDL history and marker tables, and other associated objects. This scriptproduces

a ddl_remove_spool.txtfile that logsthe script output and a ddl_remove_set.txt

file that logs environment settings in case they are needed for debugging.

11. Run the marker_remove script to remove the OracleGoldenGate marker support

system. This script produces a marker_remove_spool.txt file that logs the script

output and a marker_remove_set.txtfile that logsenvironment settings in case

they are needed for debugging.

12. If you are changing the DDL schemafor this installation, grant the following

permission to the Oracle GoldenGate schema.

GRANTEXECUTE ON utl_file TO schema;

13. If you are changing the DDL schemafor this installation, the schema’s default

tablespace must be dedicated to that schema; do not allow any other schemato

share it. AUTOEXTENDmust be set to ON for this tablespace, and thetablespace must

be sized to accommodate the growth of the GGS_DDL_HIST and GGS_MARKER tables.

The GGS_DDL_HIST table, in particular, will grow inproportion to overall DDL

activity.

Note: Instead of using INFO REPLICAT, you can use the

EVENTACTIONSoption of TABLE and MAP to stop the Extract and Replicat

processes after the DDL and DML has been processed.

Note: If the DDL tablespace fills up,Extract stops capturing DDL.

To cause user DDL activity to fail when that happens, edit the

params.sqlscript and setthe ddl_fire_error_in_triggerparameter

to TRUE. Stopping user DDL gives you timeto extend the tablespace

size and prevent the loss of DDL capture. Managing tablespace sizing

this way, however, requires frequent monitoring of the business

applications and Extract to avoid business disruptions. Instead, Oracle

recommends that you size the tablespace appropriately and set

AUTOEXTENDto ON so that the tablespace does not fillup.

Removing the DDL objects from the system

10-6 Oracle GoldenGate for Oracle Installation and Setup Guide

14. If you are changing the DDL schemafor this installation, edit the GLOBALS file and

specify the new schema name with the following parameter.

GGSCHEMAschema_name

15. Run the marker_setup script to reinstall the OracleGoldenGate marker support

system. You are prompted for the name of the Oracle GoldenGate schema.

16. Run the ddl_setup script. You are prompted for thename of the Oracle

GoldenGate DDL schema.

17. Run the role_setup script to recreate the OracleGoldenGate DDL role.

18. Grant the role to all OracleGoldenGate users under which the following Oracle

GoldenGate processes run: Extract, Replicat, GGSCI, and Manager. You might

need to make multiple grants if the processes have different user names.

19. Run the ddl_enable.sql script to enable the DDL trigger.

10.10 Removing the DDL objects from thesystem

This procedure removes the DDL environment and removes the history thatmaintains

continuity between source and target DDL operations.

1. Run GGSCI.

2. Stop Extract to stop DDL capture.

STOPEXTRACT group

3. Stop Replicat to stop DDLreplication.

STOPREPLICAT group

4. Change directories to the OracleGoldenGate installation directory.

5. Run SQL*Plus and log in as a userthat has SYSDBA privileges.

6. Disconnect all sessions that everissued DDL, including those of Oracle

GoldenGate processes, SQL*Plus, business applications, and any othersoftware

that uses Oracle. Otherwise the database might generate an ORA-04021error.

7. Run the ddl_disable script to disable the DDL trigger.

8. Run the ddl_remove script to remove the OracleGoldenGate DDL trigger, the

DDL history and marker tables, and the associated objects. This scriptproduces a

ddl_remove_spool.txtfile that logsthe script output and a ddl_remove_set.txt

file that logs current user environment settings in case they are neededfor

debugging.

9. Run the marker_remove script to remove the OracleGoldenGate marker support

system. This script produces a marker_remove_spool.txt file that logs the script

WARNING: Do not edit any otherparameters in params.sql except

if you need to follow documented instructionsto change certain

object names.

Note: Due to object interdependencies, allobjects must be removed.

Removing the DDL objects from the system

Managing the OracleDDL replication environment 10-7

output and a marker_remove_set.txtfile that logsenvironment settings in case

they are needed for debugging.

Removing the DDL objects from the system

10-8 Oracle GoldenGate for Oracle Installation and Setup Guide

11

Uninstalling OracleGoldenGate 11-1

11UninstallingOracle GoldenGate

This procedure assumes that you no longer need the data in the OracleGoldenGate

trails, and that you no longer need to preserve the current OracleGoldenGate

environment. To preserve your current environment and data, make a backupof the

Oracle GoldenGate directory and all subdirectories before starting thisprocedure.

11.1 Stopping processes

This procedure stops the Extract and Replication processes. Leave Managerrunning

until directed to stop it.

On all systems:

1. Run the command shell.

2. Log on as the system administratoror as a user with permission to issue Oracle

GoldenGate commands and delete files and directories from the operatingsystem.

3. Change directories to the OracleGoldenGate installation directory.

4. Run GGSCI.

5. Stop all Oracle GoldenGateprocesses.

STOP ER*

6. Stop the Manager process.

STOPMANAGER

11.2 Removing the DDL environment

This procedure removes all of the Oracle GoldenGate DDL objects from theDDL

schema on a source system.

1. Log in to SQL*Plus as a user thathas SYSDBA privileges.

2. Disconnect all sessions that everissued DDL, including those of Oracle

GoldenGate processes, SQL*Plus, business applications, and any othersoftware

that uses Oracle. Otherwise the database might generate an ORA-04021error.

3. Run the ddl_disable script to disable the DDL trigger.

4. Run the ddl_remove script to remove the OracleGoldenGate DDL trigger, the

DDL history and marker tables, and other associated objects. This scriptproduces

Note: Follow these sections in the orderthey are presented.

Removing database objects

11-2 Oracle GoldenGate for Oracle Installation and Setup Guide

a ddl_remove_spool.txtfile that logsthe script output and a ddl_remove_set.txt

file that logs environment settings in case they are needed for debugging.

5. Run the marker_remove script to remove the OracleGoldenGate marker support

system. This script produces a marker_remove_spool.txt file that logs the script

output and a marker_remove_set.txtfile that logsenvironment settings in case

they are needed for debugging.

11.3 Removing database objects

Follow these instructions to remove Oracle GoldenGate objects that areconfigured

within an Oracle database. Specific steps and commands may not apply toyour

configuration.

On a source system:

Review the GGSCI commands in this procedure before logging in with DBLOGIN.

Special privileges may be required.

1. Make certain all Extract andReplicat processes are stopped.

2. Log into the database with the DBLOGIN (or the MININGDBLOGIN command if you

need to remove a database logmining server from a downstream mining

database).

[MINING]DBLOGINUSERID user, PASSWORD password [encryption options]

3. Run GGSCI.

4. In GGSCI, run any or all of thefollowing commands, depending on your

configuration:

■ Disable schema-level supplemental logging (wildcards notallowed):

DELETESCHEMATRANDATA schema

■ Disable table-level supplemental logging.

DELETETRANDATA schema.*

■ (Bi-directional configuration) Remove the Oracle tracetable.

DELETETRACETABLE schema.table

■ (Classic capture configuration) Disable log retention andremove the

underlying Oracle Streams capture process. DBLOGIN requires privileges

shown in Table 6–3 on on page 6-10.

UNREGISTEREXTRACT group LOGRETENTION

■ (Integrated capture configuration) Remove the databaselogmining server

from an Oracle mining database. [MINING]DBLOGIN requires privileges granted

in the dbms_goldengate_auth.grant_admin_privilegeprocedure.

DELETEEXTRACT group

UNREGISTEREXTRACT group DATABASE

On any system where a Replicat checkpointexists:

1. Make certain Replicat is stopped.

2. Log into the database with the DBLOGIN command.

DBLOGINUSERID user, PASSWORD password [encryption options]

Removing the Oracle GoldenGate files

Uninstalling OracleGoldenGate 11-3

3. Remove the Replicat checkpoint tableby running the DELETECHECKPOINTTABLE

command.

DELETECHECKPOINTTABLE schema.table

11.4 (Windows) Removing Oracle GoldenGateWindows components

This procedure removes Oracle GoldenGate as a Windows cluster resourcefrom a

source or target Windows system, stops Oracle GoldenGate events from being

reported to the Windows Event Manager, and removes the Manager service.Perform

these steps on source and target systems.

1. Log on as the system administratoror as a user with permission to issue Oracle

GoldenGate commands and to delete files and directories from the operating

system.

2. (Cluster) Working from the node inthe cluster that owns the cluster group that

contains the Manager resource, run GGSCI and make certain that all Extractand

Replicat processes are stopped. Stop any that are running.

STATUSER *

STOP ER*

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

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

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

command console.

6. Change directories to the OracleGoldenGate installation directory.

7. Run the INSTALL utility with thefollowing syntax.

installdeleteevents deleteservice

8. Delete the CATEGORY.DLL and GGSMSG.DLL files from the Windows SYSTEM32 folder.

9. (Cluster) Move the cluster group tothe next node in the cluster, and repeat from

step 5.

11.5 Removing the Oracle GoldenGate files

Perform these steps on all systems to remove the Oracle GoldenGateinstallation

directory.

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

STATUSMANAGER

STATUSER *

STOPMANAGER

STOP ER*

2. Exit GGSCI.

EXIT

3. Remove the Oracle GoldenGateinstallation directory.

Removing the Oracle GoldenGate files

11-4 Oracle GoldenGate for Oracle Installation and Setup Guide

A

Configuring adownstream mining database for integrated capture A-1

AConfiguringa downstream mining database

for integrated capture

This chapter contains instructions for preparing a downstream Oraclemining database

to support Extract in integrated capture mode.

■ Evaluating capture options for a downstream deployment

■ Preparing the Source Database for Downstream Deployment

■ Preparing the downstream mining database

For more information about parameters used in these procedures, seeOracle®

Database Reference 11g Release 2 (11.2) and Oracle Data Guard Concepts and

Administration 11g Release 2 (11.2).

For more information about integrated capture, see "Deciding which capturemethod

to use" on page 4-3.

For examples of the downstream mining configuration, see "Example configuration of

downstream mining database for integrated capture" on page B-1.

11.6 Evaluating capture options for adownstream deployment

Downstream deployment allows you to offload the source database. Thesource

database ships its redo logs to a downstream database, and Extract usesthe logmining

server at the downstream database to mine the redo logs. A downstreammining

database can accept both archived logs and online redo logs from a sourcedatabase.

Multiple source databases can send their redo data to a single downstreamdatabase;

however the downstream mining database can accept onlineredo logs fromonly one

of those source databases. The rest of the source databases must shiparchived logs.

When online logs are shipped to the downstream database, real-timecapture by Extract

is possible. Changes are captured as though Extract is reading from thesource logs. In

order to accept online redo logs from a source database, the downstreammining

database must have standby redo logs configured.

When using a downstream mining configuration, the source database andmining

database must be of the same platform. For example, if the source databaseis running

on Linux 64-bit, the downstream database must also be on the Linux 64-bitplatform.

11.7 Preparing the Source Database forDownstream Deployment

This section guides you in the process of:

■ Creating the source user account

Preparing the Source Database for Downstream Deployment

A-2 Oracle GoldenGate for Oracle Installation and Setup Guide

■ Configuring redo transport from a source to thedownstream mining database

11.7.1 Creating the source user account

There must be an Extract user on the source database. Extract uses thecredentials of

this user to do metadata queries and to fetch column values as needed fromthe source

database. The source user is specified by the USERID parameter.

You may have created this user already and assigned the requiredprivileges if you

followed the procedure in "Assigning a database user for OracleGoldenGate" on

page 4-6. If you did not create this user, create it now and assign thefollowing

privileges:

1. Grant the appropriate privileges forExtract to operate in integrated capture mode.

■ For Oracle 11.2.0.3 and above, use the dbms_goldengate_auth.grant_admin_

privilegeprocedure.

■ For earlier Oracle releases that do not have the dbms_goldengate_auth.grant_

admin_privilegeprocedure, usethe dbms_streams_auth.grant_admin_

privilegeprocedure.

2. Grant SELECT privilege on the V_$DATABASE view to the downstream mining user.

GRANTSELECT ON V_$DATABASE TO user;

3. Assign the appropriate basic userprivileges that are listed in "Assigning a

database user for Oracle GoldenGate" on page 4-6.

11.7.2 Configuring redo transport from asource to the downstream mining database

Complete the following steps to set up the transfer of redo log files froma source

database to the downstream mining database, and to prepare the downstreammining

database to accept these redo log files.

These instructions take into account the requirements to ship redo frommultiple

sources, if required. You configure an Extract process for each of thosesources. The

following summarizes the rules for supporting multiple sources sendingredo to a

single downstream mining database:

■ Only one source database can be configured to send onlineredo to thestandby

redo logs at the downstream mining database. The log_archive_dest_n setting

for this source database should not have a TEMPLATE clause.

■ Source databases that are not sending online redo to the standbyredo logs of the

downstream mining database must have a TEMPLATE clause specified in the log_

archive_dest_nparameter.

■ Each of the source databases that sends redo to the downstreammining database

must have a unique DBID. You can select the DBID column from the v$database

view of these source databases to ensure that the DBIDs are unique.

Note: The archived logs shipped from thesource databases are

called foreign archived logs. You must not use the recovery areaat the

downstream mining database to store foreign archived logs. Such a

configuration is not supported by Integrated Capture.

Preparing the Source Database for Downstream Deployment

Configuring adownstream mining database for integrated capture A-3

To configure redo transport

1. Configure Oracle Net so that eachsource database can communicate with the

mining database. For instructions, see Oracle® Database NetServices

Administrator's Guide 11g Release 2 (11.2).

2. Configure authentication at eachsource database and at the downstream mining

database to support the transfer of redo data. Redo transport sessions are

authenticated using either the Secure Sockets Layer (SSL) protocol or aremote

login password file. If a source database has a remote login passwordfile, copy it

to the appropriate directory of the mining database system. The passwordfile

must be the same at all source databases, and at the mining database. Formore

information about authentication requirements for redo transport, see Preparing

the Primary Database for Standby DatabaseCreation in Oracle® Data Guard Concepts

and Administration 11g Release 2 (11.2).

3. At each source database, configureone LOG_ARCHIVE_DEST_ninitialization

parameter to transmit redo data to the downstream mining database. Set the

attributes of this parameter as shown in one of the following examples,depending

on whether real-time or archived-log-only capture mode is to be used.

■ Example for real-time capture at the downstream logminingserver, where the

source database sends its online redo logs to the downstream database:

ALTERSYSTEM

SETLOG_ARCHIVE_DEST_2='SERVICE=DBMSCAP.EXAMPLE.COM ASYNC NOREGISTER

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)DB_UNIQUE_NAME=dbmscap'

■ Example for archived-log-only capture at the downstreamlogmining server:

ALTERSYSTEM SET

LOG_ARCHIVE_DEST_2='SERVICE=DMBSCAP.EXAMPLE.COMASYNC NOREGISTER

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)

TEMPLATE=/usr/oracle/log_for_dbms1/dbms1_arch_%t_%s_%r.log

DB_UNIQUE_NAME=dbmscap'

4. At the source database, set a valueof ENABLE for the LOG_ARCHIVE_DEST_STATE_n

initialization parameter that corresponds with the LOG_ARCHIVE_DEST_n parameter

that corresponds to the destination for the downstream mining database, asshown

in the following example.

ALTERSYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE

5. At the source database, and at thedownstream mining database, set the DG_CONFIG

attribute of the LOG_ARCHIVE_CONFIG initialization parameter to include the DB_

UNIQUE_NAMEof the sourcedatabase and the downstream database, as shown in

the following example.

ALTERSYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbms1,dbmscap)'

Note: When using an archived-log-onlydownstream mining

database, you must specify a value for the TEMPLATE attribute. Oracle

also recommends that you use the TEMPLATE clause in thesource

databases so that the log files from all remote source databases are

kept separated from the local database log files, and from each other.

Preparing the downstream mining database

A-4 Oracle GoldenGate for Oracle Installation and Setup Guide

11.8 Preparing the downstream mining database

■ Creating the downstream mining user account

■ Configuring the mining database to archive local redo logfiles

■ Preparing a downstream mining database for real-timecapture

11.8.1 Creating the downstream mining useraccount

When using a downstream mining configuration, there must be an Extractmining

user on the downstream database. The mining Extract process uses thecredentials of

this user to interact with the downstream logmining server. The downstreammining

user is specified by the TRANLOGOPTIONS parameter with the MININGUSER option. Create

this user at the downstream mining database and assign the following privileges:

1. Grant the appropriate privileges forthe downstream mining user to operate in

integrated capture mode by executing the dbms_goldengate_auth.grant_admin_

privilegeprocedure.

2. Grant SELECT privilege on the V_$DATABASE view to the downstream mining user.

GRANTSELECT ON V_$DATABASE TO user;

3. Assign the downstream mining userthe basic privileges that are listed in

"Assigning a database user for Oracle GoldenGate" on page 4-6.

11.8.2 Configuring the mining database toarchive local redo log files

This procedure configures the downstream mining database to archive redodata in its

online redo logs. These are redo logs that are generated at the downstreammining

database.

Archiving must be enabled at the downstream mining database if you want torun

Extract in real-time integrated capture mode, but it is also recommendedfor

archive-log-only capture. Extract in integrated capture mode writes stateinformation

in the database. Archiving and regular backups will enable you to recoverthis state

information in case there are disk failures or corruption at thedownstream mining

database.

To archive local redo log files

1. Alter the downstream mining databaseto be in archivelog mode. You can do this

by issuing the following DDL.

STARTUPMOUNT;

ALTERDATABASE ARCHIVELOG;

ALTERDATABASE OPEN;

2. At the downstream mining database,set the first archive log destination in the

LOG_ARCHIVE_DEST_ninitializationparameter as shown in the following example:

ALTERSYSTEM SET

LOG_ARCHIVE_DEST_1='LOCATION=/home/arc_dest/local

VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE)'

Alternatively, you can use a command like this example:

ALTERSYSTEM SET

LOG_ARCHIVE_DEST_1='LOCATION="USE_DB_RECOVERY_FILE_DEST"valid_for=(ONLINE_

LOGFILE,PRIMARY_ROLE)'

Preparing the downstream mining database

Configuring adownstream mining database for integrated capture A-5

3. Enable the local archivedestination.

ALTERSYSTEM SET LOG_ARCHIVE_DEST_STATE_1=ENABLE

For more information about these initialization parameters, see OracleData Guard

Concepts and Administration 11g Release 2(11.2).

11.8.3 Preparing a downstream mining databasefor real-time capture

This procedure is only required if you want to use real-time capture at adownstream

mining database. It is not required to use archived-log-only capture mode.To use

real-time capture, it is assumed that the downstream database has alreadybeen

configured to archive its local redo data as shown in "Configuring the miningdatabase

to archive local redo log files" on page A-4.

11.8.3.1 Create the standby redo log files

The following steps outline the procedure for adding standby redo logfiles to the

downstream mining database. The following summarizes the rules forcreating the

standby redo logs:

■ Each standby redo log file must be at least as large asthe largest redo log file of

the redo source database. For administrative ease, Oracle recommends thatall

redo log files at source database and the standby redo log files at the downstream

mining database be of the same size.

■ The standby redo log must have at least one more redo loggroup than the redo

log at the source database, for each redo thread at the source database.

The specific steps and SQL statements that are required to add standbyredo log files

depend on your environment. See Oracle Data Guard Conceptsand Administration 11g

Release 2 (11.2) for detailed instructions aboutadding standby redo log files to a

database.

To create the standby redo log files

1. In SQL*Plus, connect to the sourcedatabase as an administrative user.

2. Determine the size of the source logfile. Make note of the results.

Note: The online redo logs generated bythe downstream mining

database can be archived to a recovery area. However, you must not

use the recovery area of the downstream mining database to stage

foreign archived logs or to archive standby redo logs. For information

about configuring a fast recovery area, see Oracle® Database Backup

and Recovery User's Guide 11g Release 2(11.2).

Note: If there will be multiple sourcedatabases sending redo to a

single downstream mining database, only one of those sources can

send redo to the standby redo logs of the mining database. An Extract

process that mines the redo from this source database can run in

real-time mode. All other source databases must send only their

archived logs to the downstream mining database, and the Extracts

that read this data must be configured to run in archived-log-only

mode.

Preparing the downstream mining database

A-6 Oracle GoldenGate for Oracle Installation and Setup Guide

SELECTBYTES FROM V$LOG;

3. Determine the number of online logfile groups that are configured on the source

database. Make note of the results.

SELECTCOUNT(GROUP#) FROM V$LOG;

4. Connect to the downstream miningdatabase as an administrative user.

5. Add the standby log file groups tothe mining database. The standby log file size

must be at least the size of the source log file size. The number ofstandby log file

groups must be at least one more than the number of source online log filegroups.

This applies to each instance (thread) in a RAC installation. So if youhave "n"

threads at the source database, each having "m" redo log groups,you should

configure n*(m+1) redo log groups at the downstream mining database.

The following example shows three standby log groups.

ALTERDATABASE ADD STANDBY LOGFILE GROUP 3

('/oracle/dbs/slog3a.rdo','/oracle/dbs/slog3b.rdo') SIZE 500M;

ALTERDATABASE ADD STANDBY LOGFILE GROUP 4

('/oracle/dbs/slog4.rdo','/oracle/dbs/slog4b.rdo') SIZE 500M;

ALTERDATABASE ADD STANDBY LOGFILE GROUP 5

('/oracle/dbs/slog5.rdo','/oracle/dbs/slog5b.rdo') SIZE 500M;

6. Confirm that the standby log filegroups were added successfully.

SELECTGROUP#, THREAD#, SEQUENCE#, ARCHIVED, STATUS

FROMV$STANDBY_LOG;

The output should be similar to the following:

GROUP#THREAD# SEQUENCE# ARC STATUS

-------------------- ---------- --- ----------

3 0 0YES UNASSIGNED

4 0 0YES UNASSIGNED

5 0 0YES UNASSIGNED

7. Ensure that log files from thesource database are appearing in the location that is

specified in the LOCATION attribute ofthe local LOG_ARCHIVE_DEST_nthat you set.

You might need to switch the log file at the source database to see filesin the

directory.

11.8.3.2 Configure the database to archivestandby redo log files locally

This procedure configures the downstream mining database to archive thestandby

redo logs that receive redo data from the online redo logs of the sourcedatabase. Keep

in mind that foreign archived logs should not be archived in the recoveryarea of the

downstream mining database.

To archive standby redo logs locally

1. At the downstream mining database,set the second archive log destination in the

LOG_ARCHIVE_DEST_ninitializationparameter as shown in the following example.

ALTERSYSTEM SET

LOG_ARCHIVE_DEST_2='LOCATION=/home/arc_dest/srl_dbms1

VALID_FOR=(STANDBY_LOGFILE,PRIMARY_ROLE)'

Oracle recommends that foreign archived logs (logs from remote source

databases) be kept separate from local mining database log files, and fromeach

other. You must not use the recovery area of the downstream miningdatabase to

Preparing the downstream mining database

Configuring adownstream mining database for integrated capture A-7

stage foreign archived logs. For information about configuring a fastrecovery

area, see Oracle® Database Backup and Recovery User's Guide 11gRelease 2 (11.2).

2. Enable the LOG_ARCHIVE_DEST_2 parameter you set in the previousstep as shown

in the following example.

ALTERSYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE

For more information about these initialization parameters, see OracleData Guard

Concepts and Administration 11g Release 2(11.2).

Note: If you are accepting redo generatedby another database in the

standby redo logs of a downstream mining database, you must

configure log_archive_dest_2for yourstandby redo logs as

described above.

Preparing the downstream mining database

A-8 Oracle GoldenGate for Oracle Installation and Setup Guide

B

Exampleconfiguration of downstream mining database for integrated capture B-1

BExampleconfiguration of downstream

mining database for integrated capture

This appendix contains examples for preparing a downstream Oracle miningdatabase

to support Extract in integrated capture mode. For more information about

configuring a downstream mining database, see "Configuring a downstreammining

database for integrated capture" on page A-1.

11.9 Example 1: Capturing from one sourcedatabase in real-time mode

This example captures changes from source database DBMS1 by deploying an

integrated capture session at a downstream mining database DBMSCAP. Thisassumes

that the following users exist:

■ User GGADM1 in DBMS1 whose credentials Extract will useto fetch data and

metadata from DBMS1. User GGADM1 has select privileges on V_$DATABASE view

at the source database. It is assumed that the DBMS_GOLDENGATE_AUTH.GRANT_

ADMIN_PRIVILEGE()procedure wascalled to grant appropriate privileges to this

user at the source database.

■ User GGADMCAP in DBMSCAP whose credentials Extract willuse to retrieve

logical change records from the logmining server at the downstream mining

database DBMSCAP. It is assumed that the DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_

PRIVILEGE()procedure wascalled to grant appropriate privileges to this user at

the mining database. User GGADMCAP has select privileges on V_$DATABASE

view at the downstream mining database.

11.9.1 Prepare the mining database to archiveits local redo

1. The downstream mining database mustbe in archivelog mode. You can do this by

issuing the following DDL.

STARTUPMOUNT;

ALTERDATABASE ARCHIVELOG;

ALTERDATABASE OPEN;

2. At the downstream mining database,set log_archive_dest_1to archivelocal

redo.

Note: This example assumes that youcreated the necessary standby

redo log files as shown in "Configuring a downstream mining

database for integrated capture" on page A-1.

Example 1: Capturing from one source database inreal-time mode

B-2 Oracle GoldenGate for Oracle Installation and Setup Guide

ALTERSYSTEM SET

LOG_ARCHIVE_DEST_1='LOCATION=/home/arc_dest/local

VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE)'

3. Enable log_archive_dest_1.

ALTERSYSTEM SET LOG_ARCHIVE_DEST_STATE_1=ENABLE

11.9.2 Prepare the mining database to archiveredo received in standby redo logs from

the source database

1. At the downstream mining database,set log_archive_dest_2as shown in the

following example.

ALTERSYSTEM SET

LOG_ARCHIVE_DEST_2='LOCATION=/home/arc_dest/srl_dbms1

VALID_FOR=(STANDBY_LOGFILE,PRIMARY_ROLE)'

2. Enable log_archive_dest_2 as shown in the following example.

ALTERSYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE

3. Set DG_CONFIG at the downstream mining database.

ALTERSYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbms1,dbmscap)'

11.9.3 Prepare the source database to sendredo to the mining database

1. Make sure that the source databaseis running with the required compatibility.

selectname, value from v$parameter where name = 'compatible';

NAMEVALUE

------------------------------

compatible11.1.0.7.0

The minimum compatibility setting required from integrated capture is10.2.0.0.0.

2. Set DG_CONFIG at the source database.

ALTERSYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbms1,dbmscap)';

3. Set up redo transport at the sourcedatabase.

ALTERSYSTEM

SETLOG_ARCHIVE_DEST_2='SERVICE=DBMSCAP.EXAMPLE.COM ASYNC OPTIONAL NOREGISTER

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)DB_UNIQUE_NAME=dbmscap';

4. Enable the downstream destination.

ALTERSYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

11.9.4 Set up integrated capture (ext1) onDBMSCAP

1. Register Extract with the downstreammining database.

GGSCI>DBLOGIN USERID ggadm1@dbms1 PASSWORD ggadm1pw

GGSCI>MININGDBLOGIN USERID ggadmcap@dbmscap PASSWORD ggadmcappw

GGSCI>REGISTER EXTRACT ext1 DATABASE

2. Create Extract at the downstreammining database.

GGSCI>ADD EXTRACT ext1 INTEGRATED TRANLOG BEGIN NOW

Example 2: Capturing from multiple sources inarchive-log-only mode

Exampleconfiguration of downstream mining database for integrated capture B-3

3. Edit Extract parameter file ext1.prm. The following lines must bepresent to take

advantage of real-time capture.

USERIDggadm1@dbms1 PASSWORD ggadm1pw

TRANLOGOPTIONSMININGUSER ggadmcap@dbmscap MININGPASSWORD ggadmcappw

TRANLOGOPTIONSINTEGRATEDPARAMS (downstream_real_time_mine Y)

4. Start Extract.

GGSCI>START EXTRACT ext1

11.10 Example 2: Capturing from multiplesources in archive-log-only

mode

The following example captures changes from database DBMS1 and DBMS2 by

deploying an integrated capture session at a downstream mining databaseDBMSCAP.

It assumes the following users:

■ User GGADM1 in DBMS1 whose credentials Extract will useto fetch data and

metadata from DBMS1. User GGADM1 has select privileges on v_$database at

DBMS1. It is assumed that the DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE()

procedure was called to grant appropriate privileges to this user atDBMS1.

■ User GGADM2 in DBMS2 whose credentials Extract will useto fetch data and

metadata from DBMS2. User GGADM2 has select privileges on v_$database in

DBMS2. It is assumed that the DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE()

procedure was called to grant appropriate privileges to this user atDBMS2.

■ User GGADMCAP in DBMSCAP whose credentials Extract willuse to retrieve

logical change records from the logmining server at the downstream mining

database. It is assumed that the DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_

PRIVILEGE()procedure wascalled to grant appropriate privileges to this user at

the downstream mining database DBMSCAP. User GGADMCAP has select

privileges on v_$databaseat DBMSCAP.

This procedure also assumes that the downstream mining database isconfigured in

archivelog mode.

11.10.1 Prepare the mining database toarchive its local redo

1. The downstream mining database mustbe in archivelog mode. You can do this by

issuing the following DDL.

STARTUPMOUNT;

ALTERDATABASE ARCHIVELOG;

ALTERDATABASE OPEN;

2. At the downstream mining database,set log_archive_dest_1to archivelocal

redo.

ALTERSYSTEM SET

LOG_ARCHIVE_DEST_1='LOCATION=/home/arc_dest/local

VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE)'

Note: You can create multiple Extractsrunning in real-time

integrated capture mode in the downstream mining database, as long

as they all are capturing data from the same source database, such as

capturing changes for database DBMS1 in the preceding example.

Example 2: Capturing from multiple sources inarchive-log-only mode

B-4 Oracle GoldenGate for Oracle Installation and Setup Guide

3. Enable log_archive_dest_1.

ALTERSYSTEM SET LOG_ARCHIVE_DEST_STATE_1=ENABLE

11.10.2 Prepare the mining database toarchive redo from the source database

Set DG_CONFIG at the downstream mining database.

ALTERSYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbms1,dbms2, dbmscap)'

11.10.3 Prepare the first source database tosend redo to the mining database

1. Make certain that DBMS1 sourcedatabase is running with the required

compatibility.

selectname, value from v$parameter where name = 'compatible';

NAMEVALUE

------------------------------

compatible11.1.0.7.0

The minimum compatibility setting required from integrated capture is10.2.0.0.0.

2. Set DG_CONFIG at DBMS1 source database.

ALTERSYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbms1, dbmscap)';

3. Set up redo transport at DBMS1source database. The TEMPLATE clause is

mandatory if you want to send redo data directly to foreign archived logsat the

downstream mining database.

ALTERSYSTEM

SETLOG_ARCHIVE_DEST_2='SERVICE=DBMSCAP.EXAMPLE.COM ASYNC OPTIONAL NOREGISTER

TEMPLATE='/usr/orcl/arc_dest/dbms1/dbms1_arch_%t_%s_%r.logVALID_FOR=(ONLINE_

LOGFILES,PRIMARY_ROLE)DB_UNIQUE_NAME=dbmscap';

4. Enable the downstream destination.

ALTERSYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

11.10.4 Prepare the second source database tosend redo to the mining database

1. Make sure that DBMS2 source databaseis running with the required

compatibility.

selectname, value from v$parameter where name = 'compatible';

NAMEVALUE

------------------------------

compatible10.2.0.3.0

The minimum compatibility setting required from integrated capture is10.2.0.0.0.

2. Set DG_CONFIG at DBMS2 source database.

ALTERSYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=( dbms2, dbmscap)';

3. Set up redo transport at DBMS2source database. The TEMPLATE clause is

mandatory if you want to send redo data directly to foreign archived logsat the

downstream mining database.

ALTERSYSTEM

SETLOG_ARCHIVE_DEST_2='SERVICE=DBMSCAP.EXAMPLE.COM ASYNC OPTIONAL NOREGISTER

Example 2: Capturing from multiple sources in archive-log-onlymode

Exampleconfiguration of downstream mining database for integrated capture B-5

TEMPLATE='/usr/orcl/arc_dest/dbms2/dbms2_arch_%t_%s_%r.logVALID_FOR=(ONLINE_

LOGFILES,PRIMARY_ROLE)DB_UNIQUE_NAME=dbmscap';

4. Enable the downstream destination.

ALTERSYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

11.10.5 Set up Extracts at the downstreammining database

These steps set up Extract at the downstream database to capture from thearchived

logs sent by DBMS1 and DBMS2.

11.10.5.1 Set up Extract (ext1) to capturechanges from archived logs sent by

DBMS1

Perform the following steps on the DBMSCAP downstream mining database.

1. Register Extract with DBMSCAP forthe DBMS1 source database.

GGSCI>DBLOGIN USERID ggadm1@dbms1 PASSWORD ggadm1pw

GGSCI>MININGDBLOGIN USERID ggadmcap@dbmscap PASSWORD ggadmcappw

GGSCI>REGISTER EXTRACT ext1 DATABASE

2. Add Extract at the mining databaseDBMSCAP.

GGSCI>ADD EXTRACT ext1 INTEGRATED TRANLOG BEGIN NOW

3. Edit the Extract parameter file ext1.prm.

USERIDggadm1@dbms1 PASSWORD ggadm1pw

TRANLOGOPTIONSMININGUSER ggadmcap@dbmscap, MININGPASSWORD ggadmcappw

TRANLOGOPTIONSINTEGRATEDPARAMS (downstream_real_time_mine N)

4. Start Extract.

GGSCI>START EXTRACT ext1

11.10.5.2 Set up Extract (ext2) to capturechanges from archived logs sent by

DBMS2

Perform the following steps on the downstream DBMSCAP mining database.

1. Register Extract with the miningdatabase for source database DBMS2.

GGSCI>DBLOGIN USERID ggadm2@dbms2, PASSWORD ggadm2pw

GGSCI>MININGDBLOGIN USERID ggadmcap@dbmscap, PASSWORD ggadmcappw

GGSCI>REGISTER EXTRACT ext2 DATABASE

2. Create Extract at the miningdatabase.

GGSCI>ADD EXTRACT ext2 INTEGRATED TRANLOG, BEGIN NOW

3. Edit the Extract parameter file ext2.prm.

USERIDggadm2@dbms2, PASSWORD ggadm2pwd

TRANLOGOPTIONSMININGUSER ggadmcap@dbmscap, MININGPASSWORD ggadmcappw

TRANLOGOPTIONSINTEGRATEDPARAMS (downstream_real_time_mine N)

4. Start Extract.

GGSCI>START EXTRACT ext2

Example 3: Capturing from multiple sources with mixedreal-time and archive-log-only mode

B-6 Oracle GoldenGate for Oracle Installation and Setup Guide

11.11 Example 3: Capturing from multiplesources with mixed real-time

and archive-log-only mode

The following example captures changes from database DBMS1, DBMS2 andDBMS3

by deploying an integrated capture session at a downstream mining database

DBMSCAP. It assumes the following users:

■ User GGADM1 in DBMS1 whose credentials Extract will useto fetch data and

metadata from DBMS1. User GGADM1 has select privileges on v_$database at

DBMS1. It is assumed that the DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE()

procedure was called to grant appropriate privileges to this user atDBMS1.

■ User GGADM2 in DBMS2 whose credentials Extract will useto fetch data and

metadata from DBMS2. User GGADM2 has select privileges on v_$database at

DBMS2. It is assumed that the DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE()

procedure was called to grant appropriate privileges to this user atDBMS2.

■ User GGADM3 in DBMS3 whose credentials Extract will useto fetch data and

metadata from DBMS3. User GGADM3 has select privileges on v_$database at

DBMS3. It is assumed that the DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE()

procedure was called to grant appropriate privileges to this user atDBMS3.

■ User GGADMCAP in DBMSCAP whose credentials Extract willuse to retrieve

logical change records from the logmining server at the downstream mining

database. It is assumed that the DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_

PRIVILEGE()procedure wascalled to grant appropriate privileges to this user at

the downstream mining database DBMSCAP. User GGADMCAP has select

privileges on v_$databaseat DBMSCAP.

This procedure also assumes that the downstream mining database isconfigured in

archivelog mode.

In this example, the redo sent by DBMS3 will be mined in real time mode,whereas the

redo data sent from DBMS1 and DBMS2 will be mined in archive-log-onlymode.

11.11.1 Prepare the mining database toarchive its local redo

1. The downstream mining database mustbe in archivelog mode. You can do this by

issuing the following DDL.

STARTUPMOUNT;

ALTERDATABASE ARCHIVELOG;

ALTERDATABASE OPEN;

Note: You can create multiple Extractscapturing data from the same

source database while running in archive-log-only mode in the

downstream mining database. In the case of these examples, you can

create other Extracts capturing changes for database DBMS1 and

DBMS2 at the downstream mining database.

Note: This example assumes that youcreated the necessary standby

redo log files as shown in "Configuring a downstream mining

database for integrated capture" on page A-1.

Example 3: Capturing from multiple sources with mixedreal-time and archive-log-only mode

Exampleconfiguration of downstream mining database for integrated capture B-7

2. At the downstream mining database,set log_archive_dest_1to archivelocal

redo.

ALTERSYSTEM SET

LOG_ARCHIVE_DEST_1='LOCATION=/home/arc_dest/local

VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE)'

3. Enable log_archive_dest_1.

ALTERSYSTEM SET LOG_ARCHIVE_DEST_STATE_1=ENABLE

11.11.2 Prepare the mining database to acceptredo from the source databases

Because redo data is being accepted in the standby redo logs of thedownstream

mining database, the appropriate number of correctly sized standby redologs must

exist. If you did not configure the standby logs, see "Configuring a downstream

mining database for integrated capture" on page A-1.

1. At the downstream mining database,set the second archive log destination in the

LOG_ARCHIVE_DEST_ninitializationparameter as shown in the following example.

This is needed to handle archive standby redo logs.

ALTERSYSTEM SET

LOG_ARCHIVE_DEST_2='LOCATION=/home/arc_dest/srl_dbms3

VALID_FOR=(STANDBY_LOGFILE,PRIMARY_ROLE)'

2. Enable the LOG_ARCHIVE_DEST_STATE_2 initialization parameter thatcorresponds

with the LOG_ARCHIVE_DEST_2parameter asshown in the following example.

ALTERSYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE

3. Set DG_CONFIG at the downstream mining database toaccept redo data from all of

the source databases.

ALTERSYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbms1, dbms2, dbms3,

dbmscap)'

11.11.3 Prepare the first source database tosend redo to the mining database

1. Make certain that DBMS1 sourcedatabase is running with the required

compatibility.

selectname, value from v$parameter where name = 'compatible';

NAMEVALUE

------------------------------

compatible11.1.0.7.0

The minimum compatibility setting required from integrated capture is10.2.0.0.0.

2. Set DG_CONFIG at DBMS1 source database.

ALTERSYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbms1, dbmscap)';

3. Set up redo transport at DBMS1source database. The TEMPLATE clause is

mandatory if you want to send redo data directly to foreign archived logsat the

downstream mining database.

ALTERSYSTEM

SETLOG_ARCHIVE_DEST_2='SERVICE=DBMSCAP.EXAMPLE.COM ASYNC OPTIONAL NOREGISTER

TEMPLATE='/usr/orcl/arc_dest/dbms1/dbms1_arch_%t_%s_%r.logVALID_FOR=(ONLINE_

LOGFILES,PRIMARY_ROLE)DB_UNIQUE_NAME=dbmscap';

Example 3: Capturing from multiple sources with mixedreal-time and archive-log-only mode

B-8 Oracle GoldenGate for Oracle Installation and Setup Guide

4. Enable the downstream destination.

ALTERSYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

11.11.4 Prepare the second source database tosend redo to the mining database

1. Make sure that DBMS2 source databaseis running with the required

compatibility.

selectname, value from v$parameter where name = 'compatible';

NAMEVALUE

------------------------------

compatible10.2.0.3.0

The minimum compatibility setting required from integrated capture is10.2.0.0.0.

2. Set DG_CONFIG at DBMS2 source database.

ALTERSYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbms2, dbmscap)';

3. Set up redo transport at DBMS2source database. The TEMPLATE clause is

mandatory if you want to send redo data directly to foreign archived logsat the

downstream mining database.

ALTERSYSTEM

SETLOG_ARCHIVE_DEST_2='SERVICE=DBMSCAP.EXAMPLE.COM ASYNC OPTIONAL NOREGISTER

TEMPLATE='/usr/orcl/arc_dest/dbms2/dbms2_arch_%t_%s_%r.logVALID_FOR=(ONLINE_

LOGFILES,PRIMARY_ROLE)DB_UNIQUE_NAME=dbmscap';

4. Enable the downstream destination.

ALTERSYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

11.11.5 Prepare the third source database tosend redo to the mining database

1. Make sure that DBMS3 source databaseis running with the required

compatibility.

selectname, value from v$parameter where name = 'compatible';

NAMEVALUE

------------------------------

compatible11.2.0.3.0

The minimum compatibility setting required from integrated capture is10.2.0.0.0.

2. Set DG_CONFIG at DBMS3 source database.

ALTERSYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbms3, dbmscap)';

3. Set up redo transport at DBMS3source database. Because DBMS3 is the source

that will send its online redo logs to the standby redo logs at thedownstream

mining database, do not specify a TEMPLATE clause.

ALTERSYSTEM

SETLOG_ARCHIVE_DEST_2='SERVICE=DBMSCAP.EXAMPLE.COM ASYNC OPTIONAL NOREGISTER

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)DB_UNIQUE_NAME=dbmscap';

4. Enable the downstream destination.

ALTERSYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

Example 3: Capturing from multiple sources with mixedreal-time and archive-log-only mode

Exampleconfiguration of downstream mining database for integrated capture B-9

11.11.6 Set up Extracts at downstream miningdatabase

These steps set up Extract at the downstream database to capture from thearchived

logs sent by DBMS1 and DBMS2.

11.11.6.1 Set up Extract (ext1) to capturechanges from archived logs sent by

DBMS1

Perform the following steps on the DBMSCAP downstream mining database.

1. Register Extract with DBMSCAP forthe DBMS1 source database.

GGSCI>DBLOGIN USERID ggadm1@dbms1 PASSWORD ggadm1pw

GGSCI>MININGDBLOGIN USERID ggadmcap@dbmscap PASSWORD ggadmcappw

GGSCI>REGISTER EXTRACT ext1 DATABASE

2. Add Extract at the mining databaseDBMSCAP.

GGSCI>ADD EXTRACT ext1 INTEGRATED TRANLOG BEGIN NOW

3. Edit the Extract parameter file ext1.prm.

USERIDggadm1@dbms1 PASSWORD ggadm1pw

TRANLOGOPTIONSMININGUSER ggadmcap@dbmscap, MININGPASSWORD ggadmcappw

TRANLOGOPTIONSINTEGRATEDPARAMS (downstream_real_time_mine N)

4. Start Extract.

GGSCI>START EXTRACT ext1

11.11.6.2 Set up Extract (ext2) to capturechanges from archived logs sent by

DBMS2

Perform the following steps on the DBMSCAP downstream mining database.

1. Register Extract with the miningdatabase for source database DBMS2.

GGSCI>DBLOGIN USERID ggadm2@dbms2, PASSWORD ggadm2pw

GGSCI>MININGDBLOGIN USERID ggadmcap@dbmscap, PASSWORD ggadmcappw

GGSCI>REGISTER EXTRACT ext2 DATABASE

2. Create Extract at the miningdatabase.

GGSCI>ADD EXTRACT ext2 INTEGRATED TRANLOG, BEGIN NOW

3. Edit the Extract parameter file ext2.prm.

USERIDggadm2@dbms2, PASSWORD ggadm2pwd

TRANLOGOPTIONSMININGUSER ggadmcap@dbmscap, MININGPASSWORD ggadmcappw

TRANLOGOPTIONSINTEGRATEDPARAMS (downstream_real_time_mine N)

4. Start Extract.

GGSCI>START EXTRACT ext2

11.11.6.3 Set up Extract (ext3) to capturechanges in real-time mode from

online logs sent by DBMS3

Perform the following steps on the DBMSCAP downstream mining database.

1. Register Extract with the miningdatabase for source database DBMS3.

GGSCI>DBLOGIN USERID ggadm3@dbms3, PASSWORD ggadm3pw

GGSCI>MININGDBLOGIN USERID ggadmcap@dbmscap, PASSWORD ggadmcappw

GGSCI>REGISTER EXTRACT ext3 DATABASE

Example 3: Capturing from multiple sources with mixedreal-time and archive-log-only mode

B-10 Oracle GoldenGate for Oracle Installation and Setup Guide

2. Create Extract at the miningdatabase.

GGSCI>ADD EXTRACT ext3 INTEGRATED TRANLOG, BEGIN NOW

3. Edit the Extract parameter file ext3.prm. To enable real-time mining, youmust

specify downstream_real_time_mine.

USERIDggadm3@dbms3, PASSWORD ggadm3pwd

TRANLOGOPTIONSMININGUSER ggadmcap@dbmscap, MININGPASSWORD ggadmcappw

TRANLOGOPTIONSINTEGRATEDPARAMS (downstream_real_time_mine Y)

4. Start Extract.

GGSCI>START EXTRACT ext3

Note: You can create multiple Extractsrunning in real-time

integrated capture mode in the downstream mining database, as long

as they all are capturing data from the same source database, such as

all capturing for database DBMS3 in the preceding example.

C

Supporting changesto XML schemas C-1

CSupportingchanges to XML schemas

This topic contains instructions for supporting changes to an XML schema.Both

classic and integrated capture modes do not support the capture of changesmade to

an XML schema.

11.12 Supporting RegisterSchema

RegisterSchemacan be handledby registering the schema definition on both source

and target databases before any table is created that references the XMLschema.

11.13 Supporting DeleteSchema:

Issue DeleteSchema on the source database first. OnceReplicat is caught up with the

changes made to the source database, issue the DeleteSchema call on the target

database.

11.14 Supporting CopyEvolve

The CopyEvolve procedure evolves, or changes, a schema and can modifytables by

adding or removing columns. It can also be used to change whether or notXML

documents are valid. Handling CopyEvolve requires more coordination. Use the

following procedure if you are issuing CopyEvolve on the source database.

1. Quiesce changes to dependent tableson the source database.

2. Execute the CopyEvolve on the primary or source database.

3. Wait for Replicat to finish applyingall of the data from those tables to the target

database.

4. Stop Replicat.

5. Apply the CopyEvolve on the target database.

6. Restart Replicat.

Supporting CopyEvolve

C-2 Oracle GoldenGate for Oracle Installation and Setup Guide

D

Preparing DBFS foractive-active propagation with Oracle GoldenGate D-1

DPreparingDBFS for active-active

propagation with Oracle GoldenGate

This chapter contains steps to configure Oracle GoldenGate to functionwithin an

active-active bi-directional or multi-directional environment where OracleDatabase

File System (DBFS) is in use on both (or all) systems.

11.15 Supported operations and prerequisites

Oracle GoldenGate for DBFS supports the following:

■ Supported DDL (like TRUNCATE or ALTER) on DBFS objects except for CREATE

statements on the DBFS objects. CREATE on DBFS must beexcluded from the

configuration, as must any schemas that will hold the created DBFSobjects. The

reason to exclude CREATES is that themetadata for DBFS must be properly

populated in the SYS dictionary tables (which itself is excluded fromOracle

GoldenGate capture by default).

■ Capture and replication of DML on the tables thatunderlie the DBFS filesystem.

The procedures that follow assume that Oracle GoldenGate is configuredproperly to

support active-active configuration. This means that it must be:

■ Installed according to the instructions in this guide.

■ Configured according to the instructions in the OracleGoldenGate Windowsand

UNIX Administrator's Guide.

11.16 Applying the required patch

Apply the Oracle DBFS patch for bug-9651229 on both databases. Todetermine if the

patch is installed, run the following query:

connect/ as sysdba

selectprocedure_name

fromdba_procedures

whereobject_name = 'DBMS_DBFS_SFS_ADMIN'

andprocedure_name = 'PARTITION_SEQUENCE';

The query should return a single row. Anything else indicates that theproper patched

version of DBFS is not available on your database.

Examples used in these procedures

D-2 Oracle GoldenGate for Oracle Installation and Setup Guide

11.17 Examples used in these procedures

The following procedures assume two systems and configure the environmentso that

DBFS users on both systems see the same DBFS files, directories, andcontents that are

kept in synchronization with Oracle GoldenGate. It is possible to extendthese

concepts to support three or more peer systems.

11.18 Partitioning the DBFS sequence numbers

DBFS uses an internal sequence-number generator to construct unique namesand

unique IDs. These steps partition the sequences into distinct ranges toensure that

there are no conflicts across the databases. After this is done, furtherDBFS operations

(both creation of new fileystems and subsequent filesystem operations) canbe

performed without conflicts of names, primary keys, or IDs during DMLpropagation.

1. Connect to each database as sysdba.

Issue the following query on each database.

selectlast_number

fromdba_sequences

wheresequence_owner = 'SYS'

andsequence_name = 'DBFS_SFS_$FSSEQ'

2. From this query, choose the maximumvalue of LAST_NUMBER across both systems,

or pick a high value that is significantly larger than the current valueof the

sequence on either system.

3. Substitute this value (“maxval” is used here as a placeholder) inboth of the

following procedures. These procedures logically index each system as myid=0 and

myid=1.

Node1

declare

begin

dbms_dbfs_sfs_admin.partition_sequence(nodes=> 2, myid => 0, newstart =>

:maxval);

commit;

end;

/

Node 2

declare

begin

dbms_dbfs_sfs_admin.partition_sequence(nodes => 2, myid => 1, newstart =>

:maxval);

commit;

end;

/

For a multi-way configuration among three or more databases, you couldmake

the following alterations:

■ Adjust the maximum value that is set for maxval upward appropriately, and

use that value on all nodes.

Note: Notice the difference in the valuespecified for the myid

parameter. These are the different index values.

Configuring the DBFS filesystem

Preparing DBFS foractive-active propagation with Oracle GoldenGate D-3

■ Vary the value of myid in the procedure from 0 for thefirst node, 1 for the

second node, 2 for the third one, and so on.

4. (Recommended) After (and only after)the DBFS sequence generator is partitioned,

create a new DBFS filesystem on each system, and use only thesefilesystems for

DML propagation with Oracle GoldenGate. See "Configuring the DBFSfilesystem"

on page D-3.

11.19 Configuring the DBFS filesystem

To replicate DBFS filesystem operations, use a configuration that issimilar to the

standard bi-directional configuration for DML.

■ Use matched pairs of identically structured tables.

■ Allow each database to have write privileges to oppositetables in a set, and set the

other one in the set to read-only. For example:

■ Node1 writes to local table t1 and these changes are replicated to t1 on

Node2.

■ Node2 writes to local table t2 and these changes are replicated to t2 on

Node1.

■ On Node1, t2 is read-only.On Node2, t1 is read-only.

DBFS filesystems make this kind of table pairing simple because:

■ The tables that underlie the DBFS filesystems have thesame structure.

■ These tables are modified by simple, conventional DMLduring higher-level

filesystem operations.

■ The DBFS ContentAPI provides a way of unifying thenamespace of the individual

DBFS stores by means of mount points that can be qualified as read-writeor

read-only.

The following steps create two DBFS filesystems (in this case named FS1 and FS2) and

set them to be read-write or read, as appropriate.

1. Run the following procedure tocreate the two filesystems. (Substitute your store

names for FS1 and FS2.)

Example 11–1

declare

dbms_dbfs_sfs.createFilesystem('FS1');

dbms_dbfs_sfs.createFilesystem('FS2');

dbms_dbfs_content.registerStore('FS1',

'posix','DBMS_DBFS_SFS');

dbms_dbfs_content.registerStore('FS2',

'posix','DBMS_DBFS_SFS');

commit;

end;

Note: DBFS filesystems that were createdbefore the patch for

bug-9651229 was applied or before the DBFS sequence number was

adjusted can be configured for propagation, but that requires

additional steps not described in this document. If you must retain old

filesystems, open a service request with Oracle Support.

Mapping local and remote peers correctly

D-4 Oracle GoldenGate for Oracle Installation and Setup Guide

/

2. Run the following procedure to giveeach filesystem the appropriate access rights.

(Substitute your store names for FS1 and FS2.)

Example 11–2 Node 1

declare

dbms_dbfs_content.mountStore('FS1','local');

dbms_dbfs_content.mountStore('FS2','remote',

read_only=> true);

commit;

end;

/

Example 11–3 Node 2

declare

dbms_dbfs_content.mountStore('FS1','remote',

read_only=> true);

dbms_dbfs_content.mountStore('FS2','local');

commit;

end;

/

In this example, note that on Node 1, store FS1 is read-write and store FS2 is

read-only, while on Node 2 the converse is true: store FS1 is read-only and store

FS2 is read-write.

Note also that the read-write store is mounted as localand theread-only store is

mounted as remote. This provides users on each system with an identical

namespace and identical semantics for read and write operations. Localpath

names can be modified, but remote path names cannot.

11.20 Mapping local and remote peerscorrectly

The names of the tables that underlie the DBFS filesystems are generatedinternally

and dynamically. Continuing with the preceding example, there are:

■ Two nodes (Node 1 and Node 2 in the example).

■ Four stores: two on each node (FS1 and FS2 in theexample).

■ Eight underlying tables: two for each store (a table anda ptable). These tables

must be identified, specified in Extract TABLE statements, and mapped in Replicat

MAP statements.

1. To identify the table names thatback each filesystem, issue the following query.

(Substitute your store names for FS1 and FS2.)

Example 11–4

selectfs.store_name, tb.table_name, tb.ptable_name

fromtable(dbms_dbfs_sfs.listTables) tb,

table(dbms_dbfs_sfs.listFilesystems)fs

wherefs.schema_name = tb.schema_name

andfs.table_name = tb.table_name

andfs.store_name in ('FS1', 'FS2')

;

The output looks like the following examples.

Mapping local and remote peers correctly

Preparing DBFS for active-activepropagation with Oracle GoldenGate D-5

Example 11–5 Example output: Node 1 (Yourtable names will be different.)

STORENAME TABLE_NAME PTABLE_NAME

-------------------------- -------------

FS1SFS$_FST_100 SFS$_FSTP_100

FS2SFS$_FST_118 SFS$_FSTP_118

Example 11–6 Example output: Node 2 (Yourtable names will be different.)

STORENAME TABLE_NAME PTABLE_NAME

-------------------------- -------------

FS1SFS$_FST_101 SFS$_FSTP_101

FS2SFS$_FST_119 SFS$_FSTP_119

2. Identify the tables that are locallyread-write to Extract by creating the following

TABLE statements in the Extract parameterfiles. (Substitute your owner and table

names.)

Example 11–7 Node1

TABLEowner.SFS$_FST_100

TABLEowner.SFS$_FSTP_100;

Example 11–8 Node2

TABLEowner.SFS$_FST_119

TABLEowner.SFS$_FSTP_119;

3. Link changes on each remotefilesystem to the corresponding local filesystem by

creating the following MAP statements inthe Replicat parameter files. (Substitute

your owner and table names.)

Example 11–9 Node1

MAPowner.SFS$_FST_119, TARGET owner.SFS$_FST_118;

MAPowner.SFS$_FSTP_119, TARGET owner.SFS$_FSTP_118

Example 11–10 Node2

MAPowner.SFS$_FST_100, TARGET owner.SFS$_FST_101;

MAPowner.SFS$_FSTP_100, TARGET owner.SFS$_FSTP_101;

This mapping captures and replicates local read-write sourcetables toremote

read-only peer tables:

■ Filesystem changes made to FS1 on Node 1 propagate to FS1 on Node 2.

■ Filesystem changes made to FS2 on Node 2 propagate to FS2 on Node1.

Changes to the filesystems can be made through the DBFS ContentAPI(package

DBMS_DBFS_CONTENT) of the database or through dbfs_client mounts and

conventional filesystems tools.

All changes are propagated in both directions.

■ A user at the virtual root of the DBFS namespace on eachsystem sees identical

content.

■ For mutable operations, users use the /local sub-directory on each system.

■ For read operations, users can use either of the /local or /remote

sub-directories, depending on whether they want to see local or remote

content.

Mapping local and remote peers correctly

D-6 Oracle GoldenGate for Oracle Installation and Setup Guide

E

Oracle GoldenGateinstalled components E-1

EOracleGoldenGate installed components

This appendix describes the programs, directories, and other componentscreated or

used by the Oracle GoldenGate software in the Oracle GoldenGateinstallation

directory. Additional files not listed here might be installed on certainplatforms. Files

listed here might not be installed on every platform.

11.21 Oracle Goldengate Programs AndUtilities

This section describes programs installed in the root Oracle Goldengateinstallation

directory.

Note: Some programs may not exist in allinstallations. For example,

if only capture or delivery is supported by Oracle GoldenGate for

your platform, the extract or replicat program will not be installed,

respectively. Likewise, special files might be installed to support a

specific database.

Table 11–1 Oracle GoldenGate installedprograms and utilities

Program Description

convchk Converts checkpoint files to a newerversion.

ddlgen Generates target database tabledefinitions based on source

database DDL. Used primarily on the NonStop platform.

defgen Generates data definitions and isreferenced by Oracle

GoldenGate processes when source and target tables have

dissimilar definitions.

emsclnt Sends event messages created byCollector and Replicat on

Windows or UNIX systems to EMS on NonStop systems.

extract Performs capture from databasetables or transaction logs or

receives transaction data from a vendor access module.

ggmxinstallOracleGoldenGate installation script for the SQL/MX database.

ggsci User interface to Oracle GoldenGatefor issuing commands and

managing parameter files.

ggsmgr.jcl

ggsmgr.proc

ggsmgrst.jcl

ggsmgrst.proc

Start the Oracle GoldenGate Manager process from a batch job

or the operator console on a z/OS system. Installed to support

DB2 z/OS databases.

Oracle Goldengate Subdirectories

E-2 Oracle GoldenGate for Oracle Installation and Setup Guide

11.22 Oracle Goldengate Subdirectories

This Section describes the subdirectories of the Oracle Goldengateinstallation

directory and their contents.

install Installs Oracle GoldenGate as aWindows service and provides

other Windows-based service options.

keygen Generates data-encryption keys.

logdump A utility for viewing and savinginformation stored in extract

trails or files.

mgr (Manager) Control process forresource management, control

and monitoring of Oracle GoldenGate processes, reporting, and

routing of requests through the GGSCI interface.

replicatApplies data totarget database tables.

reverse A utility that reverses the order oftransactional operations, so

that Replicat can be used to back out changes from target tables,

restoring them to a previous state.

server The Collector process, an ExtractTCP/IP server collector that

writes data to remote trails.

triggen Generates scripts that create theOracle GoldenGate log table

and logging triggers to support the trigger-based extraction

method.

vamserv Started by Extract to read the TMFaudit trails generated by

TMF-enabled applications. Installed to support the NonStop

SQL/MX database.

Note: Some directories may not exist inall installations.

Table 11–2 Oracle GoldenGate installedsubdirectories

Directory Description

br Contains the checkpoint files forthe bounded recover feature.

cfg Contains the property and XML filesthat are used to configure

Oracle GoldenGate Monitor.

dirdb Contains the datastore that is usedto persist information that is

gathered from an Oracle GoldenGate instance for use by the

Oracle GoldenGate Monitor application or within Oracle

Enterprise Manager.

Table 11–1 (Cont.) Oracle GoldenGateinstalled programs and utilities

Program Description

Oracle Goldengate Subdirectories

Oracle GoldenGateinstalled components E-3

dirchk Contains the checkpoint filescreated by Extract and Replicat

processes, which store current read and write positions to

support data accuracy and fault tolerance. Written in internal

Oracle GoldenGate format.

File name format is group_name+sequence_number.ext where

sequence_number is a sequential number appended toaged files

and ext is either cpe for Extract checkpoint files or cpr for

Replicat checkpoint files.

Do not edit these files.

Examples:

ext1.cpe

rep1.cpr

dirdat The default location for OracleGoldenGate trail files and extract

files that are created by Extract processes to store extracted data

for further processing by the Replicat process or another

application or utility. Written in internal Oracle GoldenGate

format.

File name format is a user-defined two-character prefix followed

by either a six-digit sequence number (trail files) or the

user-defined name of the associated Extract process group

(extract files).

Do not edit these files.

Examples:

rt000001

finance

dirdef The default location for datadefinitions files created by the

DEFGEN utility to contain source or target data definitions used

in a heterogeneous synchronization environment. Written in

external ASCII. File name format is a user-defined name

specified in the DEFGEN parameter file.

These files may be edited to add definitions for newly created

tables. If you are unsure of how to edit a definitions file, contact

Oracle GoldenGate technical support.

Example:

defs.dat

dirjar Contains the Java executable filesthat support Oracle

GoldenGate Monitor.

dirout This directory is not used any more.

dirpcs Default location for status files.File name format is

group.extension where group is the name of the group and

extension is either pce (Extract), pcr (Replicat), or pcm

(Manager).

These files are only created while a process is running. The file

shows the program name, the process name, the port number,

and the process ID.

Do not edit these files.

Examples:

mgr.pcm

ext.pce

Table 11–2 (Cont.) Oracle GoldenGateinstalled subdirectories

Directory Description

Other Oracle GoldenGate files

E-4 Oracle GoldenGate for Oracle Installation and Setup Guide

11.23 Other Oracle GoldenGate files

This section describes other files, templates, and objects created orinstalled in the root

Oracle GoldenGate installation directory.

dirprm The default location for OracleGoldenGate parameter files

created by Oracle GoldenGate users to store run-time

parameters for Oracle GoldenGate process groups or utilities.

Written in external ASCII format. File name format is group

name/user-defined name.prm or mgr.prm .

These files may be edited to change Oracle GoldenGate

parameter values after stopping the process. They can be edited

directly from a text editor or by using the EDIT PARAMS

command in GGSCI.

Examples:

defgen.prm

finance.prm

dirrec Not used by Oracle GoldenGate.

dirrpt The default location for processreport files created by Extract,

Replicat, and Manager processes to report statistical information

relating to a processing run. Written in external ASCII format.

File name format is group name+sequence number.rpt where

sequencenumber is a sequentialnumber 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 triggen

was deprecated. Currently used to store training scripts and any

user-created SQL scripts that support Oracle GoldenGate.

dirtmp The default location for storingtransaction data when the size

exceeds the memory size that is allocated for the cache manager.

Do not edit these files.

dirwlt Contains the Oracle Wallet thatsupports Oracle GoldenGate

Monitor. This directory is not installed until you run the utility

that creates the wallet.

UserExitExamplesContains samplefiles to help with the creation of user exits.

Note: Some files may not be installed inyour environment,

depending on the database and OS platform.

Table 11–3 Other Oracle GoldenGate installedfiles

Component Description

bcpfmt.tplTemplate foruse with Replicat when creating a run file for the

Microsoft BCP/DTS bulk-load utility.

bcrypt.txtBlowfishencryption software license agreement.

Table 11–2 (Cont.) Oracle GoldenGateinstalled subdirectories

Directory Description

Other Oracle GoldenGate files

Oracle GoldenGateinstalled components E-5

cagent.dllContains theWindows dynamic link library for the Oracle

GoldenGate Monitor C sub-agent.

category.dllWindows dynamiclink library used by the INSTALL utility.

chkpt_db_create.sql Script that creates a checkpointtable in the local database. A

different script is installed for each database type.

db2cntl.tplTemplate foruse with Replicat when creating a control file for

the IBM LOADUTIL bulk-load utility.

ddl_access.tplTemplate usedby the DDLGEN utility to convert source DDL to

Microsoft Access DDL.

ddl_cleartrace.sqlScript thatremoves the DDL trace file. (Oracle installations)

ddl_db2.tplTemplate usedby the DDLGEN utility to convert source DDL to

DB2 DDL (Linux, UNIX, Windows).

ddl_db2_os390.tplTemplate usedby the DDLGENutility to convert source DDL to

DB2 DDL (z/OS systems).

ddl_ddl2file.sqlScript thatsaves DDL from the marker table to a file.

ddl_disable.sqlScript thatdisables the Oracle GoldenGate DDL trigger. (Oracle

installations)

ddl_enable.sqlScript thatenables the Oracle GoldenGate DDL trigger. (Oracle

installations)

ddl_filter.sqlScript thatsupports filtering of DDL by Oracle GoldenGate. This

script runs programmatically; do not run it manually.

ddl_informix.tplTemplate usedby the DDLGEN utility to convert source DDL to

Informix DDL.

ddl_mss.tplTemplate usedby the DDLGEN utility to convert source DDL to

SQL Server DDL.

ddl_mysql.tplTemplate usedby the DDLGEN utility to convert source DDL to

MySQL DDL.

ddl_

nopurgeRecyclebin.sql

Empty script file for use by Oracle GoldenGate support staff.

ddl_nssql.tplTemplate usedby the DDLGEN utility to convert source DDL to

NonStop SQL DDL.

ddl_ora9.sql

ddl_ora10.sql

ddl_ora11.sql

ddl_ora10upCommon.sql

Scripts that run programmatically as part of Oracle GoldenGate

DDL support; do not run these scripts.

ddl_oracle.tplTemplate usedby the DDLGEN utility to convert source DDL to

Oracle DDL.

ddl_pin.sqlScript thatpins DDL tracing, the DDL package, and the DDL

trigger for performance improvements. (Oracle installations)

ddl_purgeRecyclebin.sqlScript thatpurges the Oracle recyclebin in support of the DDL

replication feature.

ddl_remove.sqlScript thatremoves the DDL extraction trigger and package.

(Oracle installations)

ddl_session.sql

ddl_session1.sql

Supports the installation of the Oracle DDL objects. This script

runs programmatically; do not run it manually.

Table 11–3 (Cont.) Other Oracle GoldenGateinstalled files

Component Description

Other Oracle GoldenGate files

E-6 Oracle GoldenGate for Oracle Installation and Setup Guide

ddl_setup.sqlScript thatinstalls the Oracle GoldenGate DDL extraction and

replication objects. (Oracle installations)

ddl_sqlmx.tplTemplate usedby the DDLGEN utility to convert Tandem

Enscribe DDL to NonStop SQL/MX DDL.

ddl_status.sqlScript thatverifies whether or not each object created by the

Oracle GoldenGate DDL support feature exists and is

functioning properly. (Oracle installations)

ddl_staymetadata_off.sql

ddl_staymetadata_on.sql

Scripts that control whether the Oracle DDL trigger collects

metadata. This script runs programmatically; do not run it

manually.

ddl_sybase.tplTemplate usedby the DDLGEN utility to convert source DDL to

Sybase DDL.

ddl_tandem.tplTemplate usedby the DDLGEN utility to convert source DDL to

NonStop SQL DDL.

ddl_trace_off.sql

ddl_trace_on.sql

Scripts that control whether DDL tracing is on or off.

ddl_tracelevel.sqlScript thatsets the level of tracing for the DDL support feature.

(Oracle installations)

debugfiles Debug textfiles 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 use

with tutorials and basic testing.

.dmpfiles Dump filescreated by Oracle GoldenGate processes for tracing

purposes.

ENCKEYS User-created file that storesencryption keys. Written in external

ASCII format.

exitdemo.cUser exitexample.

exitdemo_utf16.cUser exitexample that demonstrates how to use UTF16 encoded

data in the callback structures for information exchanged

between the user exit and the process.

freeBSD.txtLicenseagreement for FreeBSD.

ggmessage.datData file thatcontains error, informational, and warning

messages that are returned by the Oracle GoldenGate processes.

The version of this file is checked upon process startup and must

be identical to that of the process in order for the process to

operate.

ggserr.logFile that logsprocessing events, messages, errors, and warnings

generated by Oracle GoldenGate.

ggsmsg.dllWindows dynamiclink library used by the install program.

GLOBALS User-created file that storesparameters applying to the Oracle

GoldenGate instance as a whole.

help.txtHelp file forthe GGSCI command interface.

icudt38.dll

icuin38.dll

icuuc38.dll

Windows shared libraries for International Components for

Unicode.

Table 11–3 (Cont.) Other Oracle GoldenGateinstalled files

Component Description

Other Oracle GoldenGate files

Oracle GoldenGateinstalled components E-7

jagent.batWindows batchfile for the Java Agent for Oracle GoldenGate

Monitor.

jagent.log

jagentjni.log

Log files for the Oracle GoldenGate Monitor Agent.

jagent.shUNIX shellscript for the Java Agent for Oracle GoldenGate

Monitor

LGPL.txtLesser GeneralPublic License statement. Applies to free libraries

from the Free Software Foundation.

libodbc.soODBC file forIngres 2.6 on Unix.

libodbc.txtLicenseagreement for libodbc.so.

libxml2.dllWindows dynamiclink library containing the XML library for

the Oracle GoldenGate XML procedures.

libxml2.txtLicenseagreement for libxml2.dll .

marker.histFile created byReplicat if markers were passed from a NonStop

source system.

marker_remove.sqlScript thatremoves the DDL marker table. (Oracle installations)

marker_setup.sqlScript thatinstalls the Oracle GoldenGate DDL marker table.

(Oracle installations)

marker_status.sqlScript thatconfirms successful installation of the DDL marker

table. (Oracle installations)

notices.txtThird-partysoftware license file.

odbcinst.iniIngres 2.6 onUnix ODBC configuration file.

params.sqlScript thatcontains configurable parameters for DDL support.

(Oracle installations)

pthread-win32.txtLicenseagreement for pthread-VC.dll .

pthread-VC.dllPOSIX threadslibrary for Microsoft Windows.

prvtclkm.plbSupports thereplication of Oracle encrypted data.

pw_agent_util.bat

pw_agent_util.sh

Script files that support the Oracle GoldenGate Monitor Agent.

role_setup.sqlScript thatcreates the database role necessary for Oracle

GoldenGate DDL support. (Oracle installations)

sampleodbc.iniSample ODBCfile for Ingres 2.6 on UNIX.

sqlldr.tplTemplate foruse with Replicat when creating a control file for

the Oracle SQL*Loader bulk-load utility.

start.prm

stop.prm

z/OS paramlib members to start and stop theManager process.

startmgr

stopmgr

z/OS Unix System Services scripts to start the Manager process

from GGSCI.

startmgrcom

stopmgrcom

z/OS system input command for the Manager process.

tcperrs File containing user-definedinstructions for responding to

TCP/IP errors.

Table 11–3 (Cont.) Other Oracle GoldenGateinstalled files

Component Description

Oracle GoldenGate checkpoint table

E-8 Oracle GoldenGate for Oracle Installation and Setup Guide

11.24 Oracle GoldenGate checkpoint table

When database checkpoints are being used, Oracle GoldenGate creates acheckpoint

table with a user-defined name in the database upon execution of the ADD

CHECKPOINTTABLEcommand, or auser can create the table by using the chkpt_db_

create.sqlscript (where db is an abbreviation of the type ofdatabase that the script

supports).

Do not change the names or attributes of the columns in this table. Youcan change

table storage attributes as needed.

usrdecs.hInclude filefor user exit API.

xerces-c_2_8.dllApache XMLparser library.

zlib.txtLicenseagreement for zlib compression library.

Table 11–4 Checkpoint table definition

Column Description

GROUP_NAME(primary key) The name of aReplicat group using this table for checkpoints.

There can be multiple Replicat groups using the same table.

GROUP_KEY(primary key) A uniqueidentifier that, together with GROUPNAME, uniquely

identifies a checkpoint regardless of how many Replicat groups

are writing to the same table.

SEQNO The sequence number of thecheckpoint file.

RBA The relative byte address of thecheckpoint in the file.

AUDIT_TSThe timestampof the checkpoint position in the checkpoint file.

CREATE_TSThe date andtime when the checkpoint table was created.

LAST_UPDATE_TSThe date andtime when the checkpoint table was last updated.

CURRENT_DIRThe currentOracle GoldenGate home directory or folder.

Table 11–3 (Cont.) Other Oracle GoldenGateinstalled files

ComponentDescription