1

Oracle Goldengate Concepts and Architecture

Oracle Goldengate supports the replication of data across various heterogeneous platforms. The Goldengate
replication topology includes the capture and transfer of the extracted data from the source database, across to
the destination database.
Below are the topologies which can be used to fulfill various data transfer requirements using data replication.

Goldengate Topologies

1. Uni-directional: Data is replicated in one direction from source to target

2. Bi-Directional: The data flows in both direction and stays synced up between site A and site B

3. Peer to Peer: Similar to Bi-directional but involves more than 2 databases which stay synced up

4. Broadcast: Data from source is sent to multiple destinations

5. Consolidation: Data from multiple sources is delivered to one destination DB

6. Cascading: Data from one source is sent to multiple destinations

Oracle Golden Gate Logical Architecture

The Oracle Golden Gate architecture consists of the following components:
 2

Goldengate Components

Manager: The Manager is the process which starts the other Goldengate processes. This process must be
running on the source and target system for the configuration and starting up of all the other Goldengate
processes. he Manager process also manages the disk space by purging the old trail files. Only one Manager
Process is required for every Goldengate installation.

Extract: The Extract process is responsible for capturing the committed DML transactions and the DDL from
Oracle Redo logs. Then Extract writes these data changes into Trail or Extract Files.

Data Pump: The Pump process which is also an extract process is optional in the Goldengate setup. This
process copies the Trail files containing the data to the target system.

Replicat: The Replicat process is the apply process in the Goldengate configuration. This process runs at the
end point of the data delivery chain on the target database. This process reads the destination trail files and
applies the data changes to the target systems.

Trail/Extract Files: The Extract process on the source database creates trail files for consumption by the pump
process for transfer to remote database or for consumption by a local replicate on the source database.

Checkpoint: The Extract Pump & Replicat processes use checkpoints for tracking the progress of these
processes. This mechanism marks the location up to point where the data changes have been retrieved or
applied from the trail files. This is useful when processes need to recover (without any data loss) or need to
know the starting point after a failure.
 3

Collector: The Collector process runs on the target system and writes the data changes from the source database
in the target Trail Files known as RMTTRAIL. Before copying it to RMTTRAIL it reassembles the files.

Oracle Golden Gate Setup Step by Step

The following prerequisites should be met to prepare an environment for the Goldengate installation. These
steps are applicable to both Linux and Windows environments and must be satisfied on both source and target
servers.

Goldengate Replication Setup Requirements

Operating System

a. Memory Ensure that there is enough memory. This will determine the number of Goldengate processes
which be configured on the server.

b. Memory Per Process Dependent on the size of the transactions and the amount of concurrent transactions
in the database. By default, one Goldengate extract or replicat process can take up to 8G of memory.

c. Swap space Configure reasonable swap space in case Goldengate processes swap due to low memory.

d. Disk space Enough disk space to hold the trail files for the required retention period. As a starting point it
could be made approximately the same as the amount of archive logs generated in a specific time period.

Goldengate Software

Download the Oracle Goldengate Media Pack Fusion Middleware Software from the edelivery site. Ensure
you have the appropriate software for the source and target based on the Host Operating System and the
Database version.

Windows Server
When using a Windows hosts Microsoft Visual C++ 2005 Redistributable software should be installed on the
server.
 4

Database
The requirements in this section are for the source database ONLY.

Archive logging
Enable archiving of logs on the source databases servers, if not already enabled.

Force Logging

Enable force logging at the database level. If you are using Oracle 12c Database however, you can alternatively
turn force logging at the tablespace level.

SQL>ALTER DATABASE FORCE LOGGING;

SQL>ALTER SYSTEM SWITCH LOGFILE;

OR
-- 12c only
SQL>ALTER DATABASE NO FORCE LOGGING;
SQL>ALTER TABLESPACE tablespace_name FORCE LOGGING;
SQL>ALTER TABLESPACE tablespace_name NOLOGGING;

Supplemental logging

Enable at the Database level and switch logfile.

SQL>ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

SQL>alter system switch logfile;

Object level supplemental logging

Turn on supplemental logging on the source database. This can be done either using sqlplus or GGSCI
command line.

If you are using GGSCI this needs to be done after the Goldengate Binary has been installed. At the GGSCI
prompt, connect to the database run the ADD TRANDATA commands below.

At the GGSCI prompt add supplemental logging.

DBLOGIN USERID OGG_USER PASSWORD hsdgeh#die4fsG

ADD TRANDATA [schema_name].*
INFO TRANDATA [schema_name].*

Recycle bin
Turn OFF recyclebin, to support DDL replication. This can be done using the command below.
 5

For 11g:ALTER SYSTEM SET RECYCLEBIN=OFF DEFERRED;

For 10g:ALTER SYSTEM SET RECYCLEBIN=OFF;

Primary Keys
Ensure that all tables have Primary or Unique Key. This is one of the MOST important requirement to ensure
proper replication of data without discrepancies. If not an alternative method of surrogate keys can be used.

Goldengate User
To support the Oracle Goldengate replication, a user must be created on both source and target databases with
the required privileges. This user will be used to extract data and lookup data dictionary information. However
before the user is created a new empty table space is required for this user.

SQL>create tablespace GG_TBS datafile '/u01/app/data/gg_ts01.dbf' size 5g;

SQL>create user OGG_USER identified by hsdgeh#die4fsG default tablespace
GG_TBS;
SQL> grant CONNECT, RESOURCE, DBA to OGG_USER;

Binary Installation and Setup

First create the directory where Goldengate will be installed and export the GG_HOME variable.

mkdir /u01/ggs/
export GG_HOME=/u01/ggs/
export PATH=$PATH:$GG_HOME

For 12c use the Oracle User Interface or the silent installation instructions.

For Goldengate 11g unzip and untar the binaries in the home directory on both SOURCE and TARGET.

Make sure you are in the GG_HOME directory.

$cd $GG_HOME
$pwd
$unzip V5165437.zip
$untar ggg-name.tar

Create the subdirectories using the ggsci command.

ggsci>create subdirs

Prepare for DDL Replication

The script below needs to be run on the source database, to create the procedure, trigger and table to capture the
DDL statements. In Oracle database 12c, DDL replication does not require any setup of triggers as it is natively
supported at the database level. So if you are setting up Goldengate on a 12c SOURCE database this section
can be skipped.

a. Navigate to the directory where the Oracle Goldengate software is installed.

b. Connect to the Oracle database as sysdba.

 6

SQL> sys/password as sysdba

c. For DDL synchronization setup, run the marker_setup.sql script. Provide OGG_USER schema name and
tablespace name, when prompted.

SQL> @marker_setup.sql

d. Then run the ddl_setup.sql script. Provide the setup detail information below.

SQL> @ddl_setup.sql
Start the installation : yes
Schema Name : OGG_USER
Installation mode : initialsetup

e. Run the role_setup.sql script. Provide OGG_USER schema name, when prompted.
SQL> @role_setup.sql

f. Then grant the ggs_ggsuser_role to the OGG_USER.

SQL> grant ggs_ggsuser_role to OGG_USER;

g. Run the ddl_enable.sql & ddl_pin.sql script

SQL> @ddl_enable;
SQL> @ddl_pin OGG_USER;

Configure Goldengate Manager Process

The Goldengate Manager is the very first processes that needs to be setup in the replication configuration. This
process must be running on the source and the target system and is required to be able to configure and start the
other Goldengate processes. It also manages the disk space by purging the old trail files periodically. Only one
manager process is required for every Goldengate installation.

Configuring the Goldengate Manager Process

Manager Parameter file

A simple configuration file mgr.prm, is required to start up the process. All parameter files are placed in the
$GG_HOME/dirprm directory. The GG_HOME is the home directory where Goldengate binaries are installed
and dirprm was created in the pre-requisites phase by issuing CREATE SUBDIRS.

Below are the parameters which can be set in the mgr.prm file.

PORT 7810
AUTORESTART ER *, RETRIES 3, WAITMINUTES 3, RESETMINUTES 10
PURGEOLDEXTRACTS ./dirdat/*, USECHECKPOINTS
 7

LAGCRITICALMINUTES 5
LAGREPORTMINUTES 60
LAGINFOMINUTES 0

PARAMETER DESCRIPTION

PORT The default manager port is 7809.

AUTORESTART ER Restarts the crashed processes

RETRIES Number of restarts attempts

PURGEOLDEXTRACTS Purges the old trail files to manage the disk space

Warning logged in the error log when lag threshold

LAGCRITICALMINUTES
exceeded

Information logged in the error log when lag threshold

LAGINFOMINUTES
exceeded

Time interval after which manager process checks the

LAGREPORTMINUTES
processes for lag

Starting Manager
To manually start up the process the following command can be run from the ggsci prompt.

ggsci> start manager

Stopping Manager
In ggsci type the below command to stop the manager process.
ggsci> stop manager
The above command asks for your confirmation. Type y and press enter.

Advanced Manager Commands

The manager component is the key process which is responsible to manage the other process in the Goldengate
environment. To effectively manage this manager process, a list of the must know commands are below.

START/STOP Manager

This command is used to start or stop the manager process. Before this process can be stopped all other
dependant processes should be stopped.

GGSCI (ggsdb01) 2> stop manager

Manager process is required by other GGS processes.
Are you sure you want to stop it (y/n)? y

Sending STOP request to MANAGER ...

Request processed.
Manager stopped.

GGSCI (ggsdb01) 3> start manager

 8

Manager started.

STATUS Manager
These provide the current status of the Manager process.

GGSCI (ggsdb01) 1> status manager

Manager is running (IP port ggsdb01.7833).

INFO Manager
GGSCI (ggsdb01) 4> Info manager
Manager is running (IP port ggsdb01.7833).

GGSCI (ggsdb01) 5> Info mgr

Manager is running (IP port ggsdb01.7833).

GGSCI (ggsdb01) 6> refresh manager

Sending REFRESH request to MANAGER ...

GGSCI (ggsdb01) 7> view report MGR

SEND Manager

The SEND command refresh the output directly from memory and show the current state after refreshing.

GGSCI (ggsdb01) 7> send manager childstatus debug

Sending CHILDSTATUS, request to MANAGER ...

Child Process Status - 9 Entries

ID Group Process Retry Retry Time Start Time Port

---- -------- --------- ----- ------------------- ------------------- ----
0 PVST1 3530 0 None 2013/04/26 12:10:49 7840
1 PAH01 3512 0 None 2013/04/26 12:10:49 7841
2 PTAN1 8166 0 None 2013/04/26 12:10:49 7849
3 PSSO1 3474 0 None 2013/04/26 12:10:49 7842
4 XVST1 14237 0 None 2013/04/26 12:10:49 7843
5 XAH01 14842 0 None 2013/04/26 12:10:49 7844
6 XTAN1 5930 0 None 2013/04/26 12:10:49 7847
7 XSSO1 4847 0 None 2013/04/26 12:10:49 7845
8 RVST1 14854 0 None 2013/04/26 12:10:49 7846

SEND GETPORTINFO

This provides the ports open and being used by the Goldengate processes including the Extract, Pump and
Replicat processes.

GGSCI (ggsdb01) 9> send manager getportinfo detail

Sending GETPORTINFO, request to MANAGER ...

Dynamic Port List

 9

Starting Index 0
Entry Port Error Process Assigned Program
----- ----- ----- ---------- ------------------- -------
0 15010 0
1 15011 0
2 15012 0
3 15013 0
4 15014 0
5 15015 0
6 15016 0
7 15017 0
8 15018 0
9 15019 0
10 15020 0

SEND GETPURGEOLDEXTRACTS

This provides info on the trail files that may qualify for purging, for all processes managed by the Manager
process.

GGSCI (ggsdb01) 10> send manager getpurgeoldextracts

Sending GETPURGEOLDEXTRACTS request to MANAGER ...

PurgeOldExtracts Rules
Fileset MinHours MaxHours MinFiles MaxFiles UseCP
/u01/VST/ggs/dirdat/* 1 0 1 0 Y
OK
Extract Trails
Filename Oldest_Chkpt_Seqno IsTable IsVamTwoPAHseCommit
/u01/VST/ggs/dirdat/p3 3
/u01/VST/ggs/dirdat/pb 2
/u01/VST/ggs/dirdat/p2 1
/u01/VST/ggs/dirdat/xd 6
/u01/VST/ggs/dirdat/xa 14
/u01/VST/ggs/dirdat/pa 3
/u01/VST/ggs/dirdat/xn 0
/u01/VST/ggs/dirdat/pn 0
/u01/VST/ggs/dirdat/xs 8
/u01/VST/ggs/dirdat/p1 1

Monitoring and Alerting MGR process

After starting the MGR you can place the alerting to make sure you know if the process goes down. Simply
place script in the crontab or another scheduler to be executed at the interval that best fits your needs.

Classical Extract Process

 10

The Goldengate Extract process captures committed transactions from the Oracle Redo Logs or the
Archived Logs. The Extract process writes the captured source data into a file known an EXTTRAIL
file. The extract process uses the checkpoints to mark the read and write positions to track the location
up to which the data has been extracted at any given time. This information is used to determine the
starting point in case of a failure.

Configure Goldengate Extract Process

Extract Parameter File

The ESRC01.prm parameter file is used to create the extract process and is stored in the
$GG_HOME/dirprm directory. The GG_HOME is the home directory where Goldengate binaries are
installed and dirprm was created in the pre-requisites phase by issuing CREATE SUBDIRS.

EXTRACT ESRC01
USERID OGG_USER PASSWORD OGG_USER
EXTTRAIL ./dirdat/st
TRANLOGOPTIONS EXCLUDEUSER OGG_USER
TRANLOGOPTIONS DBLOGREADER
TRANLOGOPTIONS BUFSIZE 4096000
TRANLOGOPTIONS DBLOGREADERBUFSIZE 4096000
TABLE APP_TEST.*;

The parameters used in the extract prm file are briefly explained below.

PARAMETER DESCRIPTION

EXTRACT Extract process name

USERID Database username for Goldengate

EXTTRAIL Name of the extract file to be created

TRANLOGOPTIONS Specific directives while mining transactions

DBLOGREADER New ASM API to extract data

Max bytes of memory allocated to read redo data

BUFSIZE
Increases Capture Speed

DBLOGREADERBUFSIZE Increases Maximum read size for ASM

TABLE Specify the SCHEMA and TABLE to extract data for

Adding Extract Process

 11

Add the extract to Goldengate and attach a trailfile directory and the trail name to it. At the ggsci
prompt run the commands. Make sure to connect to the database.
ggsci>DBLOGIN USERID OGG_USER PASSWORD OGG_USER
ggsci>ADD EXTRACT ESRC01, TRANLOG, BEGIN NOW
ggsci>ADD EXTTRAIL ./dirdat/st, EXTRACT ESRC01, megabytes 50

Here st is the starting 2 characters of the name of the Exttrail file to be created. Only a maximum of
two characters can be specified. MEGABYTES 50 is the maximum size of the exttrail.

Starting Extract
After adding the extract process, start the extract process. While the process is being added tail(look)
the output in the ggserror.log to nsure no errors are written to it.

ggsci> start ESRC01

Here ESRC01 is the name of the extract.

Status of Extract
In ggsci type the below command to check the status of the Golden gate extract process.

ggsci> info ESRC01

ggsci> view report ESRC01
ggsci> stats extract ESRC01

This command shows the display the status, row counts and details of data processed by the extract
process.

View Trailfile
Go to the dirdat directory which was specified in the extract parameter file. You should see the trail
file growing in size as extracted data is extracted from the redo logs and written there.

ls -lrt dirdat/st*

Stopping Extract
Run the command below to stop the extract process.
ggsci> stop ESRC01

Delete Extract
In case the Extract process needs to be deleted, you can run the DELETE EXTRACT .. to remove
the extract process. However, before you can delete the processes make sure that you connect to the
database to remove the process entry from the database.

ggsci>DBLOGIN USERID OGG_USER PASSWORD OGG_USER

ggsci> DELETE EXTRACT ESRC01

Configure Oracle Goldengate PUMP Process

 12

The Oracle Goldengate Pump process is responsible for reading the data from the local EXTTRAIL trail file
(the file with data captured by extract process) and writing the data to the target system. The Pump process is an
optional component of the replication mechanism and its main benefit is its usefulness in ensuring robustness in
the replication configuration when there is a system or network failure. The following are the steps required to
configure the Oracle Goldengate Pump Process.

Creating Oracle Goldengate PUMP Process

PUMP Parameter File

The PSRC01.prm parameter file is used to create the PUMP process and is stored in the $GG_HOME/dirprm
directory.The GG_HOME is the home directory where the Goldengate binaries are installed and dirprm was
created in the pre-requisites phase by issuing CREATE SUBDIRS.
cat dirprm/PSRC01.prm
EXTRACT PSRC01
RMTHOST ggdb02, MGRPORT 7800, TIMEOUT 30
RMTTRAIL /u01/app/ggs/dirdat/ps
PASSTHRU
TABLE app_test.*;

Below is the description of the parameters used in the parameter file.

PARAMETER DESCRIPTION

RMTHOST Target host name

MGRPORT Port number of Manager running on target side

COMPRESS Used to compress the RMTTRAIL file

RMTTRAIL Location and prefix of file to be created on the target system

PASSTHRU No connection to the database is used

TABLE Data is extracted for only the schema.table name specified

Add PUMP Process

From the directory where Oracle Goldengate software is installed, go to the Goldengate command prompt or
ggsci. At the ggsci prompt, run the commands as shown below.

GGSCI (ggdb01) 1> dblogin USERID ggsuser, password ggsuser

Successfully logged into the database.
GGSCI (ggdb01) 2> add extract PSRC01, EXTTRAILSOURCE
/u01/app/ggs/dirdat/xs, begin NOW
EXTRACT added.
 13

GGSCI (ggdb01) 3> add rmttrail /u01/app/ggs/dirdat/ps,extract PSRC01,

megabytes 50
RMTTRAIL added.

EXTTRAILSOURCE used to describe the location and prefix for EXTTRAIL file, from where the pump process
will read the data changes like . /dirdat/ is the EXTTRAIL path and ST is the prefix of EXTTRAIL file.

RMTTRAIL file which contains the data changes that the pump reads from the extracts EXTTRAIL and writes
to the target system like . /dirdat/ is the location on target system and TT is the prefix for RMTTRAIL file
to be created.

Starting PUMP

In ggsci type the below command to start the PSRC01 pump process.
GGGSCI (ggdb01) 4> start PSRC01

Sending START \request to MANAGER ...

EXTRACT PSRC01 starting

Status of PUMP

In ggsci type the below command to check the status of the Pump process.

GGSCI (ggdb01) 5> info PSRC01

EXTRACT PSRC01 Last Started 2013-04-25 11:29 Status RUNNING
CheckpoSRC Lag 00:00:00 (updated 00:00:08 ago)
Log Read CheckpoSRC File /u01/app/ggs/dirdat/xs000004
2013-04-25 11:28:57.000000 RBA 43924453
GGSCI (ggdb01) 6> info all
Program Status Group Lag at Chkpt Time Since Chkpt
MANAGER RUNNING
EXTRACT RUNNING PSRC01 00:00:00 00:00:04
EXTRACT RUNNING ESRC1 00:00:00 00:00:11

GGSCI (ggdb01) 7> view report PSRC01

This command shows the display the status for the Pump process.

Stopping PUMP

In ggsci type the below command to stop the Pump process.

ggsci> stop PSRC01

Source ggserror.log
Similar content will be seen in the Goldengate alert log on the source when the Extract process is added.
2013-04-25 11:28:57 INFO OGG-00987 Oracle Golden gate Command SRCerpreter for Oracle: GGSCI command
(oracle): add extract PSRC01 EXTTRAILSOURCE /u01/app/ggs/dirdat/xs, begin now.
2013-04-25 11:29:02 INFO OGG-00987 Oracle Golden gate Command SRCerpreter for Oracle: GGSCI command
(oracle): add rmttrail /u01/app/ggs/dirdat/ps extract PSRC01, megabytes 50.
2013-04-25 11:29:07 INFO OGG-00987 Oracle Golden gate Command SRCerpreter for Oracle: GGSCI command
(oracle): start PSRC01.
2013-04-25 11:29:07 INFO OGG-00963 Oracle Golden gate Manager for Oracle, mgr.prm: Command received
from GGSCI on host ggdb01.vst.com:35255 (START EXTRACT PSRC01 ).
 14

2013-04-25 11:29:07 INFO OGG-00992 Oracle Golden gate Capture for Oracle, PSRC01.prm: EXTRACT PSRC01
starting.
2013-04-25 11:29:07 INFO OGG-03035 Oracle Golden gate Capture for Oracle, PSRC01.prm: Operating system
character set identified as US-ASCII. Locale: en_US_POSIX, LC_ALL: C.
2013-04-25 11:29:07 INFO OGG-01815 Oracle Golden gate Capture for Oracle, PSRC01.prm: Virtual Memory
Facilities for: COM
anon alloc: mmap(MAP_ANON) anon free: munmap
file alloc: mmap(MAP_SHARED) file free: munmap
target directories:
/u01/app/ggs/dirtmp.
2013-04-25 11:29:09 WARNING OGG-01842 Oracle Goldengate Capture for Oracle, PSRC01.prm: CACHESIZE PER
DYNAMIC DETERMINATION (2G) LESS THAN RECOMMENDED: 64G (64bit system)
vm found: 3.94G
Check swap space. Recommended swap/extract: 128G (64bit system).
2013-04-25 11:29:09 INFO OGG-01014 Oracle Goldengate Capture for Oracle, PSRC01.prm: Positioning with
begin time: Apr 25, 2013 11:28:57 AM, starting record time: Apr 25, 2013 10:41:45 AM at extseqno 4,
extrba 43924453.
2013-04-25 11:29:09 INFO OGG-00993 Oracle Goldengate Capture for Oracle, PSRC01.prm: EXTRACT PSRC01
started.
2013-04-25 11:29:12 INFO OGG-00975 Oracle Goldengate Manager for Oracle, mgr.prm: EXTRACT PSRC01
starting.
2013-04-25 11:29:19 INFO OGG-01226 Oracle Goldengate Capture for Oracle, PSRC01.prm: Socket buffer
size set to 27985 (flush size 27985).
2013-04-25 11:29:19 INFO OGG-01052 Oracle Goldengate Capture for Oracle, PSRC01.prm: No recovery is
required for target file /u01/app/ggs/dirdat/ps000000, at RBA 0 (file not opened).
2013-04-25 11:29:19 INFO OGG-01478 Oracle Goldengate Capture for Oracle, PSRC01.prm: Output file
/u01/app/ggs/dirdat/ps is using format RELEASE 11.2.

Target ggserror.log
This message is seen in the ggserror.log when the pump process on the source is started and initiates a connection to the collector process on the target.
2013-04-25 14:26:17 INFO OGG-01229 Oracle Goldengate Collector for Oracle: Connected to
ggdb01.vst.com:35373.
2013-04-25 14:26:17 INFO OGG-01669 Oracle Goldengate Collector for Oracle: Opening
/u01/app/ggs/dirdat/ps000000 (byte -1, current EOF 0).

Configure Goldengate REPLICAT Process

The Goldengate Replicat process also known as the apply process, is a mandatory process in the Goldengate
setup. This data delivery process is the last component to be setup on the target database. It reads the data from
a file known an EXTTRAIL file which contains data changes made on the source. In addition to applying the
data on the target, the Goldengate replicat also posts its exact location of the trail file while processing records.
This is used for recovery from crashes, allowing it to start from the exact point where it left off, without any
data loss.

Configure Golden Gate Oracle Replication (REPLICAT)

REPLICAT Parameter File

Below is the example of the Goldengate Replicat parameter file. This file in usually placed in the
$GG_HOME/dirprm directory. The GG_HOME is the home directory where Goldengate binaries are installed
and dirprm was created in the pre-requisites phase by issuing CREATE SUBDIRS.
REPLICAT RWHS01
ASSUMETARGETDEFS
USERID OGG_USER PASSWORD hsdgeh#die4fsG
DISCARDFILE ./dirrpt/rprt.dsc, PURGE
DDL INCLUDE ALL
MAP APPSRC01.*, TARGET APPTAR01.*

The parameters above used in the Oracle Replicat parameter file, have been explained below.
 15

PARAMETER DESCRIPTION

REPLICAT Name of the Replicat Process

Used to identify that the column structure of the SOURCE

ASSUMETARGETDEFS
and TARGET tables in the MAP statement are identical

USERID Login details for the Goldengate Database user

This file contains data records that caused an error

DISCARDFILE
while they are written to the TARGET databas

DDL INCLUDE This parameter is used to ensure that the scope of the
MAPPED DDL transaction is of mapped scope only

Used to map SOURCE and TARGET schema. In this example

MAP & TARGET the source schema name is APPSRC01 and the target schema
is APPTAR01

Add REPLICAT
At the GGSCI prompt in the Golden gate home directory the following commands need to be run.
GGSCI> DBLOGIN USERID OGG_USER PASSWORD hsdgeh#die4fsG
GGSCI> ADD CHECKPOINTTABLE OGG_USER.ggschkpt
GGSCI> ADD REPLICAT RWHS01, EXTTRAIL ./dirdat/ps, BEGIN NOW,
CHECKPOINTTABLE OGG_USER.ggschkpt

The DBLOGIN is used to login into the database. The EXTTRAIL parameter is used to specify the location and
prefix of the EXTTRAIL file from where the Replicat process will read the data changes. Here ./dirdat/ is the
EXTTRAIL path and tt is the prefix of EXTTRAIL file.

Start REPLICAT
In ggsci type the below command to start the Replicat process.
ggsci> start RWHS01

Here RWHS01 is the name of the Replicat process.

Status of REPLICAT
In ggsci type the below command to check the status of the Replicat process.
ggsci> info RWHS01

ggsci> view report RWHS01

This command shows the display the status for the Replicat process.

Stopping REPLICAT
In ggsci type the command below to stop the Goldengate replicat process.
 16

ggsci> stop RWHS01

Delete REPLICAT
In ggsci type the command below to delete the Goldengate replicat process.
ggsci> delete RWHS01

When is the Oracle Goldengate HANDLECOLLISIONS parameter useful?

The Goldengate HANDLECOLLISIONS parameter is configured on the target database in the Replicat process
to enable processing of the data when there are duplicate data integrity issues in the destination database.

There could be a number of reasons which could cause this condition. Some of them include the following.

The table data was instantiated at a particular CSN in the

destination database but the Replicat process was started at a CSN
prior table load CSN. This causes an overlap.
Duplicate data exists in the source table.
Misconfiguration of the extract or Replicat configuration

The HANDLECOLLISIONS parameter is utilized when there is a possibility of an overlap of the trail data
being applied by the Replicat process to the destination database. Without the use of this parameter, the Replicat
will ABEND when it tries to process the inserts from the trail into the table which already has the rows (PK or
unique constraint violation).

It will also ABEND when the Replicat tries updating or deleting rows which are not present in the destination
tables. To overcome this normally the RBA of the trail has to be moved forward one transaction before the
Replicat can be restarted and will stay running.

The following is the behavior of the Replicat process when the Goldengate HANDLECOLLISIONS parameter
is enabled.

On On
Condition Action
Source Target

Converted to
INSERTS INSERTS Duplicate INSERTS
UPDATES

Updated in source but row not present

UPDATES UPDATES Ignored
in target

Deleted in source but row not present

DELETES DELETES Ignored
in target
 17

How do you apply rows which would normally fail on target?

To capture rows which are either duplicate INSERTS or do not exist in the destination to be updated or deleted,
REPERROR can be used to record these rows into a discard file.

In the example below, the REPERROR (1403, Discard) parameter is used to identify a condition when the row
the Replicat is looking for, is not present in the destination database.

Similarly, the REPERROR (0001, Discard) is raised when a duplicate INSERT is attempted but it violates a PK
or unique value key as the row is already present in the table.

Replicat rep02
USERID gg_user, PASSWORD DCJINAREOFHCTHCHVGNATACHGAKHICHEPDXG, ENCRYPTKEY
key1
ASSUMETARGETDEFS
DISCARDFILE /u01/app/ha/ggs/dirrpt/rep02.dsc, APPEND, MEGABYTES 1024
DBOPTIONS SUPPRESSTRIGGERS
DDLOPTIONS UPDATEMETADATA, REPORT
REPERROR (0001, DISCARD)
REPERROR (1403, DISCARD)

This is how the Replicat will behave in during the different scenarios.

Source Target Error message

Send to discard file when it

Unique constraint
Duplicate inserts comes across REPERROR (0001
violation.
Discard)

Updated in source but Send to discard file when it

row not present at comes across REPERROR (1403 No data found
target Discard)

Deleted in source but Send to discard file when it

row not present at comes across REPERROR (1403 No data found
target Discard)

How can we enable HANDLECOLLISIONS for only one table?

Firstly, as discussed above the Goldengate HANDLECOLLISIONS should be used only when and where necessary.

It should be removed from the Oracle Goldengate Replication configuration as soon as possible.
 18

Secondly if it has to be enabled, it should only be done so ONLY for tables requiring this.

This can be achieved by using HANDLECOLLISION, but by listing the specific tables and then turning it off using the
NOHANDLECOLLISIONS clause for the remaining tables, as shown below.

Enabling HANDLECOLLISIONS
Set Globally

Enable global HANDLECOLLISIONS for ALL MAP statements

HANDLECOLLISIONS
MAP vst.inventory, TARGET vst.inventory;
MAP vst.trans_hist, TARGET vst.trans_hist;
MAP vst.trans, TARGET vst.trans;
MAP vst.orders, TARGET vst.orders;

Set for Group of MAP Statements

Enable HANDLECOLLISIONS for some MAP statements

HANDLECOLLISIONS
MAP vst.inventory, TARGET vst.inventory;
MAP vst.trans_hist, TARGET vst.trans_hist;
NOHANDLECOLLISIONS
MAP vst.trans, TARGET vst.trans;
MAP vst.orders, TARGET vst.orders;

Set for Specific Tables

Enable global HANDLECOLLISIONS but disable for specific tables

HANDLECOLLISIONS
MAP vst.inventory, TARGET vst.inventory;
MAP vst.trans_hist, TARGET vst.trans_hist;
MAP vst.trans, TARGET vst.trans, NOHANDLECOLLISIONS;
MAP vst.orders, TARGET vst.orders, NOHANDLECOLLISIONS;

Don't forget to remove the HANDLECOLLISIONS parameter after the Replicat has moved
past the CSN where it was abending previously.

Also make sure to restart the Replicat after the removing this parameter.

How would the Replicat behave when a DDL or DML transaction is run on the source database but the
equivalent table does not exist on the target database?

If the table is not found in the target database, the Replicat process will ABEND.

What options do you have if you are required to resume data processing immediately to the existing
tables?
 19

One way to get around this issue is to either create the required table in the target database or skip this
transaction altogether.

This article deals with the skipping of such records which are in the trail file but cannot be processed on the
target.

Skipping of the transactions can be achieved using one of the following methods.

Reset RBA using Logdump

SKIPTRANSACTION Parameter
HANDLECOLLISIONS Parameter
Exceptional handling
Using logdump

Here we skip the transaction that caused the error, by re-starting the Replicat from the next non-erroneous
transaction position, by moving forward the RBA in the trail file.

Using the logdump we first identify the next transaction number, then we use this information to reset the
Replicat to the new starting position (RBA) in the trail file.

Here is how to work around the problematic transaction.

1. Using GGSCI first determine the Replicat details.

ggsci> INFO REPLICAT rep_trg DETAIL

2. From the output above, get the filename and path.

Here the last two digits of the file name represents the Sequence Number. for example:

/u01/oracle/goldengate/dirdat/se000005

3. Also note down the RBA of the OGG trail file. This is the current location of the Replicat process where it is
failing.

4. Then using logdump open up the trail file.

logdump>open /u01/oracle/goldengate/dirdat/se000005

5. Go to the RBA noted above.

logdump>pos <<RBA>>
 20

6. To identify the next RBA, enter n at the logdump prompt. Run this command again if the RBA shown is
the same as the one noted earlier.
logdump>n

Assume the noted RBA as X.

7. Now issue the following command from ggsci to set the new RBA.

By moving the Replicat to the new RBA, the Replicat process will start processing trail data from this point
onward.

ggsci>ALTER REPLICAT rep_trg extseqno <<SEQNO>> extrba X

8. Then startup the Replicat process.

If the error still persists, check the RBA with the command given in step 1. If it is X, it means that the next
transaction is also erroneous.

Repeat the steps 6-8, till the Replicat runs successfully by moving the trail file position to the next position.

If all the RBA in file is corrupt then use next available trail using the STEP 2.

SKIPTRANSACTION
The START REPLICAT SKIPTRANSACTION command causes the Replicat to start the processing of the
records in the trail file by skipping the current erroneous transaction. It is used to specify the next logical
recovery position, after the error.

With this the Replicat is re-positioned, to skip the erroneous transaction or transactions, with the understanding
that the skipped error will not be Replicated to the target.

1. Use the command as given in the below example:

ggsci>START REPLICAT rep_trg SKIPTRANSACTION

HANDLECOLLISIONS

This HANDLECOLLISIONS parameter is used for the automatic handling of Replicat errors.

The purpose of this option is to make sure the Replicat is able to keep on running with the understanding that
the records may be skipped or some data might not be Replicated.
 21

Use the HANDLECOLLISIONS by using either of the following methods:

1. Turn on the Handle collisions option for REPLICAT, from GGSCI prompt.

ggsci>SEND REPLICAT rep_trg, HANDLECOLLISIONS

2. Mention the HANDLECOLLISIONS parameter in the Replicat parameter file. As shown in the below
example:

ggsci>HANDLECOLLISIONS MAP src.tbl_t1, TARGET hr.tbl_t1;

Apply this parameter at the end of the Replicat file, along with other map statements.

Also after the successful replication of the data, we need to remove this parameter or disable the
HANDLECOLLISIONS parameter.

Disable the HANDLECOLLISIONS by using either of the following methods:

1. Turn off the Handle collisions option for REPLICAT, from GGSCI prompt.

ggsci>SEND REPLICAT rep_trg, NOHANDLECOLLISIONS

2. Remove the HANDLECOLLISIONS parameter from the Replicat parameter file, that we added in the
previous steps.

Exceptional handling
This method involves the mapping of the erroneous transaction to a separate table, so that the rather than
ignoring the transaction we can save its information for review.

1. Create the required table in the schema used for goldengate, with the below command.

CREATE TABLE tabExceptions

(
ID varchar2(100),
GroupName varchar2(8),
TableName varchar2(61),
ErrorNo number,
dbErrorMsg varchar2(4000),
optype varchar2(20),
Errtype varchar2(20),
logrba number,
logposition number,
committimestamp timestamp );

2. Create the primary key on that table.

sqlplus>ALTER TABLE tabExceptions ADD (

 22

CONSTRAINT PK_CTS PRIMARY KEY

(logrba, logposition, committimestamp));

3. To make sure the added table is excluded from DDL replication. Add the name of the table in DDL exclude
parameter as shown in example.

DDL INCLUDE ALL, EXCLUDE OBJNAME tabExceptions

4. To add the exception handling feature in oracle goldengate use the below parameter as shown in example.

REPERROR (default, EXCEPTION)

5. Add the following parameters after the map statement in Replicat file. As shown in below example.

With these parameters we will map the tablename, error number, error message, operation type error type, time
etc. Also most importantly replace the [primary key] with primary key column name, [schemaName] with
replicating schema, [tableName] with the name of the replicating table and [processName] with the replicat
name.

MAP [statement];[codenew] INSERTALLRECORDS

MAP [SchemaName].[TableName], TARGET tabExceptions,
EXCEPTIONSONLY,
COLMAP (
USEDEFAULTS,
ID = [primary key],
GroupName = [ProcessName],
ErrorNo = @GETENV (lasterr, dberrnum),
TableName=@GETENV (ggheader, tablename),
dbErrorMsg = @GETENV (lasterr, dberrmsg),
optype = @GETENV (lasterr, optype),
errtype = @GETENV (lasterr, errtype),
logrba = @GETENV (ggheader, logrba),
logposition=@GETENV (ggheader,logposition),
committimestamp = @GETENV (ggheader, committimestamp)
),
INSERTALLRECORDS,
EXCEPTIONSONLY;

6. Then after running the Replicat all the error transactions are saved in this table.

These steps allow the Replicat to continue processing the other trail records.

Open Database Transactions Effecting Oracle Golden Gate

Oracle Golden Gate Replication will not propagate transactions to the destination which have NOT been
committed on the source yet. However, Oracle Golden gate will write the open transaction data to the dirtemp
directory in the home directory. This data will then be read back later when the transaction is committed and
needs to be propagated to the destination. This is especially true when bulk transactions are run, processing a
large account of the uncommitted data, which then has to be written temporarily to the dirtemp location.
 23

In cases such as this and others you may need to investigate these open transactions which are awaiting a
commit. The script below will identify the SID, SCHEMANAME, etc providing info on these open
transactions. Also the USED_UBLK and UREC can be used to gauge the the amount of changes made by the
statement.

Open Database Transactions effecting GoldenGate Query

--------------------------------------------------------------------------
Open Database Transactions effecting GoldenGate
--------------------------------------------------------------------------
SET LINES 300
COL start_time FOR A20
COL sid FOR 99999
COL serial# FOR 999999
COL username FOR A20
COL status FOR A10
COL schemaname FOR A10
COL process FOR A10
COL machine FOR A15
COL program FOR A30
COL module FOR A35
COL logon_time FOR A20

SELECT t.start_time,s.sid,s.serial#,s.username,
s.status, s.schemaname, s.process,s.machine,
s.program, s.module, used_ublk, used_urec,
TO_CHAR(s.logon_time,'mon-dd-yyyy HH24:MI:SS') logon_time
FROM v$transaction t, v$session s
WHERE s.saddr = t.ses_addR
ORDER BY start_time;