4.1 GGSCI Command Interface

These are the GGSCI commands that you can use including examples.

Oracle GoldenGate GGSCI Commands

This file describes the commands that can be issued through the Oracle GoldenGate
Software Command Interface (GGSCI). This is the command interface between
users and Oracle GoldenGate functional components.

Summary of Manager Commands
Use the Manager commands to control the Manager process. Manager is the parent
process of Oracle GoldenGate and is responsible for the management of its processes
and files, resources, user interface, and the reporting of thresholds and errors.

Command Description
INFO MANAGER Returns information about the Manager port and process id.
SEND MANAGER Returns information about a running Manager process and optionally
child processes.
START MANAGER Starts the Manager process.
STATUS MANAGER Returns the state of the Manager port and process ID.
STOP MANAGER Stops the Manager process.

Summary of Extract Commands
Use the Extract commands to create and manage Extract groups. The Extract process
captures either full data records or transactional data changes, depending on configuration
parameters, and then sends the data to a trail for further processing by a downstream
process, such as a data-pump Extract or the Replicat process.

Command Description
ADD EXTRACT Creates an Extract group.
ALTER EXTRACT Changes attributes of an Extract group
CLEANUP EXTRACT Deletes run history for an Extract group
DELETE EXTRACT Deletes an Extract group.
INFO EXTRACT Returns information about an Extract group.
KILL EXTRACT Forcibly terminates the run of an Extract group.
LAG EXTRACT Returns information about Extract lag.
REGISTER EXTRACT Registers an Extract group with an Oracle database.
SEND EXTRACT Sends instructions to, or returns information about, a running
Extract group.
START EXTRACT Starts an Extract group.
STATS EXTRACT Returns processing statistics for an Extract group.
STATUS EXTRACT Returns the state of an Extract group.
STOP EXTRACT Stops an Extract group.
FORCEAPPEND Allows data pump to add new trail files on top of existing initial load files
UNREGISTER EXTRACT Unregisters an Extract group from an Oracle database.

Summary of Replicat Commands
Use the Replicat commands to create and manage Replicat groups. The Replicat
process reads data extracted by the Extract process and applies it to target tables
or prepares it for use by another application, such as a load application.

Command Description
ADD REPLICAT Adds a Replicat group.
ALTER REPLICAT Changes attributes of a Replicat group.
CLEANUP REPLICAT Deletes run history of a Replicat group.
DELETE REPLICAT Deletes a Replicat group.
INFO REPLICAT Returns information about a Replicat group.
KILL REPLICAT Forcibly terminates a Replicat group.
LAG REPLICAT Returns information about Replicat lag.
REGISTER REPLICAT Registers a Replicat group with an Oracle database.
SEND REPLICAT Sends instructions to, or returns information about, a running
Replicat group.
START REPLICAT Starts a Replicat group.
STATS REPLICAT Returns processing statistics for a Replicat group.
STATUS REPLICAT Returns the state of a Replicat group.
STOP REPLICAT Stops a Replicat group.
SYNCHRONIZE REPLICAT Returns all threads of a coordinated Replicat to a uniform
start point after an unclean shutdown of the Replicat process.
UNREGISTER REPLICAT Unregisters a Replicat group from an Oracle database.

Summary of the ER Command
Use the ER command to issue standard Extract and Replicat commands to multiple
Extract and Replicat groups as a unit. See "ER" for how to use this command.

Command Description
INFO ER * Returns information about the specified wildcarded groups.
KILL ER * Forcibly terminates the specified wildcarded groups.
LAG ER * Returns lag information about the specified wildcarded groups
SEND ER * Sends instructions to, or returns information about, the
specified wildcarded groups.
START ER * Starts the specified wildcarded groups.
STATS ER * Returns processing statistics for the specified wildcarded
groups.
STATUS ER * Returns the state of the specified wildcarded groups.
STOP ER * Stops the specified wildcarded groups.

Summary of Wallet Commands
Use the wallet commands to manage the master-key wallet that stores Oracle GoldenGate
master encryptions keys, and to add master keys to this wallet.

Command Description
CREATE WALLET Creates a wallet that stores master encryption keys.
OPEN WALLET Opens a master-key wallet.
PURGE WALLET Permanently removes from a wallet the master keys that are
marked as deleted.
ADD MASTERKEY Adds a master key to a master-key wallet.
INFO MASTERKEY Returns information about master keys.
RENEW MASTERKEY Adds a new version of a master key.
DELETE MASTERKEY Marks a master key for deletion.
UNDELETE MASTERKEY Changes the state of a master key from being marked as deleted
to marked as available.

Summary of Credential Store Commands
Use the credential store commands to manage an Oracle GoldenGate credential store and
to add credentials to the credential store.

Command Description
ADD CREDENTIALSTORE Creates a credentials store (wallet) that stores encrypted
database user credentials.
ALTER CREDENTIALSTORE Changes the contents of a credentials store.
INFO CREDENTIALSTORE Returns information about a credentials store.
DELETE CREDENTIALSTORE Deletes the wallet that serves as a credentials store.

Summary of Trail Commands
Use the trail commands to create and manage Oracle GoldenGate trails. A trail is a series
of files in which Oracle GoldenGate temporarily stores extracted data on disk until it has
been applied to the target location.

Command Description

ADD EXTTRAIL Adds a local trail to the Oracle GoldenGate configuration.
ADD RMTTRAIL Adds a remote trail to the Oracle GoldenGate configuration.
ALTER EXTTRAIL Changes attributes of a local trail.
ALTER RMTTRAIL Changes attributes of a remote trail.
DELETE EXTTRAIL Removes a local trail from the Oracle GoldenGate configuration.
DELETE RMTTRAIL Removes a remote trail from the Oracle GoldenGate configuration.
INFO EXTTRAIL Returns information about a local trail.
INFO RMTTRAIL Returns information about a remote trail.

Summary of Parameter Commands
Use the parameter commands to view and manage Oracle GoldenGate parameter files.
See Administering Oracle GoldenGate for more information about how to work with parameter
files.

Command Description
EDIT PARAMS Opens a parameter file for editing in the default text editor.
SET EDITOR Sets the default text editor program for editing parameter files.
VIEW PARAMS Displays the contents of a parameter file in read-only mode on-screen.
INFO PARAM Returns parameter definition information.

Summary of Database Commands
Use the database commands to interact with the database from GGSCI.

Command Description
DBLOGIN Logs the GGSCI session into a database so that other commands that
affect the database can be issued.
DUMPDDL Shows the data in the Oracle GoldenGate DDL history table.
ENCRYPT PASSWORD Encrypts a database login password.
FLUSH SEQUENCE Updates an Oracle sequence so that initial redo records are
available at the time that Extract starts capturing transaction
data after the instantiation of the replication environment.
LIST TABLES Lists the tables in the database with names that match the input specification.
MININGDBLOGIN Specifies the credentials of the user that an Oracle GoldenGate process
uses to log into an Oracle mining database.
SET NAMECCSID Sets the CCSID of the GGSCI session in a DB2 for i environment.

Summary of Trandata Commands
Use trandata commands to configure the appropriate database components to provide the
transaction information that Oracle GoldenGate needs to replicate source data operations.

Command Description
ADD SCHEMATRANDATA Enables schema-level supplemental logging.
ADD TRANDATA Enables table-level supplemental logging.
DELETE SCHEMATRANDATA Disables schema-level supplemental logging.
DELETE TRANDATA Disables table-level supplemental logging.
INFO SCHEMATRANDATA Returns information about the state of schema-level
supplemental logging.
INFO TRANDATA Returns information about the state of table-level supplemental
logging.
SET_INSTANTIATION_CSN Sets whether and how table instantiation CSN filtering is used.
CLEAR_INSTANTIATION_CSN Clears table instantiation CSN filtering.

Summary of Checkpoint Table Commands
Use the checkpoint table commands to manage the checkpoint table that is used by Oracle
GoldenGate to track the current position of Replicat in the trail.
For more information about checkpoints and using a checkpoint table,
see Administering Oracle GoldenGate.

Command Description
ADD CHECKPOINTTABLE Creates a checkpoint table in a database.
CLEANUP CHECKPOINTTABLE Removes checkpoint records that are no longer needed.
DELETE CHECKPOINTTABLE Removes a checkpoint table from a database.
INFO CHECKPOINTTABLE Returns information about a checkpoint table.
UPGRADE CHECKPOINTTABLE Adds a supplemental checkpoint table when upgrading Oracle
GoldenGate from version 11.2.1.0.0 or earlier.

Summary of Oracle Trace Table Commands
Use the trace table commands to manage the Oracle GoldenGate trace table that is used
with bidirectional synchronization of Oracle databases. Replicat generates an operation
in the trace table at the start of each transaction. Extract ignores all transactions
that begin with an operation to the trace table. Ignoring Replicat's operations
prevents data from looping back and forth between the source and target tables.
For more information about bidirectional synchronization, see Administering
Oracle GoldenGate for Windows and UNIX

Command Description
ADD TRACETABLE Creates a trace table.
DELETE TRACETABLE Removes a trace table.
INFO TRACETABLE Returns information about a trace table.

Summary of Oracle GoldenGate Monitor JAgent Commands
Use the JAgent commands to control the Oracle GoldenGate Monitor JAgent.

Command Description
INFO JAGENT Returns information about the JAgent.
START JAGENT Starts the JAgent.
STATUS JAGENT Returns the state of the JAgent.
STOP JAGENT Stops the JAgent.

Summary of PMSRVR COMMANDS

Use the PMSRVR commands to control the Performance Metrics Server process. The
Performance Metrics Server uses the metrics service to collect and store
instance deployment performance results.

Command Description
INFO PMSRVR Returns information about the PMSRVR.
START PMSRVR Starts the PMSRVR.
STATUS PMSRVR Returns the state of the PMSRVR.
STOP PMSRVR Stops the PMSRVR.
START PMSRVR Starts the PMSRVR.
START MANAGER Starts the Manager.
START * Starts Extracts and Replicats.
Start JAGENT Starts the JAGENT

Summary of Oracle GoldenGate Automatic Heartbeat Commands
Use the heartbeat table commands to control the Oracle GoldenGate automatic
heartbeat functionality.

Command Description
ADD HEARTBEATTABLE Creates the objects required for automatic heartbeat functionality.
ALTER HEARTBEATTABLE Alters existing heartbeat objects.
DELETE HEARTBEATTABLE Deletes existing heartbeat objects.
DELETE HEARTBEATENTRY Deletes entries in the heartbeat table.
INFO HEARTBEATTABLE Displays heartbeat table information.

Summary of Procedural Replication Commands

Use the following commands to enable, delete or retrieve information about procedures
that have supplemental logging turned on.

Command Description
ADD PROCEDURETRANDATA Adding supplemental logging for Procedural Replication.
DELETE PROCEDURETRANDATA Remove supplemental logging for Procedural Replication.
INFO PROCEDURETRANDATA Display display supplemental logging information about Procedural Replication.

Summary of Miscellaneous Oracle GoldenGate Commands
Use the following commands to control various other aspects of Oracle GoldenGate.
Command Description

! Executes a previous GGSCI command without modifications.
ALLOWNESTED | NOALLOWNESTED Enables or disables the use of nested OBEY files.
CREATE SUBDIRS Creates the default directories within the Oracle GoldenGate home directory.
DEFAULTJOURNAL Sets a default journal for multiple tables or files for the ADD
TRANDATA command when used for a DB2 for i database.
FC Allows the modification and re-execution of a previously issued
Provides assistance with syntax and usage of GGSCI commands.
HISTORY Shows a list of the most recently issued commands since the
startup of the GGSCI session.
INFO ALL Displays status and lag for all Oracle GoldenGate processes on
a system.
OBEY Processes a file that contains a list of Oracle GoldenGate commands.
SHELL Executes shell commands from within the GGSCI interface.
SHOW Displays the attributes of the Oracle GoldenGate environment.
VERSIONS Displays information about the operating system and database.
VIEW GGSEVT Displays the Oracle GoldenGate error log (ggserr.logfile).
VIEW REPORT Displays the process report or the discard file that is generated
by Extract or Replicat.

---------------------------------------------------------------------
####################################
#
#MANAGER COMMANDS
#
#
####################################
----------------------------------------------------------------------
INFO MANAGER

Use INFO MANAGER(or INFO MGR) to determine whether or not the Manager process is
running and the process ID. If Manager is running, the port number is displayed. This
command is an alias for STATUS MANAGER.

Syntax
INFO MANAGER
INFO MGR

----------------------------------------------------------------------
SEND MANAGER

Use SEND MANAGER to retrieve the status of the active Manager process or to retrieve
dynamic port information as configured in the Manager parameter file.

Syntax
SEND MANAGER [CHILDSTATUS [DEBUG]]
[GETPORTINFO [DETAIL]
[GETPURGEOLDEXTRACTS]

CHILDSTATUS [DEBUG]

Retrieves status information about processes started by Manager. DEBUG returns the port
numbers that are allocated to processes.

GETPORTINFO [DETAIL]

By default, retrieves the current list of ports that have been allocated to processes
and their corresponding process IDs. DETAIL provides a list of all the ports defined
using the DYNAMICPORTLIST parameter.

GETPURGEOLDEXTRACTS

Displays information about trail maintenance rules that are set with the
PURGEOLDEXTRACTS parameter in the Manager parameter file. For more information, see
“PURGEOLDEXTRACTS”.

Examples

Example 1
SEND MANAGER CHILDSTATUS DEBUG returns a child process status similar to
the following. The basic CHILDSTATUS option returns the same display,
without the Port column.
ID Group Process Retry Retry Time Start Time
Port 1 ORAEXT 2400 0 None 2011/01/21 21:08:32
7840 2 ORAEXT 2245 0 None 2011/01/23 21:08:33 7842

Example 2
SEND MANAGER GETPORTINFO DETAIL returns a dynamic port list similar to the following.
Entry Port Error Process Assigned Program
0 8000 0 2387 2011-01-01 10:30:23
1 8001 0
2 8002 0

Example 3
SEND MANAGER GETPURGEOLDEXTRACTS outputs information similar to the following.
PurgeOldExtracts Rules Fileset MinHours MaxHours MinFiles MaxFiles UseCP
S:\GGS\DIRDAT\EXTTRAIL\P4\* 0 0 1 0 Y
S:\GGS\DIRDAT\EXTTRAIL\P2\* 0 0 1 0 Y
S:\GGS\DIRDAT\EXTTRAIL\P1\* 0 0 1 0 Y
S:\GGS\DIRDAT\REPTRAIL\P4\* 0 0 1 0 Y
S:\GGS\DIRDAT\REPTRAIL\P2\* 0 0 1 0 Y
S:\GGS\DIRDAT\REPTRAIL\P1\* 0 0 1 0 Y
OK
Extract Trails
Filename Oldest_Ch kpt_Seqno IsTable IsVamTwoPhaseCommit
S:\GGS\8020\DIRDAT\RT 3 0 0
S:\GGS\8020\DIRDAT\REPTRAIL\P1\RT 13 0 0
S:\GGS\8020\DIRDAT\REPTRAIL\P2\RT 13 0 0
S:\GGS\8020\DIRDAT\REPTRAIL\P4\RT 13 0 0
S:\GGS\8020\DIRDAT\EXTTRAIL\P1\ET 14 0 0
S:\GGS\8020\DIRDAT\EXTTRAIL\P2\ET 14 0 0
S:\GGS\8020\DIRDAT\EXTTRAIL\P4\ET 14 0 0

----------------------------------------------------------------------
START MANAGER

Use START MANAGER to start the Manager process. This applies to a non-clustered
environment. In a Windows cluster, you should stop Manager from the Cluster
Administrator.

Syntax
START MANAGER

----------------------------------------------------------------------
STATUS MANAGER

Use STATUS MANAGER to see if the Manager process is running and any associate
process ID. If Manager is running, the port number is displayed.

Syntax
STATUS MANAGER

----------------------------------------------------------------------
STOP MANAGER

Use STOP MANAGER to stop the Manager process. This applies to non-clustered
environments. In a Windows cluster, Manager must be stopped through the
Cluster Administrator.

Syntax
STOP MANAGER [!]

! (Exclamation point) Bypasses the prompt that confirms the intent to shut
down Manager.

Examples:

STOP MANAGER

STOP MANAGER !

----------------------------------------------------------------------
####################################
#
#EXTRACT COMMANDS
#
#
####################################

---------------------------------------------------------------------
ADD EXTRACT

Use ADD EXTRACT to create an Extract group. Unless a SOURCEISTABLE task or
an alias Extract is specified, ADD EXTRACT creates an online group that uses
checkpoints so that processing continuity is maintained from run to run.

For DB2 for i, this command establishes a overall start point for all journals
and is a required first step. After issuing the ADD EXTRACT command, you can
then optionally position any given journal at a specific journal sequence
number by using the ALTER EXTRACT command with an appropriate journal option.

Oracle GoldenGate supports up to 5,000 concurrent Extract and Replicat
groups per instance of Oracle GoldenGate Manager. At the supported level,
all groups can be controlled and viewed in full with GGSCI commands such
as the INFO and STATUS commands. Oracle GoldenGate recommends keeping the
combined number of Extract and Replicat groups at the default level of
300 or below in order to manage your environment effectively.

This command cannot exceed 500 bytes in size for all keywords and input,
including any text that you enter for the DESC option.

Syntax for a Regular, Passive, or Data Pump Extract

ADD EXTRACT group_name
{, SOURCEISTABLE |
, TRANLOG |
, INTEGRATED TRANLOG |
, VAM |
, EXTFILESOURCE file_name |
, EXTTRAILSOURCE trail_name |
, VAMTRAILSOURCE VAM_trail_name}
BEGIN {NOW | yyyy-mm-dd[ hh:mi:[ss[.cccccc]]]} |
EXTSEQNO sequence_number, EXTRBA relative_byte_address |
EOF |
LSN [value] |
bsds_name |
LRI_NUMBER |
EXTRBA relative_byte_address |
PAGE data_page, ROW row_ID |
SEQNO sequence_number
SCN value
THREADS [n]
PASSIVE
PARAMS file_name
REPORT file_name
DESC 'description'
SOCKSPROXY {host_name | IP_address}[:port] [PROXYCSALIAS credential_store_alias
[PROXYCSDOMAIN credential_store_domain]]]
RMTNAME passive_Extract_name]
DESC [description]
}

group_name

The name of the Extract group. The name of an Extract group can contain
up to eight characters. See for group naming conventions. See Administering
Oracle GoldenGate for group naming conventions.

SOURCEISTABLE

Creates an Extract task that extracts entire records from the database
for an initial load using the Oracle GoldenGate direct load method or
the direct bulk load to SQL*Loader method. If SOURCEISTABLE is not
specified, ADD EXTRACT creates an online change-synchronization process,
and one of the other data source options must be specified. When using
SOURCEISTABLE, do not specify any service options. Task parameters
must be specified in the parameter file.

For more information about initial load methods, see Administering Oracle
GoldenGate.

TRANLOG [bsds_name| LRI_NUMBER | EOF | BEGIN {NOW | yyyy-mm-dd[
hh:mi:[ss[.cccccc]]]}]

Specifies the transaction log as the data source. Use this option for all
databases. TRANLOG requires the BEGIN option.

(DB2 on z/OS) You can use the bsds_name option for DB2 on a z/OS system to
specify the Bootstrap Data Set file name of the transaction log, though it
is not required and is not used. You do not need to change existing TRANLOG
parameters.

(DB2 LUW) You can use the LRI_NUMBER option for DB2 LUW systems to specify
the LRI at which Extract can start capturing records from the transaction
log. You can use the DB2 utility db2logsForRfwd to obtain the LRI. This
utility provides LRI ranges present in the DB2 logs. Note that,
although Extract might position to a given LRI, that LRI might not
necessarily be the first one that Extract processes. There are
numerous record types in the log files that Extract ignores, such as
DB2 internal log records. Extract reports the actual starting LRI
to the Extract report file.

(Oracle) As of Oracle Standard or Enterprise Edition 11.2.0.3, this mode
is known as classic capture mode. Extract reads the Oracle redo logs
directly. See INTEGRATED TRANLOG for an alternate configuration.

INTEGRATED TRANLOG

(Oracle) Adds this Extract in integrated capture mode. In this mode, Extract
integrates with the database logmining server, which passes logical change
records (LCRs) directly to Extract. Extract does not read the redo log. Before
using INTEGRATED TRANLOG, use the REGISTER EXTRACT command. For information
about integrated capture, see the Oracle GoldenGate documentation for your database.

VAM

(MySQL and Teradata) Specifies that the Extract API known as the
Vendor Access Module (VAM) will be used to transfer change data to Extract.

EXTFILESOURCE file_name

Specifies an extract file as the data source. Use this option with a secondary
Extract group (data pump) that acts as an intermediary between a primary
Extract group and the target system.

For file_name, specify the relative or fully qualified path name of the file,
for example dirdat/extfile or c:\ggs\dirdat\extfile.

EXTTRAILSOURCE trail_name

Specifies a trail as the data source. Use this option with a secondary Extract
group (data pump) that acts as an intermediary between a primary Extract group
and the target system.

For trail_name, specify the relative or fully qualified path name of the trail,
for example dirdat/aa or c:\ggs\dirdat\aa.

BEGIN {NOW | yyyy-mm-dd[ hh:mi:[ss[.cccccc]]]}
Specifies a timestamp in the data source at which to begin processing.

NOW

For all databases except DB2 LUW, NOW specifies the time at which the
ADD EXTRACT command is issued.

For DB2 LUW, NOW specifies the time at which START EXTRACT takes effect. It
positions to the first record that approximately matches the date and time.
This is because the only log records that contain timestamps are the commit
and stop transaction records, so the starting position can only be calculated
relative to those timestamps. This is a limitation of the API that is used
by Oracle GoldenGate.

Do not use NOW for a data pump Extract except to bypass data that was captured
to the trail prior to the ADD EXTRACT statement.

yyyy-mm-dd[ hh:mi:[ss[.cccccc]]]

A date and time (timestamp) in the given form. For an Oracle Extract in
integrated mode, the timestamp value must be greater than the timestamp at
which the Extract was registered with the database.

* Positioning by timestamp in a SQL Server transaction log is affected by
the following characteristics of SQL Server:

– The timestamps recorded in the SQL Server transaction log use a 3.333
microsecond (ms) granularity. This level of granularity may not allow
positioning by time between two transactions, if the transactions began
in the same 3.333 ms time interval.

– Timestamps are not recorded in every SQL Server log record, but only in
the records that begin and commit the transaction, as well as some others
that do not contain data.

– SQL Server timestamps are not from the system clock, but instead are
from an internal clock that is specific to the individual processors in use.
This clock updates several times a second, but between updates it could get
out of sync with the system clock. This further reduces the precision of
positioning by time.

– Timestamps recorded for log backup files may not precisely correspond to
times recorded inside the backup (however this imprecision is less than a
second).

Positioning to an LSN is precise.

EXTSEQNO sequence_number, EXTRBA relative_byte_address

Valid for a primary Extract in classic capture mode for Oracle and a data pump
Extract. Not supported for an Oracle Extract in integrated mode. Specifies
either of the following:

* sequence number of an Oracle redo log and RBA within that log at which
to begin capturing data.

* the file in a trail in which to begin capturing data (for a data pump).
Specify the sequence number, but not any zeroes used for padding. For
example, if the trail file is c:\ggs\dirdat\aa000000026, you would specify
EXTSEQNO 26. By default, processing begins at the beginning of a trail
unless this option is used.

Contact Oracle Support before using this option. For more information, go to
http://support.oracle.com.

EXTRBA relative_byte_address

Valid for DB2 on z/OS. Specifies the relative byte address within a transaction
log at which to begin capturing data. The required format is 0Xnnn, where
nnn is a 1 to 20 digit hexadecimal number (the first character is the digit
zero, and the second character can be upper or lower case letter x).

EOF

Valid for SQL Server and DB2 for i. Configures processing to start at the end
of the log files (or journals) that the next record will be written to. Any
active transactions will not be captured.

LSN [value]

Valid for SQL Server. Specifies the LSN in a transaction log
at which to start capturing data. The specified LSN should exist in a log
backup or the online log. An alias for this option is EXTLSN.

For SQL Server, an LSN is composed of one of these, depending on how the
database returns it:

* Colon separated hex string (8:8:4) padded with leading zeroes and 0X prefix,
as in 0X00000d7e:0000036b:01bd

* Colon separated decimal string (10:10:5) padded with leading zeroes,
as in 0000003454:0000000875:00445

* Colon separated hex string with 0X prefix and without leading zeroes,
as in 0Xd7e:36b:1bd

* Colon separated decimal string without leading zeroes, as in 3454:875:445

* Decimal string, as in 3454000000087500445

In the preceding, the first value is the virtual log file number, the
second is the segment number within the virtual log, and the third is
the entry number. You can find the LSN for named transactions by using
a query like:
select [Current LSN], [Transaction Name], [Begin Time] from fn_dblog(null, null)
where Operation = 'LOP_BEGIN_XACT' and [Begin Time] = 'time'

The time format that you should use in the query should be similar to
'2015/01/30 12:00:00.000' and not '2017-01-30 12:00:00.000'.

You can determine the time that a particular transaction started, then find
the relevant LSN, and then position between two transactions with the same
begin time.

SEQNO sequence_number

Valid for DB2 for i. Starts capture at, or just after, a system sequence
number, which is a decimal number up to 20 digits in length.

SCN [value]

Valid for Oracle. Starts Extract at the transaction in the redo log
that has the specified Oracle system change number (SCN). This option
is valid for Extract both in classic capture and integrated modes. For
Extract in integrated mode, the SCN value must be greater than the SCN
at which the Extract was registered with the database. For more
information, see REGISTER EXTRACT.

PARAMS file_name

Specifies the full path name of an Extract parameter file in a location
other than the default of dirprm within the Oracle GoldenGate directory.

REPORT file_name

Specifies the full path name of an Extract report file in a location other
than the default of dirrpt within the Oracle GoldenGate directory.

THREADS [n]

Valid for Oracle classic capture mode. Specifies the number of producer
threads that Extract maintains to read redo logs.

Required in an Oracle RAC configuration to specify the number of producer
threads. These are the Extract threads that read the different redo logs
on the various RAC nodes. The value must be the same as the number of nodes
from which you want to capture redo data.

PASSIVE

Specifies that this Extract group runs in passive mode and can only be
started and stopped by starting or stopping an alias Extract group on
the target system. Source-target connections will be established not
by this group, but by the alias Extract from the target.

This option can be used for a regular Extract group or a data-pump
Extract group. It should only be used by whichever Extract on the
source system is the one that will be sending the data across the
network to a remote trail on the target.

For instructions on how to configure passive and alias Extract groups,
see Administering Oracle GoldenGate.

DESC 'description'

Specifies a description of the group, such as 'Extracts account_tab on
Serv1'. Enclose the description within single quotes. You may use the
abbreviated keyword DESC or the full word DESCRIPTION.

SOCKSPROXY{host_name| IP_address}[:port] [PROXYCSALIAS credential_store_alias
[PROXYCSDOMAINcredential_store_domain]

Use for an alias Extract. Specifies the DNS host name or IP address of the
proxy server. You can use either one to define the host though you must use
the IP address if your DNS server is unreachable. If you are using an IP
address, use either an IPv6 or IPv4 mapped address, depending on the stack
of the destination system. You must specify the PROXYCSALIAS. In addition,
you can specify the port to use, and the credential store domain.

RMTNAME passive_extract_name

Use for an alias Extract. Specifies the passive Extract name, if different
from that of the alias Extract.

Examples

Example 1

The following creates an Extract group named finance that extracts database
changes from the transaction logs. Extraction starts with records generated
at the time when the group was created with ADD EXTRACT.

ADD EXTRACT finance, TRANLOG, BEGIN NOW

Example 2

The following creates an Extract group named finance that extracts database
changes from Oracle RAC logs. Extraction starts with records generated at
the time when the group was created. There are four RAC instances, meaning
there will be four Extract threads.

ADD EXTRACT finance, TRANLOG, BEGIN NOW, THREADS 4

Example 3

The following creates an Extract group named finance that extracts database
changes from the transaction logs. Extraction starts with records generated
at 8:00 on January 21, 2011.

ADD EXTRACT finance, TRANLOG, BEGIN 2017-01-21 08:00

Example 4

The following creates an integrated capture Extract group.
ADD EXTRACT finance, INTEGRATED TRANLOG, BEGIN NOW

Example 5

The following creates an Extract group named finance that interfaces with
a Teradata TAM in either maximum performance or maximum protection mode.
No BEGIN point is used for Teradata sources.

ADD EXTRACT finance, VAM

Example 6

The following creates a data-pump Extract group named finance. It reads
from the Oracle GoldenGate trail c:\ggs\dirdat\lt.

ADD EXTRACT finance, EXTTRAILSOURCE dirdat/lt

Example 7

The following creates an initial-load Extract named load.

ADD EXTRACT load, SOURCEISTABLE

Example 8

The following creates a passive Extract group named finance that extracts
database changes from the transaction logs.

ADD EXTRACT finance, TRANLOG, BEGIN NOW, PASSIVE

Example 9

The following creates an alias Extract group named financeA. The alias
Extract is associated with a passive extract named finance on source system
sysA. The Manager on that system is using port 7800.

ADD EXTRACT financeA, RMTHOST sysA, MGRPORT 7800, RMTNAME finance

Example 10

The following examples create and position Extract at a specific Oracle
system change number (SCN) in the redo log.

ADD EXTRACT finance TRANLOG SCN 123456
ADD EXTRACT finance INTEGRATED TRANLOG SCN 123456

Example 11

The following example creates an alias Extract specifying the host to use.

ADD EXTRACT apmp desc "alias extract" RMTHOST lc01abc MGRPORT 7813 RMTNAME
ppmp SOCKSPROXY lc02def:3128 PROXYCSALIAS proxyAlias

Example 12

The following example creates an Extract on a DB2 LUW system.

ADD EXTRACT extcust, TRANLOG LRI 8066.322711

----------------------------------------------------------------------
ALTER EXTRACT

Use ALTER EXTRACT for the following purposes:

* To change the attributes of an Extract group created with the ADD
EXTRACT command.

* To increment a trail to the next file in the sequence.

* To upgrade to an integrated capture configuration.

* To downgrade from an integrated capture configuration.

* To position any given IBM for i journal at a specific journal
sequence number.

* To position an Extract for SQL Server to begin at a specific LSN.

Before using this command, stop Extract with the STOP EXTRACT
group_name command.

Syntax

ALTER EXTRACT group_name
[ADD_EXTRACT_attribute]
[TRANLOG LRI_number]
[UPGRADE INTEGRATED TRANLOG]
[DOWNGRADE INTEGRATED TRANLOG [THREADS number]]
[THREAD number]
[LSN value]
[SCN value]
[ETROLLOVER]

The following ALTER EXTRACT options are supported for DB2 for i
to position Extract for a given journal:

ALTER EXTRACT {BEGIN {NOW | yyyy-mm-dd[ hh:mi:[ss[.cccccc]]]}
[JOURNAL journal_library/journal_name [JRNRCV receiver_library/
receiver_name]] | , EOF [JOURNAL journal_library/journal_name
[JRNRCV receiver_library/receiver_name]] | , SEQNO sequence_number
[JOURNAL journal_library/journal_name [JRNRCV receiver_library/
receiver_name]]}

group_name

The name of the Extract group that is to be altered.

ADD_EXTRACT_attribute

You can change any of the attributes specified with the ADD EXTRACT
command, except for the following:

* Altering an Extract specified with the EXTTRAILSOURCE option.

* Altering the number of RAC threads specified with the THREADS option.

For these exceptions, delete the Extract group and then add it again.

If using the BEGIN option, do not combine other options in the statement.
Issue separate statements, for example:

ALTER EXTRACT finance, BEGIN 2017-01-01
ALTER EXTRACT finance, ETROLLOVER
ALTER EXTRACT finance, SCN 789000

If using the SCN or BEGIN option for Integrated Extract, it requires a DBLOGIN,
and the SCN or timestamp value specified cannot be below the outbound
server's first SCN or timestamp. To find the outbound server's first SCN,
issue the following command:

INFO EXTRACT group_name, SHOWCH DETAIL

The first SCN value is listed as shown in the following example:

Integrated Extract outbound server first scn: 0.665884 (665884)

TRANLOG LRI_number
(DB2 LUW) You can use the LRI_number option for DB2 LUW systems to reposition
Extract at that LRI in the DB2 transaction log.

UPGRADE INTEGRATED TRANLOG

Upgrades the Extract group from classic capture to integrated capture.
To support the upgrade, the transaction log that contains the start of
the oldest open transaction must be available on the source or downstream
mining system. For instructions on making the transition from classic to
integrated capture, see the full procedure in Administering Oracle
GoldenGate.

DOWNGRADE INTEGRATED TRANLOG [THREADS number]

Downgrades the Extract group from integrated capture to classic capture.
When downgrading on a RAC system, the THREADS option must be used to specify
the number of RAC threads. On a non-RAC system, you can optionally specify
THREADS 1 to cause the downgraded classic Extract to run in threaded mode
with one thread, which is similar to doing an ADD EXTRACT with THREADS 1
on a non-RAC system.

See Administering Oracle GoldenGate for the full procedure for performing the
transition from integrated to classic capture.

To support the downgrade, the transaction log that contains the start
of the oldest open transaction must be available on the source or
downstream mining system. For information about integrated capture,
see the Oracle GoldenGate documentation for your database.

THREAD number

Valid for classic capture mode. In an Oracle RAC configuration,
alters Extract only for the specified redo thread. Only one thread
number can be specified.

LSN value

Valid for SQL Server. Repositions Extract to the specified LSN value.
For Extract to capture the data for the specified LSN, the LSN value
must be the actual 'begin' LSN. For the CDC Extract, the 'begin' LSN
can be found from the tran_begin_lsn column of the cdc.lsn_time_mapping
table.

SCN value

Valid for Oracle. Repositions Extract to the transaction in the
redo log that has the specified Oracle system change number (SCN). You
cannot alter the Extract to an SCN less than the first SCN.
This option is valid both for integrated capture mode and classic
capture mode.

ETROLLOVER

Causes Extract to increment to the next file in the trail sequence
when restarting. For example, if the current file is ET000000002, the
current file will be ET000000003 when Extract restarts. A trail can be
incremented from 000000001 through 999999999, and then the sequence numbering
starts over at 000000000.

BEGIN {NOW | yyyy-mm-dd[ hh:mi:[ss[.cccccc]]]}
[JOURNALjournal_library/journal_name
[JRNRCV receiver_library/ receiver_name]] |
, EOF [JOURNALjournal_library/journal_name
[JRNRCVreceiver_library/receiver_name]] |
, SEQNO sequence_number[JOURNALjournal_library/journal_name
[JRNRCV receiver_library/receiver_name]]

These IBM for i options allow journal-specific Extract positioning after
the extract overall position is issued with ADD EXTRACT. A specific journal
position set with ALTER EXTRACT does not affect any overall position that
was previously set with ADD EXTRACT or ALTER EXTRACT; however an extract
overall position set with ALTER EXTRACT overrides any specific journal positions
that were previously set in the same Extract configuration.

Note:
SEQNO, when used with a journal in ALTER EXTRACT, is the journal sequence
number that is relative to that specific journal, not the system sequence
number that is common across all of the journals read by the Extract.

Examples

Example 1

The following alters Extract to start processing data from January 1, 2011.

ALTER EXTRACT finance, BEGIN 2017-01-01

Example 2

The following alters Extract to start processing at a specific location
in the trail.

ALTER EXTRACT finance, EXTSEQNO 26, EXTRBA 338

Example 3

The following alters Extract in an Oracle RAC environment, and applies
the new begin point only for redo thread 4.

ALTER EXTRACT accounts, THREAD 4, BEGIN 2017-01-01

Example 4

The following alters Extract in a SQL Server environment to start
at a specific LSN.

ALTER EXTRACT sales, LSN 0x00000037:0000029b:0001

Example 5

The following alters Extract to increment to the next file in the
trail sequence.

ALTER EXTRACT finance, ETROLLOVER

Example 6

The following alters Extract to upgrade to integrated capture.

ALTER EXTRACT finance, UPGRADE INTEGRATED TRANLOG

Example 7

The following alters Extract to downgrade to classic capture in
a RAC environment.

ALTER EXTRACT finance, DOWNGRADE INTEGRATED TRANLOG THREADS 3

Example 8

The following alters Extract in an Oracle environment to start
processing data from source database SCN 778899.

ALTER EXTRACT finance, SCN 778899

Example 9

The following shows ALTER EXTRACT for an IBM for i journal start point.

ALTER EXTRACT finance, SEQNO 1234 JOURNAL accts/acctsjrn

Example 10

The following shows ALTER EXTRACT for an IBM for i journal and
receiver start point.

ALTER EXTRACT finance, SEQNO 1234 JOURNAL accts/acctsjrn JRNRCV
accts/jrnrcv0005

Example 11

The following example alters an Extract on a DB2 LUW system.

ALTER EXTRACT extcust, TRANLOG LRI 8066.322711

----------------------------------------------------------------------
CLEANUP EXTRACT

Use CLEANUP EXTRACT to delete run history for the specified Extract
group. The cleanup keeps the last run record intact so that Extract
can resume processing from where it left off. Before using this command,
stop Extract by issuing the STOP EXTRACT command.

Syntax
CLEANUP EXTRACT group_name SAVE count]

group_name
The name of an Extract group or a wildcard (*) to specify multiple groups.
For example, T* cleans up all Extract groups whose names start with T.

SAVE count
Excludes the specified number of the most recent records from the cleanup.

Examples

Example 1
The following deletes all but the last record.

CLEANUP EXTRACT finance

Example 2
The following deletes all but the most recent five records.

CLEANUP EXTRACT *, SAVE 5

----------------------------------------------------------------------
DELETE EXTRACT

Use DELETE EXTRACT to delete an Extract group. This command deletes the
checkpoint file that belongs to the group, but leaves the parameter file
intact. You can then re-create the group or delete the parameter file as needed.

Before using DELETE EXTRACT, stop Extract with the STOP EXTRACT command.

To delete the trail files that are associated with the Extract group,
delete them manually through the operating system.

Syntax
DELETE EXTRACT group_name [!]

group_name

The name of an Extract group or a wildcard specification (*) to specify
multiple groups. For example, T* deletes all Extract groups whose names
start with T.

!
(Exclamation point) Deletes all Extract groups associated with a wildcard
without prompting.

----------------------------------------------------------------------
INFO EXTRACT

Use INFO EXTRACT to view the following information.

* The status of Extract (STARTING, RUNNING, STOPPED, or ABENDED). STARTING
means that the process has started but has not yet locked the checkpoint
file for processing.

* Approximate Extract lag.

* Checkpoint information.

* Process run history.

* The trail(s) to which Extract is writing.

* Status of upgrade to, or downgrade from, Integrated Extract

Extract can be running or stopped when INFO EXTRACT is issued. In the case
of a running process, the status of RUNNING can mean one of the following:

* Active: Running and processing (or able to process) data. This is the
normal state of a process after it is started.

* Suspended: The process is running, but suspended due to an EVENTACTIONS
SUSPEND action. In a suspended state, the process is not active, and no data
can be processed, but the state of the current run is preserved and can be
continued by issuing the SEND EXTRACT command with the RESUME option in GGSCI.
The RBA in the INFO command reflects the last checkpointed position before
the suspend action. To determine whether the state is active or suspended,
issue the SEND EXTRACT command with the STATUS option.

The basic command displays information only for online (continuous) Extract
processes. Tasks are excluded.

About Extract Lag

The Checkpoint Lag field of the INFO EXTRACT output reflects the lag, in seconds,
at the time that the last checkpoint was written to the trail. For example,
if the following is true...

* Current time = 15:00:00

* Last checkpoint = 14:59:00

* Timestamp of the last record processed = 14:58:00

...then the lag is reported as 00:01:00 (one minute, the difference between 14:58
and 14:59).

A lag value of UNKNOWN indicates that the process could be running but has not
yet processed records, or that the source system's clock is ahead of the target
system's clock (due to clock imperfections, not time zone differences).

For more precise lag information, use LAG EXTRACT (see “LAG EXTRACT”).

Syntax

INFO EXTRACT group_name
[SHOWCH [n]]
[DETAIL]
[TASKS | ALLPROCESSES]
[UPGRADE | DOWNGRADE | CONTAINERS]

group_name

The name of an Extract group or a wildcard (*) to specify multiple groups.
For example, T* shows information for all Extract groups whose names start
with T.

SHOWCH [n]

The basic command shows information about the current Extract checkpoints.
Extract checkpoint positions are composed of read checkpoints in the data
source and write checkpoints in the trail. The trail type (RMTTRAIL or
EXTTRAIL) is also noted.

Optionally, specify a value for n to include the specified number of previous
checkpoints as well as the current one.

Note:
You might see irregular indents and spacing in the output. This is normal
and does not affect the accuracy of the information. See Administering
Oracle GoldenGate for more information about checkpoints, including descriptions
of the types of checkpoints made by each process and the internal metadata entries
that are included in the display.

DETAIL

Displays the following:

* Extract run history, including start and stop points in the data source,
expressed as a time.

* Trails to which Extract is writing.

See Example 5 for sample output of DETAIL.

TASKS

Displays only Extract tasks. Tasks that were specified by a wildcard
argument are not displayed by INFO EXTRACT.

ALLPROCESSES

Displays all Extract groups, including tasks.

UPGRADE | DOWNGRADE

Valid for an Oracle database only.

* UPGRADE displays whether the Extract can be upgraded from classic capture
mode to integrated capture mode.

* DOWNGRADE displays whether the Extract can be downgraded from integrated
capture mode to classic capture mode.

If Extract cannot be upgraded or downgraded, the reason is displayed.

A wildcarded Extract name is not allowed with this option.

Before using this command, issue the DBLOGIN command.

CONTAINERS

Lists the PDBs that are registered with the specified Extract group.
However, the command errors out if it is run in non-CDB mode or the
Extract group doesn't exist.

Issue the DBLOGIN command before running this command.

Examples

Example 1

INFO EXTRACT fin*, SHOWCH

Example 2

INFO EXTRACT *, TASKS

Example 3 (Oracle only)

INFO EXTRACT finance UPGRADE

Example 4

The following example shows basic INFO EXTRACT output.

EXTRACT EXTCUST Last Started 2017-01-05 16:09 Status RUNNING
Checkpoint Lag 00:01:30 (updated 97:16:45 ago)
Log Read Checkpoint File /rdbms/data/oradata/redo03a.log
2017-01-05 16:05:17 Seqno 2952, RBA 7598080
Example 5

The following is an example of the output of INFO EXTRACT with DETAIL.
EXTRACT ORAEXT Last Started 2017-01-15 16:16 Status STOPPED
Checkpoint Lag 00:00:00 (updated 114:24:48 ago)
Log Read Checkpoint File C:\ORACLE\ORADATA\ORA920\REDO03.LOG
2017-01-15 16:17:53 Seqno 46, RBA 3757568
Target Extract Trails:

Trail Name Seqno RBA Max MB Trail Type

c:\goldengate802\dirdat\xx 0 57465 10 RMTTRAIL
c:\goldengate802\dirdat\jm 0 19155 10 RMTTRAIL

Extract Source Begin End

C:\ORACLE\ORADATA\ORA920\REDO03.LOG 2017-01-15 16:07 2017-01-15 16:17
C:\ORACLE\ORADATA\ORA920\REDO03.LOG 2017-01-15 15:55 2017-01-15 16:07
C:\ORACLE\ORADATA\ORA920\REDO03.LOG 2017-01-15 15:42 2017-01-15 15:55
C:\ORACLE\ORADATA\ORA920\REDO03.LOG 2017-01-15 15:42 2017-01-15 15:42
Not Available * Initialized * 2017-01-15 15:42

Current directory C:\GoldenGate802
Report file C:\GoldenGate802\dirrpt\ORAEXT.rpt
Parameter file C:\GoldenGate802\dirprm\ORAEXT.prm
Checkpoint file C:\GoldenGate802\dirchk\ORAEXT.cpe
Process file C:\GoldenGate802\dirpcs\ORAEXT.pce
Error log C:\GoldenGate802\ggserr.log

---------------------------------------------------------------------
KILL EXTRACT

Use KILL EXTRACT to kill an Extract process running in regular or PASSIVE mode.
Use this command only if a process cannot be stopped gracefully with the STOP
EXTRACT command. The Manager process will not attempt to restart a killed
Extract process.

Syntax

KILL EXTRACT group_name

group_name

The name of an Extract group or a wildcard (*) to specify multiple groups.
For example, T* kills all Extract processes whose group names start with T.

Example

KILL EXTRACT finance

---------------------------------------------------------------------
LAG EXTRACT

Use LAG EXTRACT to determine a true lag time between Extract and the data
source. LAG EXTRACT calculates the lag time more precisely than INFO EXTRACT
because it communicates with Extract directly, rather than reading a
checkpoint position in the trail.

For Extract, lag is the difference, in seconds, between the time that a record
was processed by Extract (based on the system clock) and the timestamp of
that record in the data source.

If the heartbeat functionality is enabled, you can view the associated lags.

Syntax
LAG EXTRACT
[group_name]
[GLOBAL]

group_name

The name of an Extract group or a wildcard (*) to specify multiple groups.
For example, T* determines lag time for all Extract groups whose names
start with T.

GLOBAL

Displays the lags in the GG_LAGS view.

Examples

Example 1

LAG EXTRACT *

Example 2

LAG EXTRACT *fin*

Example 3

The following is sample output for LAG EXTRACT.

Sending GETLAG request to EXTRACT CAPTPCC...
Last record lag: 2 seconds.
At EOF, no more records to process.

---------------------------------------------------------------------
REGISTER EXTRACT

Use REGISTER EXTRACT to register a primary Extract group with an Oracle
Database to:

* Enable integrated capture mode

* Specify options for Integrated Extract from a multitenant container database

* Enable Extract in classic capture mode to work with Oracle Recovery Manager
to retain the archive logs needed for recovery

To unregister an Extract group from the database, use the UNREGISTER EXTRACT
command (see “UNREGISTER EXTRACT”). See the Oracle GoldenGate documentation for your database
for more information about using REGISTER EXTRACT.

Syntax

For classic Extract:

For Integrated Extract:

REGISTER EXTRACT group-name
( LOGRETENTION | DATABASE
( [ CONTAINER container-list |
ADD CONTANER container-list |
DROP CONTAINER container-list ]
[ SCN scn ]
[ SHARE ( AUTOMATIC | group-name | NONE ) ]
[ [NO]OPTIMIZED ]
)
)
Container-list is a comma separated list of PDB names, for example (pdb1, pdb2);
or wildcarded PDB names, for example (pdb* or pdb?); or both, for example
(cdb1_pdb1, pdb*). Supported wildcards are ? and *.
The default value is NOOPTIMIZED. The NOOPTIMIZED option cannot be used with
the ADD CONTAINER or DROP CONTAINERor SHARE EXTRACT options.

group_name

The name of the Extract group that is to be registered. Do not use a wildcard.
DATABASE[
CONTAINER (container ...]) |
ADD CONTAINER (container ...]) |
DROP CONTAINER (container ...])
]

Without options, DATABASE enables integrated capture from a non-CDB database
for the Extract group. In this mode, Extract integrates with the database
logmining server to receive change data in the form of logical change records
(LCR). Extract does not read the redo logs. Extract performs capture processing,
transformation, and other requirements. The DML filtering is performed by the
Logmining server. For support information and configuration steps, see
the Oracle GoldenGate documentation for your database.

Before using REGISTER EXTRACT with DATABASE, use the DBLOGIN command for all
extracts with the privileges granted using the dbms_goldengate_auth.grant_admin_privilege
procedure. If you have a downstream configuration, then you must also issue the
MININGDBLOGIN command. If the source database you are registering is a CDB database
and Extract will fetch data, then grant_admin_privilege must be called with the
CONTAINER='ALL' parameter.

After using REGISTER EXTRACT, use ADD EXTRACT with the INTEGRATED TRANLOG option
to create an Extract group of the same name. You must register an Extract group
before adding it.

CONTAINER (container ...])
(containers) of a multitenant container database (CDB). Specify one or more
pluggable databases as a comma-delimited list within parentheses, for
example: CONTAINER (pdb1, pdb2, pdb3). If you list the pluggable
databases, they must exist in the database. You can also specify the
pluggable databases using the wildcards * and ?. For example, CONTAINER
(pdb*).

ADD CONTAINER (container ...])
Adds the specified pluggable database to an existing Extract capture configuration.
Specify one or more pluggable databases as a comma-delimited list within
parentheses, or using the wildcards * and ?. For example: ADD CONTAINER (pdb1, pdb2,
pdb3). Before issuing REGISTER EXTRACT with this option, stop the Extract group.

For Oracle, adding CONTAINERs at particular SCN on an existing Extract
is not supported.

DROP CONTAINER (container ...])
Drops the specified pluggable database from an existing Extract capture
configuration. Specify one or more pluggable databases as a comma-delimited
list within parentheses, for example: DROP CONTAINER (pdb1, pdb2, pdb3).
A register drop container does not fully happen until the Extract has been
started and it reads a committed txn from a dropped pluggable database greater
than the Extract checkpoint SCN. Extract then fully drops the containers then
shutdowns with a message.
Before issuing REGISTER EXTRACT with this option, stop the Extract group.

LOGRETENTION

Valid for classic Extract only. Enables an Extract group in classic capture mode
to work with Oracle Recovery Manager (RMAN) to retain the logs that Extract needs
for recovery. LOGRETENTION is ignored if the Extract group is configured for
integrated capture.

LOGRETENTION creates an underlying Oracle Streams capture process that is dedicated
to the Extract group and has a similar name. This capture is used only for the
purpose of log retention.

The logs are retained from the time that REGISTER EXTRACT is issued, based on the
current database SCN. The log-retention feature is controlled with the LOGRETENTION
option of the TRANLOGOPTIONS parameter.

Before using REGISTER EXTRACT with LOGRETENTION, issue the DBLOGIN command with
the privileges shown in “DBLOGIN”.

SCN scn

Registers Extract to begin capture at a specific system change number (SCN)
in the past. Without this option, capture begins from the time that REGISTER EXTRACT
is issued. The specified SCN must correspond to the begin SCN of a dictionary
build operation in a log file. You can issue the following query to find all
valid SCN values:

SELECT first_change#
FROM v$archived_log
WHERE dictionary_begin = 'YES' AND
standby_dest = 'NO' AND
name IS NOT NULL AND
status = 'A';

When used alone, the SCN value is the beginning SCN of the dictionary build
operation in a log file.

When used in conjunction with SHARE AUTOMATIC or SHARE extract_name, then the
specified SCN is the start_scn for the capture session and has the following restrictions:

* Should be lesser than or equal to the current SCN.

* Should be greater than the minimum (first SCN) of the existing captures.

{SHARE [
AUTOMATIC |

extract|
NONE]}

Registers the extract to return to an existing LogMiner data dictionary build
with a specified SCN creating a clone. This allows for faster creation captures
by leveraging existing dictionary builds.

SHARE cannot be used on a CDB.

The following GGSCI commands are supported:

REGISTER EXTRACT extract database SCN #### SHARE AUTOMATIC
REGISTER EXTRACT extract database SCN #### SHARE extract
REGISTER EXTRACT extract database SHARE NONE
REGISTER EXTRACT extract database SCN #### SHARE NONE

In contrast, the following GGSCI commands are not supported in a downstream
configuration:

AUTOMATIC
Clone from the existing closest capture. If no suitable clone candidate
is found, then a new build is created.

extract
Clone from the capture session associated for the specified extract. If
this is not possible, then an error occurs the register does not complete.

NONE
Does not clone or create a new build; this is the default.

In a downstream configuration, the SHARE clause must be used in conjunction
with the SCN clause when registering for Extract.

Examples

Example 1

Example 2

Example 3

Example 4

Example 5

Example 6

The beginning SCN of the dictionary build is 136589.

Example 7

The valid start SCN, 67000 in this case; it is not necessarily the
current SCN.

Example 8

---------------------------------------------------------------------
SEND EXTRACT

Use SEND EXTRACT to communicate with a running Extract process. The
request is processed as soon as Extract is ready to accept commands from users.

Syntax

SEND EXTRACT group_name, {
BR {BRINTERVAL interval |
BRSTART |
BRSTOP | BRCHECKPOINT {IMMEDIATE | IN n{M|H} |
AT yyyy-mm-dd hh:mm[:ss]]}} |
BR BRFSOPTION { MS_SYNC | MS_ASYNC }
CACHEMGR {CACHESTATS | CACHEQUEUES | CACHEVMUSAGE} |
FORCESTOP |
FORCETRANS transaction_ID [THREAD n] [FORCE] |

GETLAG |
GETPARAMINFO [parameter_name] [FILE output_file] |
GETTCPSTATS |
LOGEND |
LOGSTATS |
REPORT |
RESUME |
ROLLOVER |
SHOWTRANS [transaction_ID] [THREAD n] [COUNT n]
[DURATION duration unit] [TABULAR]
[FILE file_name [DETAIL]] |
SKIPTRANS transaction_ID [THREAD n] [FORCE] |
STATUS |
STOP |
TRACE[2] file_name |
TRACE[2] OFF |
TRACE OFF file_name |
TRACEINIT |
TRANSLOGOPTIONS INTEGRATEDPARAMS(parameter_specification)|
TRANLOGOPTIONS {PREPAREFORUPGRADETOIE | NOPREPAREFORUPGRADETOIE}
|TRANLOGOPTIONS
{PURGEORPHANEDTRANSACTIONS | NOPURGEORPHANEDTRANSACTIONS} |
TRANLOGOPTIONS TRANSCLEANUPFREQUENCY minutes |
VAMMESSAGE 'Teradata_command' |
VAMMESSAGE {'ARSTATS' | 'INCLUDELIST [filter]' | 'FILELIST [filter]'
| 'EXCLUDELIST
[filter]'} |
VAMMESSAGE 'OPENTRANS'
}

group_name

The name of the Extract group or a wildcard (*) to specify multiple
groups. For example, T* sends the command to all Extract processes whose
group names start with T. If an Extract is not running, an error is returned.
BR {BRINTERVALinterval| BRSTART | BRSTOP |
BRCHECKPOINT {IMMEDIATE | INn{H|M} | ATyyyy-mm-dd[ hh:mm[:ss]]}}

Sends commands that affect the Bounded Recovery mode of Extract.

BRINTERVAL interval

Sets the time between Bounded Recovery checkpoints. Valid values
are from 20 minutes to 96 hours specified as M for minutes or H
for hours, for example, 20M or 2H. The default interval is 4 hours.

BRSTART

Starts Bounded Recovery. This command should only be used under
direction of Oracle Support.

BRSTOP

Stops Bounded Recovery for the run and for recovery. Consult Oracle
Support before using this option. In most circumstances, when there
is a problem with Bounded Recovery, it turns itself off.

BRCHECKPOINT {IMMEDIATE | IN n{H|M} | AT yyyy-mm-dd[ hh:mm[:ss]]}}

Sets the point at which a bounded recovery checkpoint is made.
IMMEDIATE issues the checkpoint immediately when SEND EXTRACT is
issued. IN issues the checkpoint in the specified number of hours
or minutes from when SEND extract is issued. AT issues the checkpoint
at exactly the specified time.

BR BRFSOPTION {MS_SYNC | MS_ASYNC}

Performs synchronous/asynchronous writes of the mapped data in
Bounded Recovery.

MS_SYNC
Bounded Recovery writes of mapped data are synchronized for
I/O data integrity completion.

MS_ASYNC
Bounded Recovery writes of mapped data are initiated or
queued for servicing.

CACHEMGR {CACHESTATS | CACHEQUEUES | CACHEVMUSAGE}

Returns statistics about the Oracle GoldenGate memory cache
manager.

CACHESTATS
Returns all CACHEMGR statistics.

CACHEQUEUES
Returns statistics for the free queues only.

CACHEVMUSAGE
Returns statistics for the virtual memory use.

FORCESTOP

Forces Extract to stop, bypassing any notifications. This command
will stop the process immediately.

FORCETRANS transaction_ID [THREAD n] [FORCE]

Valid for MySQL, Oracle, and SQL Server.

Forces Extract to write a transaction specified by its transaction ID
number to the trail as a committed transaction. FORCETRANS does not
commit the transaction to the source database. It only forces the
existing data to the trail so that it is processed (with an implicit
commit) by Replicat. You can repeat FORCETRANS for other transactions
in order of their age. Note that forcing a transaction to commit to
the trail (and therefore the target database) may cause data discrepancies
if the transaction is rolled back by the source user applications.

After using FORCETRANS, wait at least five minutes if you intend to issue
SEND EXTRACT with FORCESTOP. Otherwise, the transaction will still be present.

If FORCETRANS is used immediately after Extract starts, you might
receive an error message that asks you to wait and then try the
command again. This means that no other transactions have been processed
yet by Extract. Once another transaction is processed, you will be
able to force the transaction to trail.

transaction_ID

The ID of the transaction. Get the transaction ID number with
SHOWTRANS or from an Extract runtime message. Extract ignores any
data added to the transaction after this command is issued. A
confirmation prompt must be answered unless FORCE is used. To use
FORCETRANS, the specified transaction must be the oldest one in the
list of transactions shown with SHOWTRANS.

THREAD n

Valid only for Oracle.

Use THREAD n to specify which thread generated the transaction in an Oracle
RAC environment if there are duplicate transaction IDs across threads.

FORCE

Valid for Oracle and SQL Server. Use FORCE to bypass the confirmation prompt.

GETLAG

Determines a true lag time between Extract and the data source. Returns the
same results as LAG EXTRACT (see “LAG EXTRACT”).

GETPARAMINFO [parameter_name] [FILE output_file]

Use GETPARAMINFO to query runtime parameter values of a running instance,
including Extract, Replicat, and Manager. You can query for a single parameter
or all parameters and send the output to the console or a text file

parameter_name

The default behavior is to display all parameters in use, meaning those
parameters that have ever been queried by the application, parameters,
and their current values. If you specify a particular parameter, then the
output is filtered by that name.

FILEoutput_file

The name of the text file that your output is redirected to.

GETTCPSTATS

Displays statistics about network activity between Extract and the target
system. The statistics include:

* Local and remote IP addresses.

* Inbound and outbound messages, in bytes and bytes per second.

* Number of receives (inbound) and sends (outbound). There will be at least
two receives per inbound message: one for the length and one or more for the data.

* Average bytes per send and receive.

* Send and receive wait time: Send wait time is how long it takes for the write
to TCP to complete. The lower the send wait time, the better the performance over
the network. Receive wait time is how long it takes for a read to complete.
Together, the send and receive wait times provide a rough estimate of network
round trip time. These are expressed in microseconds.

* Status of data compression (enabled or not).

* Uncompressed bytes and compressed bytes: When compared (uncompressed to compressed),
these comprise the compression ratio, meaning how many bytes there were before and
after compression. You can compare the compression ratio with the bytes that are
being compressed per second to determine if the compression rate is worth the cost
in terms of resource and network consumption.

The TCPBUFSIZE option of RMTHOST and RMTHOSTOPTIONS controls the size of the TCP buffer
for uncompressed data. What actually enters the network will be less than this size
if compression is enabled. GETTCPSTATS shows post-compression throughput.

LOGEND

Confirms whether or not Extract has processed all of the records in the data source.

LOGSTATS

Valid only for Oracle.

Instructs Extract to issue a report about the statistics that are related to the
processing of data from the Oracle redo log files. Extract uses an asynchronous
log reader that reads ahead of the current record that Extract is processing,
so that the data is available without additional I/O on the log files. The processing
is done through a series of read/write queues. Data is parsed by a producer thread
at the same time that additional data is being read from the log file by a reader
thread. Thus, the reason for the term "read-ahead" in the statistics.

The statistics are:

* AsyncReader.Buffersn: There is a field like this for each buffer queue that
contains captured redo data. It shows the size, the number of records in it,
and how long the wait time is before the data is processed. These statistics
are given for write operations and read operations on the queue.

* REDO read ahead buffers: The number of buffers that are being used to read
ahead asynchronously.

* REDO read ahead buffer size: The size of each buffer.

* REDO bytes read ahead for current redo: Whether read-ahead mode is on or off
for the current redo log file (value of ON or OFF).

* REDO bytes read: The number of bytes read from all redo log files that are
associated with this instance of Extract.

* REDO bytes read ahead: The number of bytes that were processed by the
read-ahead mechanism.

* REDO bytes unused: The number of read-ahead bytes that were subsequently
dropped as the result of Extract position changes or stale reads.

* REDO bytes parsed: The number of bytes that were processed as valid log data.

* REDO bytes output: The number of bytes that were written to the trail file
(not including internal Oracle GoldenGate overhead).

REPORT

Generates an interim statistical report to the Extract report file. The
statistics that are displayed depend upon the configuration of the STATOPTIONS
parameter when used with the RESETREPORTSTATS| NORESETREPORTSTATS option.

RESUME
Resumes (makes active) a process that was suspended by an EVENTACTIONS SUSPEND
event. The process resumes normal processing from the point at which it was suspended.

ROLLOVER

Causes Extract to increment to the next file in the trail when restarting. For
example, if the current file is ET000002, the current file will be ET000003
after the command executes. A trail can be incremented from 000001through
999999, and then the sequence numbering starts over at 000000.

SHOWTRANS [transaction_ID] [THREAD n] [COUNT n]
[DURATION duration unit] [TABULAR] | [FILE file_name [DETAIL]]

Valid for MySQL, Oracle, and SQL Server.

Displays information about open transactions. SHOWTRANS shows any of the
following, depending on the database type:

* Process checkpoint (indicating the oldest log needed to continue
processing the transaction in case of an Extract restart). See Administering
Oracle GoldenGate for more information about checkpoints.

* Transaction ID

* Extract group name

* Redo thread number

* Timestamp of the first operation that Oracle GoldenGate extracts from
a transaction (not the actual start time of the transaction)

* System change number (SCN)

* Redo log number and RBA

* Status (Pending COMMIT or Running). Pending COMMIT is displayed while
a transaction is being written after a FORCETRANS was issued.

Without options, SHOWTRANS displays all open transactions that will fit
into the available buffer.

See the examples for sample output of SHOWTRANS. To further control output,
see the following options.

transaction_ID
Limits the command output to a specific transaction.

THREAD n
Valid only for Oracle.

Constrains the output to open transactions against a specific Oracle
RAC thread. For n, use a RAC thread number that is recognized by Extract.

COUNT n
Constrains the output to the specified number of open transactions,
starting with the oldest one. Valid values are 1 to 1000.

DURATION duration unit
Restricts the output to transactions that have been open longer than
the specified time, where:

duration is the length of time expressed as a whole number.

unit is one of the following to express seconds, minutes, hours, or days:

TABULAR
Valid only for Oracle.
Generates output in tabular format similar to the default table printout
from SQL*Plus. The default is field-per-row.

FILE file_name [DETAIL]
Valid only for Oracle and SQL Server. Not valid for MySQL.

Forces Extract to write the transaction information to the specified file.
There is no output to the console.

For Oracle, you can write a hex and plain-character dump of the data by
using FILE with DETAIL. This dumps the entire transaction from memory to
the file. Viewing the data may help you decide whether to skip the transaction
or force it to the trail.

Note:
Basic detail information is automatically written to the report file at intervals
specified by the WARNLONGTRANS CHECKINTERVAL parameter.

SKIPTRANS transaction_ID [THREAD n] [FORCE]
Valid for MySQL, Oracle, and SQL Server.

Forces Extract to skip the specified transaction, thereby removing any current data
from memory and ignoring any subsequent data. A confirmation prompt must be answered
unless FORCE is used. After using SKIPTRANS, wait at least five minutes if you intend
to issue SEND EXTRACT with FORCESTOP. Otherwise, the transaction will still be present.
Note that skipping a transaction may cause data loss in the target database.

Note:
To use SKIPTRANS, the specified transaction must be the oldest one in the
list of transactions shown with SHOWTRANS.

transaction_ID
The transaction ID number. Get the ID number with SHOWTRANS or from an Extract
runtime message.

THREAD n
Valid only for Oracle.

Use THREAD n to specify which thread generated the transaction in an Oracle RAC
environment if there are duplicate transaction IDs. SKIPTRANS specifies the
checkpoint index number, not the actual thread number. To specify the correct
thread, issue the INFO EXTRACT group_name SHOWCH command, and then specify
the READ checkpoint index number that corresponds to the thread number that
you want to skip. See the examples for details. See Administering Oracle
GoldenGate for more information about checkpoints.

FORCE
Valid for Oracle and SQL Server. Not valid for MySQL

Use FORCE to bypass the prompt that confirms your intent to skip the transaction.

STATUS

Returns a detailed status of the processing state, including current position and
activity. Possible processing status messages on the Current status line are:

* Delaying– waiting for more data

* Suspended– waiting to be resumed

* Processing data– processing data

* Starting initial load– starting an initial load task

* Processing source tables– processing data for initial load task

* Reading from data source– reading from the data source, such as a source
table or transaction log

* Adding record to transaction list– adding a record to the file memory
transaction list

* At EOF (end of file)– no more records to process

In addition to the preceding statuses, the following status notations appear
during an Extract recovery after an abend event. You can follow the progress
as Extract continually changes its log read position over the course of the recovery.

* In recovery[1]– Extract is recovering to its checkpoint in the transaction
log.

* In recovery[2]– Extract is recovering from its checkpoint to the end of the
trail.

* Recovery complete – The recovery is finished, and normal processing will
resume.

STOP

Stops Extract. If there are any long-running transactions (based on the
WARNLONGTRANS parameter), the following message will be displayed:

Sending STOP request to EXTRACT JC108XT...
There are open, long-running transactions. Before you stop Extract, make the
archives containing data for those transactions available for when Extract
restarts. To force Extract to stop, use the SEND EXTRACT group, FORCESTOP command.
Oldest redo log file necessary to restart Extract is:
Redo Thread 1, Redo Log Sequence Number 150, SCN 31248005, RBA 2912272.

TRACE[2] {file_name | OFF}
Turns tracing on and off. Tracing captures information to the specified file to
reveal processing bottlenecks. Contact Oracle Support for assistance if the
trace reveals significant processing bottlenecks.

TRACE
Captures step-by-step processing information.

TRACE2
Identifies code segments rather than specific steps.

file_name
Specifies the name of the file to which the trace information is written.
If a trace is already running when SEND EXTRACT is issued with TRACE, the
existing trace file is closed and the trace is resumed to the new file
specified with file_name.

OFF
Turns off tracing.

TRACE OFF file_name

Turns tracing off only for the specified trace file.

TRACEINIT

Resets tracing statistics back to 0 and then starts accumulating statistics
again. Use this option to track the current behavior of processing, as
opposed to historical.

INTEGRATEDPARAMS(parameter_specification)

(Oracle) Supports an Integrated Extract. Sends a parameter specification to
the database inbound server while Extract is running in integrated mode. Only
one parameter specification can be sent at a time with this command. Parameter
changes do not take affect until the Extract is restarted.

To preserve the continuity of processing, the parameter change is made at a
transaction boundary. For a list of supported inbound server parameters, see
the Oracle GoldenGate documentation for your database.

TRANLOGOPTIONS{PREPAREFORUPGRADETOIE| NOPREPAREFORUPGRADETOIE}

(Oracle) Valid when upgrading from Classic to Integrated Extract on Oracle RAC.

When upgrading on Oracle RAC from Classic to Integrated Extract, you must set
the PREPAREFORUPGRADETOIE option before stopping Classic Extract for the upgrade
then wait for the information message in the report file that indicates that the
parameter has taken effect before proceeding with the upgrade. For detailed
upgrade instructions, see Upgrading Oracle GoldenGate for Windows and UNIX.

PREPAREFORUPGRADETOIE

Set PREPAREFORUPGRADETOIE in the Extract parameter file, which requires a
restart of Extract, or you can set it dynamically for a running extract
from GGSCI using this command:

SEND EXTRACT extract_name TRANLOGOPTIONS
PREPAREFORUPGRADETOIE

NOPREPAREFORUPGRADETOIE

Dynamically turns off the PREPAREFORUPGRADETOIE option if necessary.
The default is NOPREPAREFORUPGRADETOIE.

TRANLOGOPTIONS {PURGEORPHANEDTRANSACTIONS |
NOPURGEORPHANEDTRANSACTIONS}

Valid for Oracle RAC. Enables or disables purging of orphaned transactions
that occur when a node fails and Extract cannot capture the rollback.

TRANLOGOPTIONS TRANSCLEANUPFREQUENCY minutes

Valid for Oracle RAC. Specifies the interval, in minutes, after which Oracle
GoldenGate scans for orphaned transactions and then re-scans to confirm and
delete them. Valid values are from 1 to 43200 minutes. Default is 10 minutes.

VAMMESSAGE 'Teradata_command'
VAMMESSAGE { 'ARSTATS' | 'INCLUDELIST [filter]' | 'EXCLUDELIST
[filter]' }
VAMMESSAGE 'OPENTRANS'
Sends a command to the capture API that is used by Extract.
A Teradata command can be any of the following:

'control:terminate'
Stops a replication group. Required before dropping or altering a
replication group in Teradata.

'control:suspend'
Suspends a replication group. Can be used when upgrading Oracle GoldenGate.

'control:resume'
Resumes a replication group after it has been suspended.

'control:copy database.table'
Copies a table from the source database to the target database.

A SQL Server command can be the following:

'OPENTRANS'
Prints a list of open transactions with their transaction ID, start time,
first LSN, and the number of operations they contain.

Examples

Example 1

SEND EXTRACT finance, ROLLOVER

Example 2

SEND EXTRACT finance, STOP

Example 3

SEND EXTRACT finance, VAMMESSAGE 'control:suspend'

Example 4

SEND EXTRACT finance, TRANLOGOPTIONS TRANSCLEANUPFREQUENCY 20

Example 5

This example explains SKIPTRANS. Start with the following SHOWCH output, which
shows that thread 2 is at Read Checkpoint #3. See Administering Oracle GoldenGate
for more information about checkpoints.

INFO extract SHOWCH
Read Checkpoint #3
Oracle RAC Redo Log
Startup Checkpoint (starting position in the data source):
Thread #: 2
Sequence #: 17560
RBA: 65070096
Timestamp: 2017-07-30 20:04:47.000000
SCN: 1461.3499051750 (6278446271206)
Redo File: RAC4REDO/sss11g/onlinelog/group_4.292.716481937

Therefore, SKIPTRANS should be: SKIPTRANS xid THREAD 3.

Example 6

SEND EXTRACT finance, SHOWTRANS COUNT 2

Example 7

The following shows the default output of SHOWTRANS.

Oldest redo log file necessary to restart Extract is:
Redo Thread 1, Redo Log Sequence Number 148, SCN 30816254, RBA 17319664

XID : 5.15.52582
Items : 30000
Extract : JC108XT
Redo Thread : 1
Start Time : 2017-01-18:12:51:27
SCN : 20634955
Redo Seq : 103
Redo RBA : 18616848
Status : Running

XID : 7.14.48657
Items : 30000
Extract : JC108XT
Redo Thread : 1
Start Time : 2017-01-18:12:52:14
SCN : 20635145
Redo Seq : 103
Redo RBA : 26499088
Status : Running

Example 8

The following shows SHOWTRANS output with TABULAR in effect (view is
truncated on right)

XID Items Extract Redo Thread Start Time 5.15.52582 30000 JC108XT 1
2017-01-18:12:52:14

Dumping transaction memory at 2017-01-21 13:36:54.
Record #1:
Header (140 bytes):
0: 0000 0A4A 0000 FFFF 0000 0000 0057 6C10 ...J.........Wl.
16: 02FF 3F50 FF38 7C40 0303 4141 414E 5A77 ..?P.8|@..AAANZw
32: 4141 4641 4141 4B6F 4941 4144 0041 4141 AAFAAAKoIAAD.AAA
48: 4E5A 7741 4146 4141 414B 6F49 4141 4400 NZwAAFAAAKoIAAD.
64: 4141 414E 5A77 414A 2F41 4142 7A31 7741 AAANZwAJ/AABz1wA
80: 4141 0041 4141 4141 4141 4141 4141 4141 AA.AAAAAAAAAAAAA
96: 4141 4141 4100 0000 0140 FF08 0003 0000 AAAAA....@......
112: 0000 0000 0000 70FF 0108 FFFF 0001 4A53 ......p.......JS
128: 554E 2E54 4355 5354 4D45 5200 UN.TCUSTMER.
Data (93 bytes):
0: 2C00 0400 0400 0000 0100 0200 0300 0000 ,...............
16: 0000 0000 0800 0000 1800 0000 2000 0400 ............ ...
32: 1000 0600 0200 0000 284A 414E 456C 6C6F ........(JANEllo
48: 6352 4F43 4B59 2046 4C59 4552 2049 4E43 cROCKY FLYER INC
64: 2E44 454E 5645 5220 6E43 4F20 7365 7400 .DENVER nCO set.
80: 0000 0000 0000 0C00 0000 0000 00 ..............

When analyzing the summary output of SHOWTRANS, understand that it shows
all currently running transactions on the database (as many as will fit
into a predefined buffer). Extract must track every open transaction, not
just those that contain operations on tables configured for Oracle
GoldenGate.

The Items field of the SHOWTRANS output shows the number of operations in the
transaction that have been captured by Oracle GoldenGate so far, not the total number
of operations in the transaction. If none of the operations are for configured tables, or
if only some of them are, then Items could be 0 or any value less than the total
number of operations.

The Start Time field shows the timestamp of the first operation that Oracle
GoldenGate extracts from a transaction, not the actual start time of the transaction
itself

Note:
Command output may vary somewhat from the examples shown due ongoing enhancements
of Oracle GoldenGate.

---------------------------------------------------------------------
START EXTRACT

Use START EXTRACT to start the Extract process. To confirm that Extract has started,
use the INFO EXTRACT or STATUS EXTRACT command. Extract can be started at its normal
start point (from initial or current checkpoints) or from an alternate, user-specified
position in the data source.

Normal Start Point

Without options, START EXTRACT directs a primary Extract and a data pump Extract to
start processing at one of the following locations in the data source to maintain
data integrity:

* After graceful or abnormal termination: At the first unprocessed transaction
in the data source from the previous run, as represented by the current read checkpoint.

* First-time startup after the group was created: At the start point specified
with the ADD EXTRACT command.
See Administering Oracle GoldenGate for more information about checkpoints.

Extract also can be started from the command line of the operating system
for certain synchronization configurations. For more information on the proper
configuration and startup method to use for your purposes, see Administering
Oracle GoldenGate.

Alternate Start Point

The ATCSN and AFTERCSN options enable you to establish a logical starting point
for a primary Extract or a data pump, after you establish an approximate physical
starting point with the ADD EXTRACT or ALTER EXTRACT command. For example, in an
initial-load scenario, after a backup is applied to the target, the serial
identifier of the last transaction (such as an Oracle SCN) can be mapped
to an Oracle GoldenGate CSN (commit sequence number) value, which can be
used to start Extract with the AFTERCSN option. By starting with the first
transaction after the specified CSN, Extract omits the transactions that
were included in the backup, which would otherwise cause duplicate-record
and missing-record errors.

Before starting Extract with ATCSN or AFTERCSN, you must establish a physical
starting location with one of the following commands:

* ADD EXTRACT with the BEGIN option set to a timestamp that is earlier than the
CSN value specified with ATCSN or AFTERCSN. The transaction log that contains
the timestamp and every log thereafter must be available on the system before
Extract is started.

* ALTER EXTRACT to the sequence number of the log that contains the CSN
specified with ATCSN or AFTERCSN.

Note:
See Administering Oracle GoldenGate for more information about the values that
comprise a CSN for a given database.

Syntax

START EXTRACT group_name [ATCSN csn | AFTERCSN csn]

group_name

The name of an Extract group or a wildcard (*) to specify multiple groups. For
example, T* starts all Extract groups whose names begin with T.

ATCSN csn | AFTERCSN csn

Specifies an alternate start point. (See "Alternate Start Point" for usage instructions.)

ATCSN
Directs Extract to position its start point at the first transaction that
has the specified CSN. Any transactions in the data source that have CSN
values less than the specified one are skipped.

AFTERCSN
Directs Extract to position its start point at the beginning of the first
transaction after the one that has the specified CSN. Any transactions in
the data source that have CSN values that are less than, or equal to, the
specified one are skipped.

csn
Specifies a CSN value. Enter the CSN value in the format that is valid for
the database. See Administering Oracle GoldenGate for CSN formats and descriptions.
Extract abends if the format is invalid and writes a message to the report file.
To determine the CSN to supply after an initial load is complete, use the serial
identifier at which the load utility completed. Otherwise, follow the instructions
in the initial load procedure for determining when to start Extract.

The following are additional guidelines to observe when using ATCSN and AFTERCSN:

* To support starting at, or after, a CSN, the trail must be of Oracle GoldenGate
version 10.0.0 or later, because the CSN is stored in the file header so that it
is available to downstream processes.

* When a record that is specified with a CSN is found, Extract issues a checkpoint.
The checkpoint ensures that subsequent Extract startups begin from the requested
location, and not from a point prior to the requested CSN.

* You must establish a physical start point in the transaction log or trail for
Extract with ADD EXTRACT or ALTER EXTRACT before using ATCSN or AFTERCSN. These
options are intended to be an additional filter after Extract is positioned to
a physical location in the data source.

Examples

Example 1

START EXTRACT finance

Example 2

START EXTRACT finance ATCSN 684993

Example 3

START EXTRACT finance AFTERCSN 684993

---------------------------------------------------------------------
STATS EXTRACT

Use STATS EXTRACT to display statistics for one or more Extract groups. The output
includes DML and DDL operations that are included in the Oracle GoldenGate
configuration.

To get the most accurate number of operations per second that are being processed,
do the following.

1. Issue the STATS EXTRACT command with the RESET option.

2. Issue the STATS EXTRACT REPORTRATE command. The LATEST STATISTICS field shows
the operations per second.

Note:
The actual number of DML operations executed on a DB2 database might not match
the number of extracted DML operations reported by Oracle GoldenGate. DB2 does
not log update statements if they do not physically change a row, so Oracle
GoldenGate cannot detect them or include them in statistics.

To get accurate statistics on a Teradata source system where Oracle GoldenGate
is configured in maximum protection mode, issue STATS EXTRACT to the VAM-sort
Extract, not the primary Extract. The primary Extract may contain statistics for
uncommitted transactions that could be rolled back; whereas the VAM-sort Extract
reports statistics only for committed transactions.

Syntax

STATS EXTRACT group_name
statistic]
TABLE [container. | catalog.]schema.table]
TOTALSONLY [container. | catalog.]schema.table]
REPORTCHARCONV]
REPORTFETCH | NOREPORTFETCH]
REPORTRATE time_units]
... ]

group_name

The name of an Extract group or a wildcard (*) to specify multiple groups. For
example, T* returns statistics for all Extract groups whose names start with T.

statistic

The statistic to be displayed. More than one statistic can be specified by
separating each with a comma, for example STATS EXTRACT finance, TOTAL, DAILY.

Valid values:

TOTAL
Displays totals since process startup.

DAILY
Displays totals since the start of the current day.

HOURLY
Displays totals since the start of the current hour.

LATEST
Displays totals since the last RESET command.

RESET
Resets the counters in the LATEST statistical field.

TABLE [container. | catalog.]schema.table

Displays statistics only for the specified table or a group of tables
specified with a wildcard (*). The table name or wildcard specification
must be fully qualified with the two-part or three-part name, for example
hr.empor *.*.*.

TOTALSONLY [container. | catalog.]schema.table

Summarizes the statistics for the specified table or a group of tables
specified with a wildcard (*). The table name or wildcard specification
must be fully qualified with the two-part or three-part name, for example
hr.empor *.*.*.

REPORTCHARCONV

Use only when TABLE parameters have a TARGET clause and character-set
conversion is performed. The following statistics are added to the STATS
output:

Total column character set conversion failure: the number of validation
or conversion failures in the current Extract run.

Total column data truncation: the number of times that column data was
truncated in the current Extract run as the result of character set conversion

REPORTFETCH | NOREPORTFETCH

Controls whether or not statistics about fetch operations are included
in the output. The default is NOREPORTFETCH. See “STATOPTIONS” for defaults
that control fetching and options for altering fetch behavior. The output of
REPORTFETCH is as follows:

* row fetch attempts: The number of times Extract attempted to fetch a column
value from the database when it could not obtain the value from the transaction log.

* fetch failed: The number of row fetch attempts that failed.

* row fetch by key: Valid for Oracle. The number of row fetch attempts that
were made by using the primary key. The default is to fetch by row ID.

REPORTRATE time_units

Displays statistics in terms of processing rate rather than absolute values.

Valid values:

HR
MIN
SEC

Example

Example 1

The following example displays total and hourly statistics per minute for a
specific table, and it also resets the latest statistics and outputs fetch
statistics.

STATS EXTRACT finance, TOTAL, HOURLY, TABLE hr.acct, REPORTRATE MIN, RESET,
REPORTFETCH

Example 2

The following is sample output using the LATESTand REPORTFETCH options

STATS EXTRACT ext, LATEST, REPORTFETCH
Sending STATS request to EXTRACT GGSEXT...
Start of Statistics at 2017-01-08 11:45:05.
DDL replication statistics (for all trails):
*** Total statistics since extract started ***

Operations 3.00
Mapped operations 3.00
Unmapped operations 0.00
Default operations 0.00
Excluded operations 0.00

Output to ./dirdat/aa:
Extracting from HR.EMPLOYEES to HR.EMPLOYEES:
*** Latest statistics since 2017-01-08 11:36:55 ***

Total inserts 176.00
Total updates 0.00
Total deletes 40.00
Total discards 0.00
Total operations 216.00

Extracting from HR.DEPARTMENTS to HR.DEPARTMENTS:
*** Latest statistics since 2017-01-08 11:36:55 ***
No database operations have been performed.
End of Statistics.

---------------------------------------------------------------------
STATUS EXTRACT

Use STATUS EXTRACT to determine whether or not Extract is running. A status
of RUNNING can mean one of the following:

* Active: Running and processing (or able to process) data. This is the
normal state of a process after it is started.

* Suspended: The process is running, but suspended due to an EVENTACTIONS SUSPEND
action. In a suspended state, the process is not active, and no data can be
processed, but the state of the current run is preserved and can be continued by
issuing the RESUME command in GGSCI. The RBA in the INFO command reflects the last
checkpointed position before the suspend action. To determine whether the state
is active or suspended, issue the SEND EXTRACT command with the STATUS option.

Syntax

STATUS EXTRACT group_name TASKS | ALLPROCESSES] [UPGRADE | DOWNGRADE]

group_name

The name of an Extract group or a wildcard (*) to specify multiple groups.
For example, T* returns status for all Extract groups whose names begin with T.

TASKS

Displays status only for Extract tasks. By default, tasks are not displayed
unless you specify a single Extract group (without wildcards).

ALLPROCESSES

Displays status for all Extract groups, including tasks.

UPGRADE | DOWNGRADE

Valid for an Oracle Database only. If Extract cannot be upgraded or downgraded,
the reason why is displayed. A wildcarded Extract name is not allowed with this
option. Before using this command, issue the DBLOGIN command.

UPGRADE
Displays whether the Extract can be upgraded from classic capture mode to
integrated capture mode.

DOWNGRADE
Displays whether the Extract can be downgraded from integrated capture
mode to classic capture mode.

Examples

Example 1

STATUS EXTRACT finance

Example 2

STATUS EXTRACT fin*

---------------------------------------------------------------------
STOP EXTRACT

Use STOP EXTRACT to stop Extract gracefully. The command preserves the state
of synchronization for the next time Extract starts, and it ensures that
Manager does not automatically start Extract.

If there are open, long-running transactions when you issue STOP EXTRACT, you
might be advised of the oldest transaction log file that will be needed for
that transaction when Extract is restarted. You can use the SEND EXTRACT option
of SHOWTRANS to view details and data of those transactions and then, if desired,
use the SKIPTRANS or FORCETRANS options to skip the transaction or force it to be
written as a committed transaction to the trail. See “SEND EXTRACT”.

Syntax

STOP EXTRACT group_name

group_name

The name of an Extract group or a wildcard (*) to specify multiple groups.
For example, T* stops all Extract processes for groups whose names begin with T.

STOP EXTRACT finance

--------------------------------------------------------------------
FORCEAPPEND

FORCEAPPEND instructs Extracts, primary or data pump, to forgive the missing CSN information in existing output trails during recovery stage, so that the new trail files can be seemingly appended to the existing ones.

Syntax

START data_pump FORCEAPPEND

data_pump

The name of the Extract data pump for which the FORCEAPPEND option needs to be applied.

Example:

START EXT1PMP FORCEAPPEND

--------------------------------------------------------------------
UNREGISTER EXTRACT

UNREGISTER EXTRACT

Use UNREGISTER EXTRACT to remove the registration of an Extract group from an
Oracle Database. UNREGISTER EXTRACT is valid only for a primary Extract group.
Do not use it for a data pump Extract.

To register an Extract group with the database, use the REGISTER EXTRACT command.

To upgrade an Extract from classic capture mode to integrated capture mode, use
the ALTER EXTRACT command.

See the Oracle GoldenGate documentation for your database for more
information about configuring and registering Oracle GoldenGate for
Oracle Database.

Syntax

UNREGISTER EXTRACT group_name
{DATABASE | LOGRETENTION}

group_name

The name of the Extract group that is to be unregistered from the database. Do
not use a wildcard. This group must currently be registered with the database.

DATABASE

Disables integrated capture mode for the Extract group.

This command removes the database capture (mining) server that has the same name
as the Extract group. For additional information about support for, and
configuration of, the Extract capture modes, see the Oracle GoldenGate documentation
for your database.

Before using UNREGISTER EXTRACT with DATABASE, do the following:

1. Stop Extract with the STOP EXTRACT command.

2. Log in to the mining database with the DBLOGIN or MININGDBLOGIN command with the
privileges granted in the dbms_goldengate_auth.grant_admin_privilege procedure.
For local capture, DBLOGIN is required. For downstream capture, DBLOGIN and
MININGDBLOGIN are both required.

3. Delete the Extract group with DELETE EXTRACT.

LOGRETENTION

Disables log retention for the specified Extract group and removes the underlying
Oracle Streams capture process. Use UNREGISTER EXTRACT with LOGRETENTION only if
you no longer want to capture changes with this Extract group. The log-retention
feature is controlled with the LOGRETENTION option of the TRANLOGOPTIONS parameter.

Before using UNREGISTER EXTRACT with LOGRETENTION, stop Extract with the STOP EXTRACT
command. Next, issue the DBLOGIN command with the privileges shown in Examples 1–2.

Examples

Example 1

UNREGISTER EXTRACT sales LOGRETENTION

Example 2

UNREGISTER EXTRACT sales DATABASE

---------------------------------------------------------------------
####################################
#
#REPLICAT COMMANDS
#
#
####################################
---------------------------------------------------------------------
ADD REPLICAT

Use ADD REPLICAT to create a Replicat group. Unless SPECIALRUN is specified,
ADD REPLICAT creates an online process group that creates checkpoints so
that processing continuity is maintained from run to run.

This command cannot exceed 500 bytes in size for all keywords and input,
including any text that you enter for the DESC option.

Oracle GoldenGate supports up to 5,000 concurrent Extract and Replicat groups
per instance of Oracle GoldenGate Manager. At the supported level, all groups
can be controlled and viewed in full with GGSCI commands such as the INFO and
STATUS commands. Oracle GoldenGate recommends keeping the number of Extract and
Replicat groups (combined) at the default level of 300 or below in order to
manage your environment effectively.

(Oracle) Unless the INTEGRATED option is used, this command creates a Replicat
group in non-integrated mode.

Syntax

ADD REPLICAT group_name
INTEGRATED | COORDINATED [MAXTHREADS number]]
{, SPECIALRUN |
, EXTFILE file_name |
, EXTTRAIL trail_name}
BEGIN {NOW | yyyy-mm-dd[ hh:mm[:ss[.cccccc]]]} |
, EXTSEQNO sequence_number, EXTRBA rba]
{PARALLEL | PARALLEL INTEGRATED EXTTRAIL trail_name ,
CHECKPOINTTABLE owner.table | NODBCHECKPOINT}
PARAMS file_name]
REPORT file_name]
DESC 'description']

group_name

The name of the Replicat group. The name of a coordinated Replicat group
can contain a maximum of five characters. The name of a regular Replicat
group can contain up to eight characters. See Administering Oracle
GoldenGate for more information about naming conventions
for process groups.

INTEGRATED

(Oracle) Creates the Replicat in integrated mode. Without this option,
ADD REPLICAT creates the Replicat in non-integrated (classic) mode. In this
mode, the Replicat process leverages the apply processing functionality that
is available within the Oracle Database. In this mode, Replicat operates
as follows:

* Reads the Oracle GoldenGate trail.

* Performs data filtering, mapping, and conversion.

* Constructs logical change records (LCR) that represent source database DML
or DDL transactions (in committed order).

* Attaches to a background process in the target database known as a database
inbound server by means of a lightweight streaming interface.

* Transmits the LCRs to the inbound server, which applies the data to the
target database.

Do not use INTEGRATED with the SPECIALRUN or EXTFILE options. INTEGRATED must
be used for an online change-synchronization Replicat that reads from a local
EXTTRAIL-specified trail.
Integrated Replicat does not require a checkpoint table (ADD CHECKPOINTTABLE
command and CHECKPOINTTABLE parameter) or a trace table (TRACETABLE parameter).
Integrated Replicat does not maintain either of these tables.
When in integrated mode, Replicat does not support the following parameters:

* BULKLOAD(Do not use integrated Replicat as an initial-load Replicat.)

* SPECIALRUN

* GENLOADFILES

* SHOWSYNTAX

* MAXTRANSOPS(is ignored)

See the Oracle GoldenGate documentation for your database for more information
about configuring and using integrated Replicat.

COORDINATED [MAXTHREADS number]

Creates the Replicat in coordinated mode. A coordinated Replicat is
multithreaded to enable parallel processing. This option adds the coordinator
(identified by the group name itself) and the maximum number of processing
threads that are specified by default or with MAXTHREADS. Dependencies are
computed and coordinated by the coordinator, and the SQL processing is
performed by the threads.

Do not use COORDINATED with the SPECIALRUN or EXTFILE options. COORDINATED
must be used for an online change-synchronization Replicat that reads from
a local EXTTRAIL-specified trail. For more information about coordinated
Replicat, see Administering Oracle GoldenGate.

Note:
Note that the group name of a coordinated Replicat can contain only
five characters. See Administering Oracle GoldenGate for more information
about naming conventions for process groups.

MAXTHREADS number
Specifies the maximum number of processing threads that this Replicat
group can spawn. These threads are all created on startup, but depending
on what is specified in the MAP statements in the parameter file, some or
all of these threads will process the workload at any given time. As a
general rule, specify twice the number of threads that you specify in the
MAP statements when you partition the workload. This allows you to add
threads in the event that the workload increases, without having to drop
and recreate the Replicat group. See Administering Oracle GoldenGate for
for more information about how to partition the workload
across threads.

The default number of threads is 25 if MAXTHREADS is omitted. The maximum
number of threads is 500.

MAXTHREADS has a relationship to the MAXGROUPS parameter. MAXGROUPS controls
the maximum number of process groups (Extract and Replicat) allowed per
instance of Oracle GoldenGate. Each Replicat thread is considered a Replicat
group in the context of MAXGROUPS. Therefore, the number of Extract and
Replicat groups in the Oracle GoldenGate instance, plus the value of
MAXTHREADS, cannot exceed the value of MAXGROUPS.

SPECIALRUN
Creates a Replicat special run as a task. Either SPECIALRUN, EXTFILE, or
EXTTRAIL is required. When Extract is in SPECIALRUN mode, do not start
Replicat with the START REPLICAT command in GGSCI. Do not use this option
with the INTEGRATED or COORDINATED option.

EXTFILE file_name
Specifies the relative or fully qualified name of an Extract file that is
specified with RMTFILE in the Extract parameter file. Do not use this option
with the INTEGRATED option.

EXTTRAIL trail_name
Specifies the relative or fully qualified name of a trail that was created
with the ADD RMTTRAIL or ADD EXTTRAIL command.

BEGIN {NOW | yyyy-mm-dd[ hh:mm[:ss[.cccccc]]]}
Defines an initial checkpoint in the trail.

NOW
Begins replicating changes from the time when the group is created.

yyyy-mm-dd[ hh:mm[:ss[.cccccc]]]
Begins extracting changes from a specific time.

EXTSEQNO sequence_number

Specifies the sequence number of the file in a trail in which to begin
processing data. Specify the sequence number, but not any zeroes used for
padding. For example, if the trail file is c:\ggs\dirdat/aa000000026, you
would specify EXTSEQNO 26.
By default, processing begins at the beginning of a trail unless this option
is used. To use EXTSEQNO, you must also use EXTRBA. Contact Oracle Support
before using this option.

EXTRBA rba

Specifies the relative byte address within the trail file that is specified
by EXTSEQNO. Contact Oracle Support before using this option.

(Oracle) PARALLEL

Adds the Replicat in parallel mode. In this mode, Replicat applies transactions in
parallel to improve the performance. It takes into account dependencies between
transactions. PARALLEL INTEGRATED adds the parallel Replicat in integrated mode,
which like Integrated Replicat leverages the apply processing functionality that is
available within the Oracle Database. You must use a checkpointtable with this Replicat.

CHECKPOINTTABLE owner.table

Not valid for Oracle GoldenGate Applications Adapter or Oracle GoldenGate Big
Data.

Specifies that this Replicat group will write checkpoints to the specified
table in the database. Include the owner and table name, as in hr.hr_checkpoint.
This argument overrides any default CHECKPOINTTABLE specification in the GLOBALS
file. The table must first be added with the ADD CHECKPOINTTABLE command. Do not
use this option with the INTEGRATED option. When NODBCHECKPOINT is specified, an
additional checkpoint file for Java is not created.

NODBCHECKPOINT

Specifies that this Replicat group will not write checkpoints to a checkpoint
table. This argument overrides any default CHECKPOINTTABLE specification in the
GLOBALS file. This argument is required if you do not want to use a checkpoint
table with the Replicat group that is being created. Do not use this option with
the INTEGRATED option.

PARAMS file_name

Specifies a parameter file in a location other than the default of dirprm
within the Oracle GoldenGate directory. Specify the fully qualified path name.

REPORT file_name

Specifies the full path name of a process report file in a location other
than the default of dirrpt within the Oracle GoldenGate directory.

DESC 'description'

Specifies a description of the group, such as 'Loads account_tab on Serv2'.
Enclose the description within quotes. You can use either the abbreviated
keyword DESC or the full word DESCRIPTION.

Examples

Example 1

ADD REPLICAT sales, EXTTRAIL dirdat/rt

Example 2

ADD REPLICAT sales, INTEGRATED, EXTTRAIL dirdat/rt

Example 3

This example creates Replicat in coordinated mode. It indicates that up
to 100 threads can be employed in parallel at any given point in processing.

ADD REPLICAT sales, COORDINATED MAXTHREADS 100, EXTTRAIL dirdat/rt

Example 4

ADD REPLICAT sales, PARALLEL, EXTTRAIL dirdat/rt , checkpointtable
ggadmin.checkpoint
Example 5

This example creates parallel Replicat in integrated mode.

ADD REPLICAT sales, PARALLEL INTEGRATED, EXTTRAIL dirdat/rt ,
checkpointtable ggadmin.checkpoint

---------------------------------------------------------------------
ALTER REPLICAT

Use ALTER REPLICAT to change the attributes of a Replicat group that was
created with the ADD REPLICAT command. Before using this command, stop
Replicat by issuing the STOP REPLICAT command. If this is a coordinated
Replicat group, the ALTER takes effect for all threads unless the threadID
option is used.

Note:
ALTER REPLICAT does not support switching from regular Replicat mode to
coordinated mode. You must stop processes, make certain all of the en route
data is applied to the target, roll the trail to a new trail, drop and
recreate the Replicat group in coordinated mode, and then start the processes
again.

Syntax

ALTER REPLICAT group_name[threadID], {
ADD REPLICAT option ...] |
INTEGRATED | NONINTEGRATED, CHECKPOINTTABLE owner.table }

group_name[threadID]

The name of the Replicat group or a thread of a coordinated Replicat that is
to be altered. To specify a thread, use the full thread name, such as ALTER
REPLICAT fin003, EXTSEQNO 53. If a thread ID is not specified, the ALTER takes
effect for all threads of the Replicat group.

ADD REPLICAT option

An ADD REPLICAT option. For a non-integrated Replicat, you can change the
description or any service option that was configured with the ADD REPLICAT
command, except for the CHECKPOINT and NODBCHECKPOINT options.

INTEGRATED

Switches Replicat from non-integrated mode to integrated mode. Transactions
currently in process are applied before the switch is made. See Administering
Oracle GoldenGate for the full procedure for performing the transition from
non-integrated to integrated Replicat.

NONINTEGRATED, CHECKPOINTTABLE owner.table

(Oracle) Switches Replicat from integrated mode to non-integrated mode.

For CHECKPOINTTABLE, specify the owner and name of a checkpoint table. This
table must be created with the ADD CHECKPOINTTABLE command before issuing ALTER
EXTRACT with NONINTEGRATED.

See Administering Oracle GoldenGate for the full procedure for performing
the transition from integrated Replicat to non-integrated Replicat.

See the Oracle GoldenGate documentation for your database for more information
about integrated Replicat.

Examples

Example 1

ALTER REPLICAT finance, EXTSEQNO 53

Example 2

ALTER REPLICAT finance, EXTRBA 0

Example 3

ALTER REPLICAT finance, BEGIN 2017-01-07 08:00:00

Example 4

ALTER REPLICAT finance, INTEGRATED

Example 5

ALTER REPLICAT finance, NONINTEGRATED, CHECKPOINTTABLE ogg.checkpt

Example 6

ALTER REPLICAT fin001, EXTSEQNO 53

---------------------------------------------------------------------
CLEANUP REPLICAT

Use CLEANUP REPLICAT to delete run history for a specified Replicat group.
The cleanup keeps the last run record intact so that Replicat can resume
processing from where it left off.

Before using this command, stop Replicat by issuing the STOP REPLICAT command.

Syntax

CLEANUP REPLICAT group_name[threadID] SAVE count]

group_name[threadID]

One of the following:

* group_name: The name of a Replicat group or a wildcard (*) to specify
multiple groups. For example, T* cleans up all Replicat groups whose names
begin with T. If the specified group (or groups) is a coordinated Replicat,
the cleanup applies to all threads.

* group_namethreadID: A thread of a coordinated Replicat, identified by its
full name (group name plus threadID), such as finance003.

SAVE count

Excludes the specified number of the most recent records from the cleanup.

Examples

Example 1

The following deletes all but the last record.

CLEANUP REPLICAT finance

Example 2

The following deletes all but the most recent five records.

CLEANUP REPLICAT *, SAVE 5

Example 3

The following deletes all but the most recent five records for thread 3
of coordinated Replicat group fin.

CLEANUP REPLICAT fin003, SAVE 5

---------------------------------------------------------------------
DELETE REPLICAT

Use DELETE REPLICAT to delete a Replicat group. This command deletes the
checkpoint file but leaves the parameter file intact. Then you can re-create
the group or delete the parameter file as needed. This command frees up
trail files for purging by Manager, because the checkpoints used by the
deleted group are removed (assuming no other processes are reading the file).
Before using DELETE REPLICAT, stop Replicat with the STOP REPLICAT command.

If this is an integrated Replicat (Oracle only) or a non-integrated Replicat
that uses a checkpoint table, do the following after you stop Replicat:

1. Log into the database by using the DBLOGIN command. DBLOGIN enables DELETE
REPLICAT to delete the checkpoints from the checkpoint table of a non-integrated
Replicat or to delete the inbound server that an integrated Replicat uses.
For more information, see “DBLOGIN”.

2. Issue DELETE REPLICAT.

Syntax

DELETE REPLICAT group_name [!]

group_name

The name of a Replicat group or a wildcard (*) to specify multiple groups.
For example, T* deletes all Replicat groups whose names begin with T.

!
Use this option to force the Replicat group to be deleted if the DBLOGIN command
is not issued before the DELETE REPLICAT command is issued. If the group is
a nonintegrated Replicat, this option deletes the group's checkpoints from
the checkpoint file on disk, but not from the checkpoint table in the database.
If using this option to delete an integrated Replicat group, you must use the
UNREGISTER REPLICAT command to delete the inbound server from the target
database. This option can also be used to ignore the prompt that occurs
when a wildcard specifies multiple groups.

Note:
The basic DELETE REPLICAT command commits an existing Replicat transaction,
but the ! option prevents the commit.

Example

DELETE REPLICAT finance

---------------------------------------------------------------------
INFO REPLICAT

Use INFO REPLICAT to retrieve the processing history of a Replicat group.
The output of this command includes:

* The status of Replicat (STARTING, RUNNING, STOPPED or ABENDED). STARTING
means that the process has started but has not yet locked the checkpoint
file for processing.

* (Oracle Database) The Replicat mode: non-integrated or integrated.

* Whether or not Replicat is in coordinated mode and, if so, how many
threads it currently uses.

* Approximate Replicat lag.

* The trail from which Replicat is reading.

* Replicat run history, including checkpoints in the trail.

* Information about the Replicat environment.

The basic command displays information only for online (continuous) Replicat
groups. Tasks are excluded.
Replicat can be stopped or running when INFO REPLICAT is issued. In the case
of a running process, the status of RUNNING can mean one of the following:

* Active: Running and processing (or able to process) data. This is the normal
state of a process after it is started.

* Suspended: The process is running, but suspended due to an EVENTACTIONS
SUSPEND action. In a suspended state, the process is not active, and no data
can be processed, but the state of the current run is preserved and can be
continued by issuing the RESUME command in GGSCI. The RBA in the INFO command
reflects the last checkpointed position before the suspend action. To
determine whether the state is active or suspended, issue the SEND REPLICAT
command with the STATUS option.

About Lag

Checkpoint Lag is the lag, in seconds, at the time the last checkpoint was
written to the trail. For example, consider the following example.

* Current time = 15:00:00

* Last checkpoint = 14:59:00

* Timestamp of the last record processed =14:58:00

Assuming these values, the lag is reported as 00:01:00 (one minute, the
difference between 14:58 and 14:59).

A lag value of UNKNOWN indicates that Replicat could be running but has
not yet processed records, or that the source system's clock is ahead of
the target system's clock (due to clock imperfections, not time zone
differences). For more precise lag information, use LAG REPLICAT.

Syntax

INFO REPLICAT group_name[thread id]
[DETAIL]
[SHOWCH [n]]
[TASKS | ALLPROCESSES]

group_name[thread id]

The name of:

* A Replicat group or a wildcard (*) to specify multiple groups. For
example, T* shows information for all Replicat groups whose names begin
with T.

* A thread of a coordinated Replicat, identified by its full name. For
example, fin003 shows information only for thread 3 of the fin group.

DETAIL

Displays detail information. For an Oracle target, DETAIL displays the
name of the inbound server when Replicat is in integrated mode. See
Example 4.

To view LOGBSN information with the DETAIL output, issue the DBLOGIN
command before you issue INFO REPLICAT. If the command is issued for
a specific thread ID of a coordinated Replicat, only the LOGBSN for
that thread is displayed. Otherwise, the LOGBSNs for all threads are
displayed. For more information about recovering Extract by using the
LOGBSN, see Administering Oracle GoldenGate.

If Replicat is in coordinated mode, DETAIL will display only the active
threads. For example, if a Replicat named CR was created with a maximum
of 15 threads, but only threads 7-9 are running, INFO REPLICAT group_name
with DETAIL will show only the coordinator thread (CR), CR007, CR008, and
CR009. Checkpoints will exist for the other threads, but they will not be
shown in the command output. See the examples for sample output.

SHOWCH [n]

Displays current checkpoint details, including those recorded to the
checkpoint file and those recorded to the checkpoint table, if one is
being used. The database checkpoint display includes the table name,
the hash key (unique identifier), and the create timestamp.

Specify a value for n to include the specified number of previous checkpoints
as well as the current one.

TASKS

Displays only Replicat tasks. Tasks that were specified by a wildcard
argument are not displayed by INFO REPLICAT.

ALLPROCESSES

Displays all Replicat groups, including tasks.

Examples

Example 1

INFO REPLICAT *, DETAIL, ALLPROCESSES

Example 2

INFO REPLICAT *, TASKS

Example 3

INFO REPLICAT fin003, SHOWCH

Example 4

The following shows sample output of INFO REPLICAT with DETAIL.

REPLICAT DELTPCC Last Started 2017-01-21 11:40 Status RUNNING
Checkpoint Lag 00:00:00 (updated 232:39:41 ago)
Log Read Checkpoint File C:\GGS\DIRDAT\RT000000000
2017-01-21 18:54:33.000000 RBA 4735245

Extract Source Begin End
C:\GGS\DIRDAT\RT000000000 2017-01-21 18:54 2017-01-21 18:54
C:\GGS\DIRDAT\RT000000000 * Initialized * 2017-01-21 18:54

Current directory C:\GGS
Report file C:\GGS\dirrpt\DELTPCC.rpt
Parameter file dirprm\DELTPCC.prm
Checkpoint file C:\GGS\dirchk\DELTPCC.cpr
Checkpoint table GG.CHECKPT
Process file C:\GGS\dirpcs\DELTPCC.pcr
Error log C:\GGS\ggserr.log

Example 5

The following shows INFO EXTRACT with DETAIL for a coordinated Replicat.

GGSCI (sysa) 3 info ra detail

REPLICAT RA Last Started 2017-05-01 14:15 Status RUNNING
COORDINATED Coordinator MAXTHREADS 15
Checkpoint Lag 00:00:00 (updated 00:00:07 ago)
Process ID 11445
Log Read Checkpoint File ./dirdat/withMaxTransOp/bg000000001
2017-05-02 07:49:45.975662 RBA 44704

Lowest Log BSN value: (requires database login)

Active Threads:
ID Group Name PID Status Lag at Chkpt Time Since Chkpt
1 RA001 11454 RUNNING 00:00:00 00:00:01
2 RA002 11455 RUNNING 00:00:00 00:00:04
3 RA003 11456 RUNNING 00:00:00 00:00:01
5 RA005 11457 RUNNING 00:00:00 00:00:02
6 RA006 11458 RUNNING 00:00:00 00:00:04
7 RA007 11459 RUNNING 00:00:00 00:00:04

Current directory /scratch/vara/view_storage/vara_gg7/work/worklv/oggora1
Report file /scratch/vara/view_storage/vara_gg7/work/worklv/oggora1/dirrpt/
RA.rpt
Parameter file /net/slc03jgo/scratch/vara/view_storage/vara_gg7/work/worklv/ oggora1/dirprm/ra.prm
Checkpoint file /scratch/vara/view_storage/vara_gg7/work/worklv/oggora1/dirchk/
RA.cpr Checkpoint table atstgt.checkPoint_ra
Process file /scratch/vara/view_storage/vara_gg7/work/worklv/oggora1/dirpcs/
RA.pcr
Error log /scratch/vara/view_storage/vara_gg7/work/worklv/oggora1/
ggserr.log

Example 6

The following shows INFO EXTRACT with DETAIL for a threadID of a coordinated
Replicat.

GGSCI (sysa) 5 info ra002 detail

REPLICAT RA002 Last Started 2017-05-01 14:15 Status RUNNING
COORDINATED Replicat Thread Thread 2
Checkpoint Lag 00:00:00 (updated 00:00:02 ago)
Process ID 11455
Log Read Checkpoint File ./dirdat/withMaxTransOp/bg000000001
2017-05-01 14:13:37.000000 RBA 44704

Current Log BSN value: (requires database login)

Extract Source Begin End
./dirdat/withMaxTransOp/bg000000001 2017-05-01 14:11 2017-05-01 14:13
./dirdat/withMaxTransOpbg000000001 2017-05-01 14:11 2017-05-01 14:11
./dirdat/withMaxTransOp/bg000000001 * Initialized * 2017-05-01 14:11
./dirdat/withMaxTransOp/bg000000001 * Initialized * First Record
Current directory /scratch/vara/view_storage/vara_gg7/work/worklv/oggora1
Report file /scratch/vara/view_storage/vara_gg7/work/worklv/oggora1/
dirrpt/ RA002.rpt
Parameter file /net/slc03jgo/scratch/vara/view_storage/vara_gg7/work/worklv/ oggora1/dirprm/ra.prm
Checkpoint file /scratch/vara/view_storage/vara_gg7/work/worklv/oggora1/
dirchk/
RA002.cpr
Checkpoint table atstgt.checkPoint_ra
Process file /scratch/vara/view_storage/vara_gg7/work/worklv/oggora1/dirpcs/
RA002.pcr
Error log /scratch/vara/view_storage/vara_gg7/work/worklv/oggora1/
ggserr.log

---------------------------------------------------------------------
KILL REPLICAT

Use KILL REPLICAT to kill a Replicat process. Killing a process leaves the
most recent checkpoint in place, and the current transaction is rolled back
by the database, guaranteeing that no data is lost when the process is
restarted. The Manager process will not attempt to restart a killed Replicat
process. Use this command only if Replicat cannot be stopped gracefully with
the STOP REPLICAT command.

Syntax

KILL REPLICAT group_name

group_name

The name of a Replicat group or a wildcard (*) to specify multiple groups.
For example, T* kills all Replicat processes whose group names begin with T.

Example

KILL REPLICAT finance

---------------------------------------------------------------------
LAG REPLICAT

Use LAG REPLICAT to determine a true lag time between Replicat and the trail.
LAG REPLICAT estimates the lag time more precisely than INFO REPLICAT because
it communicates with Replicat directly rather than reading a checkpoint position.

For Replicat, lag is the difference, in seconds, between the time that the last
record was processed by Replicat (based on the system clock) and the timestamp
of the record in the trail.

If the heartbeat functionality is enable, you can view the associated lags.
A DBLOGIN is required to view the heartbeat lag.

Syntax

LAG REPLICAT

[group_name[threadID]name]
[GLOBAL]

group_name[threadID]
The name of:

* A Replicat group or a wildcard (*) to specify multiple groups. For
example, T* shows lag for all Replicat groups whose names begin with T.

* A thread of a coordinated Replicat, identified by its full name. For
example, fin003 shows lag for thread 3 of coordinated Replicat fin.

GLOBAL

Displays the lags in the GG_LAGS view.

Examples

Example 1

LAG REPLICAT *

Example 2

LAG REPLICAT *fin*

---------------------------------------------------------------------
REGISTER REPLICAT

Use the REGISTER REPLICAT command to register a Replicat group with a
target Oracle Database to support integrated Replicat mode. This command
should not be necessary under normal Replicat conditions. The startup
registers Replicat with the target database automatically. Use this
command only if Oracle GoldenGate returns a message that an integrated
Replicat is not registered with the database.

Before issuing this command, issue the DBLOGIN command as the Replicat
database user with privileges granted through
dbms_goldengate_auth.grant_admin_privilege.

Syntax

group_name

The name of a Replicat group or a wildcard (*) to specify multiple groups. For
example, T* registers all Replicat groups whose names begin with T.

DATABASE

Required keyword to register with the target database. Creates a
database inbound server and associates it with the specified Replicat group.

Example

Use SEND REPLICAT to communicate with a starting or running Replicat process.
The request is processed as soon as Replicat is ready to accept commands
from users.

Syntax

SEND REPLICAT group_name[threadID],
{

CACHEMGR {CACHESTATS | CACHEQUEUES | CACHEVMUSAGE} |
DEPENDENCYINFO|DEPINFO [TXNCOUNT num] |
FORCESTOP |
GETLAG |
GETPARAMINFO [parameter_name] [FILE output_file] |
HANDLECOLLISIONS | NOHANDLECOLLISIONS [table_spec] |
INTEGRATEDPARAMS(parameter_specification) |
REPORT [HANDLECOLLISIONS [table_spec]] |
RESUME |
STATUS |
STOP |
TRACE[2] [DDLINCLUDE | DDL[ONLY]] file_name |
TRACE[2] OFF |
TRACE OFF file_name |
TRACEINIT |
THREADS (threadID threadID] ...] thread_range thread_range]
...])
}

group_name[threadID]

The name of the Replicat group or the name of a specific thread of a
coordinated Replicat, for example fin003. If the command is issued for a
specific thread, then an option that is used applies only to that thread.
As an alternative, you can issue SEND REPLICAT with the THREADS option
instead of including threadID with the group name. If Replicat is not
running, an error is returned.

CACHEMGR {CACHESTATS | CACHEQUEUES | CACHEVMUSAGE}

Returns statistics about the Oracle GoldenGate memory cache manager.

CACHESTATS
Returns all CACHEMGR statistics.

CACHEQUEUES
Returns statistics for the free queues only.

CACHEVMUSAGE
Returns statistics for the virtual memory usage.

DEPENDENCYINFO|DEPINFO [TXNCOUNT num]

Prints out information from PR transaction dependency graph.
First, it shows the transaction groups currently being executed and then
the transactions waiting on some other due to a dependency.

TXNCOUNT: Determines the number of waiting transactions to print.
Default value is 10 and maximum is 99.

FORCESTOP

Forces Replicat to stop, bypassing any notifications. This command will
roll back any active transaction and stop the process immediately. This
command applies to Replicat as a whole and cannot be used for a specific
Replicat thread.

GETLAG

Shows a true lag time between Replicat and the trail. Lag time is the
difference, in seconds, between the time that the last record was processed
by Replicat and the timestamp of the record in the trail. The results
are the same as LAG REPLICAT.

GETPARAMINFO [parameter_name] [FILE output_file]

Use GETPARAMINFO to query runtime parameter values of a running instance,
including Extract, Replicat, and Manager. You can query for a single
parameter or all parameters and send the output to the console or a text
file.

parameter_name

The default behavior is to display all parameters in use, meaning
those parameters that have ever been queried by the application,
parameters, and their current values. If you specify a particular
parameter, then the output is filtered by that name.

FILEoutput_file

The name of the text file that your output is redirected to.

HANDLECOLLISIONS | NOHANDLECOLLISIONS [table_spec]

Control HANDLECOLLISIONS behavior. Instead of using this option, you can
specify the HANDLECOLLISIONS or NOHANDLECOLLISIONS parameter in the
Replicat parameter file. This command can be sent directly
to an individual thread by means of SEND REPLICAT group_name[threadID]
or you can use the THREADS option to send the command through the
coordinator thread to affect multiple threads.

HANDLECOLLISIONS

Use HANDLECOLLISIONS to enable automatic error handling when performing
initial data loads while the source database is active. Make certain to
disable HANDLECOLLISIONS, either by issuing SEND REPLICAT with the
NOHANDLECOLLISIONS option or by removing the parameter from the parameter
file, after the initial load is complete and online data changes have
been applied to the target tables.

Note:
The message returned by SEND REPLICAT with HANDLECOLLISIONS, when issued
for a specific Replicat thread, shows that the command set HANDLECOLLISIONS
for all MAP statements, not only the one handled by the specified thread.
This is a known issue. The command actually affects only the MAP statement
that includes the specified thread.

NOHANDLECOLLISIONS

Turns off the HANDLECOLLISIONS parameter but does not remove it from the
parameter file. To avoid enabling HANDLECOLLISIONS the next time Replicat
starts, remove it from the parameter file.

table_spec

table_spec restricts HANDLECOLLISIONS or NOHANDLECOLLISIONS to a specific
target table or a group of target tables specified with a standard
wildcard (*).

INTEGRATEDPARAMS(parameter_specification)
(Oracle) Supports an integrated Replicat. Sends a parameter specification
to the database inbound server while Replicat is running in integrated mode.
Only one parameter specification can be sent at a time with this command. You
can send multiple parameter changes, issue multiple SEND REPLICAT commands.

SEND REPLICAT myrep INTEGRATEDPARAMS ( parallelism 4 ) SEND REPLICAT
myrep INTEGRATEDPARAMS ( max_sga_size 250)

To preserve the continuity of processing, the parameter change is made
at a transaction boundary. For a list of supported inbound server
parameters, see the Oracle GoldenGate documentation for your database.

REPORT [HANDLECOLLISIONS [table_spec]]

Generates an interim statistical report to the Extract report file.
The statistics that are displayed depend upon the configuration of the
STATOPTIONS parameter when used with the RESETREPORTSTATS | NORESETREPORTSTATS
option. See “STATOPTIONS”.

HANDLECOLLISIONS
Shows tables for which HANDLECOLLISIONShas been enabled.

table spec
Restricts the output to a specific target table or a group of target
tables specified with a standard wildcard (*).

RESUME

Resumes (makes active) a process that was suspended by an EVENTACTIONS SUSPEND
event. The process resumes normal processing from the point at which it was
suspended.

STATUS

Returns the current location within the trail and information regarding the
current transaction. Fields output are:

* Processing status (per thread, if Replicat is coordinated)

* Position in the trail file (per thread, if Replicat is coordinated)

* Trail sequence number (per thread, if Replicat is coordinated)

* RBA in trail

* Trail name

Possible processing status messages are:

* Delaying– waiting for more data

* Suspended– waiting to be resumed

* Waiting on deferred apply– delaying processing based on the
DEFERAPPLYINTERVAL parameter.

* Processing data– processing data

* Skipping current transaction– START REPLICAT with SKIPTRANSACTION was used.

* Searching for START ATCSN csn– START REPLICAT with ATCSN was used.

* Searching for START AFTERCSN csn– START REPLICAT with AFTERCSN was used.

* Performing transaction timeout recovery– stoping current incomplete
transaction and repositioning to start new one (see the TRANSACTIONTIMEOUT
parameter).

* Waiting for data at logical EOF after transaction timeout recovery–
Waiting to receive remainder of incomplete source transaction after a
TRANSACTIONTIMEOUT termination.

* At EOF (end of file)– no more records to process

Possible thread status messages when THREADS is used or the command is
issued for a specific thread are:

* Waiting for consensus stop point: This indicates that the threads are
attempting to synchronize for a barrier transaction.

* Waiting for Watermark: Indicates that all threads are attempting to
stop at the same transaction boundary in the trail, known as the global
watermark.

* Waiting on all threads to start up: Indicates that the thread is
waiting for all of the threads to start after a successful barrier
transaction or a Replicat startup.

Possible coordinator thread status messages are:

* Waiting for all threads to register: Indicates that the MAP statements
are all being parsed to determine the thread IDs that are specified in them.

* Processing data: Indicates that data is being processed normally.

* Suspended, waiting to be resumed: Indicates that a SEND REPLICAT command
with a SUSPEND request was sent to Replicat.

* At EOF: Indicates that there is no more data in the trail to process.

* Waiting to register MAP statistics: Indicates that Replicat is collecting
processing statistics to send to the report file.

STOP

Stops Replicat gracefully. This command applies to Replicat as a whole and
cannot be used for a specific Replicat thread.

THREADS (threadID threadID] ...] thread_range
thread_range] ...])
Issues the command only for the specified thread or threads of a coordinated
Replicat. You can use this option or you can use groupname with threadID.
Without either of those options, the command applies to all active threads.

threadID threadID] ...]
Specifies a thread ID or a comma-delimited list of threads in the
format of threadID, threadID, threadID.

thread_range thread_range] ...]
Specifies a range of threads in the form of threadIDlow-threadIDhigh
or a comma-delimted list of ranges in the format of threadIDlow-threadIDhigh,
threadIDlow-threadIDhigh.

A combination of these formats is permitted, such as threadID, threadID,
threadIDlow-threadIDhigh.

TRACE[2] [DDLINCLUDE | DDL[ONLY]] file_name
Turns tracing on and off. Tracing captures information to the specified
file to reveal processing bottlenecks. Tracing also can be enabled by
means of the Replicat parameters TRACE and TRACE2.

If the Replicat is in coordinated mode and TRACE is used with a THREADS
list or range, a trace file is created for each currently active thread.
Each file name is appended with its associated thread ID. This method of
identifying trace files by thread ID does not apply when SEND REPLICAT is
issued by groupname with threadID (as in SEND REPLICAT fin003TRACE...) or
when only one thread is specified with THREADS.

Contact Oracle Support for assistance if the trace reveals significant
processing bottlenecks.

TRACE

Captures step-by-step processing information.

TRACE2

Identifies code segments rather than specific steps.

DDLINCLUDE | DDLONLY
(Replicat only) Enables DDL tracing and specifies how DDL tracing
is included in the trace report.

* DDLINCLUDE includes DDL tracing in addition to regular tracing of
transactional data processing.

* DDL[ONLY] excludes the tracing of transactional data processing and
only traces DDL. This option can be abbreviated to DDL.

file_name

file_name specifies the relative or fully qualified name of a file
to which Oracle GoldenGate logs the trace information. If a trace is
already in progress, the existing trace file is closed and the trace
resumes to the file specified with file_name. For example:

SEND REPLICAT group_name TRACE file_name DDLINCLUDE

If no other options will follow the file name, the FILE keyword can be
omitted, for example:

SEND REPLICAT group_name TRACE DDLINCLUDE file_name

TRACE[2] OFF

Turns off tracing.

TRACE OFF file_name

Turns tracing off only for the specified trace file. This option supports
the EVENTACTIONS feature, where there can be multiple trace files due to
multiple EVENTACTIONS statements.

TRACEINIT

Resets tracing statistics back to 0 and then starts accumulating statistics
again. Use this option to track the current behavior of processing, as
opposed to historical.

Examples

Example 1

SEND REPLICAT finance, HANDLECOLLISIONS

Example 2

SEND REPLICAT finance, REPORT HANDLECOLLISIONS fin_*

Example 3

SEND REPLICAT finance, GETLAG

Example 4

SEND REPLICAT finance, INTEGRATEDPARAMS (parallelism 10)

Example 5

The following gets lag for thread 3 of a coordinated Replicat.

SEND REPLICAT fin003, GETLAG

Example 6

The following enables tracing for only thread 1 of a coordinated Replicat.
In this case, because only one thread is being traced, the trace file
will not have a threadID extension. The file name is trace.trc.

SEND REPLICAT fin, TRACE THREADS(1) FILE ./dirrpt/trace.trc

Example 7

The following enables tracing for threads 1,2, and 3 of a coordinated
Replicat. Assuming all threads are active, the tracing produces files
trace001, trace002, and trace003.

SEND REPLICAT fin TRACE THREADS(1-3) FILE ./dirrpt/trace.trc

Example 8

The following enables tracing only for thread 1 of a coordinated Replicat.
Because the command was issued directly for thread 1 without the use of a
THREAD clause, the trace file is named trace(without a thread ID suffix).

SEND REPLICAT fin001 TRACE FILE ./dirrpt/trace.trc

Example 9

The following sends dependency information to a Replicat.

Send Rep2 DEPENDENCYINFO TXNCOUNT 5

Sending DEPENDENCYINFO request to REPLICAT REP2 ...
Scheduler 0:
Transaction groups currently being executed:
Group 0:0.3.31.2374, 0.1.15.1860, 0.6.19.2650
Group 1:0.2.18.2510, 0.6.0.2645, 0.8.22.2487
Group 2:0.9.7.2445, 0.10.6.1896, 0.3.8.2367
Group 3:0.5.4.2362, 0.4.31.1736, 0.10.29.1875
Group 4:0.3.6.2376, 0.6.2.2637, 0.9.8.2414
Group 5:0.6.11.2645, 0.9.10.2451, 0.5.22.2357
Group 6:0.9.20.2452, 0.3.4.2367, 0.6.20.2644
Group 7:0.2.10.2487, 0.8.30.2459, 0.5.5.2360
Group 8:0.2.2.2514, 0.8.4.2477, 0.4.23.1733
Group 9:0.9.26.2454, 0.3.20.2367, 0.2.1.2483
Waiting transactions:
Transaction with XID 0.8.28.2483 is waiting on transaction with XID
0.6.15.2617
Transaction with XID 0.9.16.2453 is waiting on transaction with XID
0.8.28.2483
Transaction with XID 0.7.19.1750 is waiting on transaction with XID
0.3.12.2377
Transaction with XID 0.6.17.2647 is waiting on transaction with XID
0.7.19.1750
Transaction with XID 0.9.18.2446 is waiting on transaction with XID
0.4.14.1732

---------------------------------------------------------------------
START REPLICAT

Use START REPLICAT to start Replicat. To confirm that Replicat has started,
use the INFO REPLICAT or STATUS REPLICAT command.

When starting an integrated Replicat group for an Oracle target database,
START REPLICAT automatically registers Replicat with the target database.

A coordinated Replicat can only be started as a whole. There is no option
to start individual threads. If the prior shutdown of a coordinated Replicat
was not clean, the threads may have stopped at different positions in the
trail file. If this happens, START REPLICAT writes a warning if the parameter
file was changed since the prior run and raises an error if the number of
threads was changed. To resolve these problems and start Replicat again,
see Administering Oracle GoldenGate.

Normal Start Point

Replicat can be started at its normal start point (from initial or current
checkpoints) or from an alternate, user-specified position in the trail.

START REPLICAT, without any options, causes Replicat to start processing
at one of the following points to maintain data integrity:

* After graceful or abnormal termination: At the first unprocessed transaction
in the trail from the previous run, as represented by the current read
checkpoint.

* First-time startup after the group was created: From the beginning of
the active trail file (seqno 0, rba 0). See Administering Oracle GoldenGate
for more information about checkpoints.

Alternate Start Point

The SKIPTRANSACTION, ATCSN, and AFTERCSN options of START REPLICAT cause
Replicat as a whole, or specific threads of a coordinated Replicat, to
begin processing at a transaction in the trail other than the normal start
point. Use these options to:

* Specify a logical recovery position when an error prevents Replicat from
moving forward in the trail. Replicat can be positioned to skip the
offending transaction or transactions, with the understanding that the
data will not be applied to the target.

* Skip replicated transactions that will cause duplicate-record and missing-record
errors after a backup is applied to the target during an initial load. These
options cause Replicat to discard transactions that occurred earlier than the
most recent set of changes that were captured in the backup. You can map the
value of the serial identifier that corresponds to the completion of the backup
to a CSN value, and then start Replicat to begin applying transactions from
the specified CSN onward.

Note:
Skipping a transaction, or starting at or after a CSN, might cause Replicat to
start more slowly than normal, depending on how much data in the trail must be
read before arriving at the appropriate transaction record. To view the startup
progress, use the SEND REPLICAT command with the STATUS option. To omit the need
for Replicat to read through transactions that ultimately will be skipped, you
can use the ATCSN or AFTERCSN option when starting Extract and the data pumps,
so that those transactions are omitted from the trail. See “START EXTRACT”. See
Administering Oracle GoldenGate for more information about performing an initial
load.

Syntax

START REPLICAT group_name
[SKIPTRANSACTION | {ATCSN csn | AFTERCSN csn}]
[FILTERDUPTRANSACTIONS | NOFILTERDUPTRANSACTIONS]
[THREADS (threadID threadID] ...] thread_range thread_range] ...])

group_name

The name of a Replicat group or a wildcard (*) to specify multiple groups. For
example, T* starts all Replicat groups whose names begin with T.

SKIPTRANSACTION

Causes Replicat to skip the first transaction after its expected startup
position in the trail. All operations from that first transaction are excluded.

If the MAXTRANSOPS parameter is also being used for this Replicat, it is possible
that the process will start to read the trail file from somewhere in the middle
of a transaction. In that case, the remainder of the partial transaction is skipped
and Replicat resumes normal processing from the next begin-transaction record
in the file. The skipped records are written to the discard file if the DISCARDFILE
parameter is being used; otherwise, a message is written to the report file that
is similar to:

User requested START SKIPTRANSACTION. The current transaction will be skipped.
Transaction ID txid, position Seqno seqno, RBA rba

SKIPTRANSACTION is valid only when the trail that Replicat is reading is part of
an online change synchronization configuration (with checkpoints). Not valid
for task-type initial loads (where SPECIALRUN is used with ADD REPLICAT).

ATCSN csn| AFTERCSNcsn
Sets a user-defined start point at a specific CSN. When ATCSN or AFTERCSN is
used, a message similar to one of the following is written to the report file:

User requested start at commit sequence number (CSN) csn-string

User requested start after commit sequence number (CSN) csn-string

General information about these options:

* Valid only when the trail that Replicat is reading is part of an online change
synchronization configuration (with checkpoints). Not valid for task-type initial
loads (where SPECIALRUN is used with ADD REPLICAT).

* To support starting at, or after, a CSN, the trail must be of Oracle GoldenGate
version 10.0.0 or later, because the CSN is stored in the first trail record of
each transaction. If Replicat is started with AFTERCSN against an earlier trail
version, Replicat will abend and write an error to the report stating that the
trail format is not supported.

ATCSN

Causes Replicat to start processing at the transaction that has the specified
CSN. Any transactions in the trail that have CSN values that are less than
the specified one are skipped.

AFTERCSN

Causes Replicat to start processing at the transaction that occurred after
the one with the specified CSN. Any transactions in the trail that have CSN
values that are less than, or equal to, the specified one are skipped.

csn

Specifies a CSN value. Enter the CSN value in the format that is valid for
the database. See Administering Oracle GoldenGate CSN formats and descriptions.
Replicat abends if the format is invalid and writes a message to the report file.
To determine the CSN to supply after an initial load is complete, use the commit
identifier at which the load utility completed the load. Otherwise, follow the
instructions in the initial load procedure for determining when to start Replicat.

FILTERDUPTRANSACTIONS | NOFILTERDUPTRANSACTIONS

Causes Replicat to ignore transactions that it has already processed. Use when
Extract was repositioned to a new start point (see the ATCSN or AFTERCSN option of
“START EXTRACT”) and you are confident that there are duplicate transactions
in the trail that could cause Replicat to abend. This option requires the use
of a checkpoint table. For Oracle Database, this option is valid only
for Replicat in nonintegrated mode. For Integrated mode and automatic
target trail file regeneration, the Integrated mode handles the duplicate
transactions transparently. The default is FILTERDUPTRANSACTIONS.

THREADS (threadID threadID] ...] thread_range
thread_range] ...])
Valid for SKIPTRANSACTION, ATCSN, and AFTERCSN when Replicat is in coordinated
mode. Not valid for START REPLICAT without those options. Starts the specified
Replicat thread or threads at the specified location.

threadID threadID] ...]

Specifies a thread ID or a comma-delimited list of threads in the format
of threadID, threadID, threadID.

thread_range thread_range] ...]

Specifies a range of threads in the form of threadIDlow-threadIDhigh or
a comma-delimted list of ranges in the format of threadIDlowthreadIDhigh,
threadIDlow-threadIDhigh.

A combination of these formats is permitted, such as threadID, threadID,
threadIDlow-threadIDhigh.

Examples

Example 1

START REPLICAT finance

Example 2

The following starts Replicat at an Oracle-specific CSN.

START REPLICAT finance, ATCSN 6488359

Example 3

The following starts Replicat at a SQL Server-specific CSN after the one
with the specified CSN.

START REPLICAT finance, AFTERCSN 0X000004D2:0000162E:0009

Example 4

The following causes threads 4 and 5 of a coordinated Replicat to skip
the first transaction after their last checkpoint when Replicat is started.
If this were a 10-thread coordinated Replicat, threads 0-3 and 6-10 would
all start at the normal start point, that of their last checkpoint.

START REPLICAT fin SKIPTRANSACTION THREADS(4-5)

Example 5

The following example causes threads 1-3 of a coordinated Replicat to
start at CSN 6488359, threads 9-10 to start after CSN 6488360, and threads
7 and 8 to skip the first transaction after its last checkpoint.

START REPLICAT fin ATCSN 6488359 THREADS(1-3), AFTERCSN 6488360
THREADS(9-10), SKIPTRANSACTION THREADS(7,8)

---------------------------------------------------------------------
STATS REPLICAT

Use STATS REPLICAT to display statistics for one or more Replicat groups.
Thread statistics for a coordinated Replicat group are provided as follows.

Thread Lag Gap
The difference between the maximum lag and the minimum lag among all threads.

Coordinated Total DDLs
The total number of coordinated DDL transactions.

Coordinated Total PK-Update Transactions
The total number of coordinated transactions that involved an update to a
primary key.

Coordinated Total EMI Transactions
The total number of coordinated EVENTACTIONS events.

Total Transactions with User-requested Coordination
The total number of coordinations that were explicitly requested in the
configuration by means of the COORDINATED option of the MAP parameter.

Average Coordination Time
The average time (in seconds) spent in coordination among all threads.

Syntax

STATS REPLICAT group_name
[statistic]
[TABLE [container. | catalog.]schema.table]
[TOTALSONLY [container. | catalog.]schema.table]
[REPORTCDR]
[REPORTCHARCONV]
[REPORTDETAIL | NOREPORTDETAIL] REPORTRATE {HR | MIN | SEC}]
... ]

group_name

The name of a Replicat group or a wildcard (*) to specify multiple groups.
For example, T* shows statistics for all Replicat groups whose names begin with T.

statistic

The statistic to be displayed. More than one statistic can be specified
by separating each with a comma, for example STATS REPLICAT finance, TOTAL, DAILY.

Valid values are:

TOTAL
Displays totals since process startup.

DAILY
Displays totals since the start of the current day.

HOURLY
Displays totals since the start of the current hour.

LATEST
Displays totals since the last RESET command.

RESET
Resets the counters in the LATEST statistical field.

TABLE [container. | catalog.]schema.table]

TOTALSONLY [container. | catalog.]schema.table]

REPORTCDR

Shows statistics for Conflict Detection and Resolution. Statistics include:

* Total CDR conflicts

* CDR resolutions succeeded

* CDR resolutions failed

* CDR INSERTROWEXISTS conflicts

* CDR UPDATEROWEXISTS conflicts

* CDR UPDATEROWMISSING conflicts

* CDR DELETEROWEXISTS conflicts

* CDR DELETEROWMISSING conflicts

REPORTCHARCONV

Reports statistics for character validation when character-set conversion
is performed. The following statistics are added to the STATS output:

Total column character set conversion failure: the number of validation
or conversion failures in the current Replicat run.

Total column data truncation: the number of times that column data was
truncated in the current Replicat run as the result of character set conversion.

REPORTDETAIL | NOREPORTDETAIL

Controls whether or not the output includes operations that were not replicated
as the result of collision errors. These operations are reported in the
regular statistics (inserts, updates, and deletes performed) plus as
statistics in the detail display, if enabled. For example, if 10 records
were insert operations and they were all ignored due to duplicate keys, the
report would indicate that there were 10 inserts and also 10 discards due to
collisions. The default is REPORTDETAIL. See “STATOPTIONS”.

REPORTRATE {HR | MIN | SEC}

Displays statistics in terms of processing rate rather than absolute values.

HR
Sets the processing rate in terms of hours.

MIN
Sets the processing rate in terms of minutes.

SEC
Sets the processing rate in terms of seconds.

Examples

Example 1

The following example displays total and hourly statistics per minute for a specific
table, and it also resets the latest statistics. Statistics for discarded operations
are not reported.

STATS REPLICAT finance, TOTAL, HOURLY, TABLE sales.acct, REPORTRATE MIN, RESET,
NOREPORTDETAIL

Example 2

The following example displays the same statistics as the previous example, but
for thread 3 of a coordinated Replicat group.

STATS REPLICAT fin003, TOTAL, HOURLY, TABLE sales.acct, REPORTRATE MIN, RESET,
NOREPORTDETAIL

---------------------------------------------------------------------
STATUS REPLICAT

Use STATUS REPLICAT to determine whether or not Replicat is running. There are
the following four possible statuses:

Abended

The process has abnormally ended.

Running

Means one of the following:

* Active: Running and processing (or able to process) data. This is the normal
state of a process after it is started.

* Suspended: The process is running though suspended due to an EVENTACTIONS SUSPEND
action. In a suspended state, the process is not active, and no data can be
processed, but the state of the current run is preserved and can be continued
by issuing the RESUME command in GGSCI. The RBA in the INFO command reflects the
last checkpointed position before the suspend action. To determine whether the
state is active or suspended, issue a SEND EXTRACT|REPLICAT group_name STATUS
command. For more information, see SEND EXTRACT or SEND REPLICAT.

Starting

The process is starting.

Stopped

The process was stopped.

Syntax

STATUS REPLICAT group_name
[TASKS]
[ALLPROCESSES]

group_name

The name of a Replicat group or a wildcard (*) to specify multiple
groups. For example, T* shows status for all Replicat groups whose names
begin with T.

TASKS

Displays status only for Replicat tasks. By default, tasks are not displayed
unless you specify a single Replicat group (without wildcards).

ALLPROCESSES

Displays status for all Replicat groups, including tasks.

Examples

Example 1

STATUS REPLICAT finance

Example 2

STATUS REPLICAT fin*
---------------------------------------------------------------------
STOP REPLICAT

Use STOP REPLICAT to stop Replicat cleanly. This command preserves the state
of synchronization for the next time Replicat starts, and it ensures that
Manager does not automatically start Replicat.

In a clean shutdown of a coordinated Replicat, the coordinator thread attempts
to stop all of the threads on the same transaction boundary. If the shutdown
of a coordinated Replicat is not clean, the threads may stop at different
positions in the trail file. If this happens, START REPLICAT writes a warning
if the parameter file was changed since the prior run and raises an error if
the number of threads was changed. To resolve these problems and start Replicat
again, see Administering Oracle GoldenGate.

Syntax

STOP REPLICAT group_name [!]

group_name

The name of a Replicat group or a wildcard (*) to specify multiple groups.
For example, T* stops all Replicat groups whose names begin with T.

!
(Exclamation point) Stops Replicat immediately. The transaction is stoped
and the process terminates.

Example

STOP REPLICAT finance

---------------------------------------------------------------------
SYNCHRONIZE REPLICAT

Use SYNCHRONIZE REPLICAT to return all of the threads of a coordinated Replicat
to the same position in the trail file after an unclean shutdown. This position
is the maximum checkpoint position of all of the threads, in other words, the
most recent trail record processed among all of the threads. When SYNCHRONIZE
REPLICAT is issued, all threads are started and allowed to process transactions
until they reach the maximum checkpoint position, and then Replicat stops.

For more information about how to use SYNCHRONIZE REPLICAT to recover a
coordinated Replicat after an unclean shutdown, or to enable repartitioning
of data among different threads, see Administering Oracle GoldenGate.

Syntax

SYNCHRONIZE REPLICAT group_name

group_name

The name of a Replicat group or a wildcard (*) to specify multiple groups.
For example, T* synchronizes the threads of all Replicat groups whose names
begin with T. The threads synchronize to the same position within their group,
not to the same position across all Replicat groups being synchronized with
this command.

Example

SYNCHRONIZE REPLICAT repA

---------------------------------------------------------------------
UNREGISTER REPLICAT

Use the UNREGISTER REPLICAT command to unregister a Replicat group from a
target Oracle Database to disable integrated Replicat mode. Use this
command only if you forcibly deleted the Replicat group. UNREGISTER REPLICAT
should not be used when deleting Replicat in the normal manner, where you
first stop Replicat and then issue the DELETE REPLICAT command.

Before issuing this command, issue the DBLOGIN command as the Replicat
database user with privileges granted through
dbms_goldengate_auth.grant_admin_privilege.

For more information about integrated Replicat, see the Oracle GoldenGate documentation
for your database.

Syntax

UNREGISTER REPLICAT group_name DATABASE

group_name

The name of a Replicat group or a wildcard (*) to specify multiple groups.
For example, T* unregisters all Replicat groups whose names begin with T.

DATABASE

Required keyword to unregister from the target database. Removes the database
inbound server that is associated with this Replicat.

Example

UNREGISTER REPLICAT sales DATABASE

--------------------------------------------------------------------
SET_INSTANTIATION_CSN

SET_INSTANTIATION_CSN

Use SET_INSTANTIATION_CSN on your target database to set the instantiation CSN
manually. This command requires DBLOGIN. It enables a Replicat with the DBOPTIONS
ENABLE_INSTANTIATION_FILTERING option to filter out records below the specified
CSN for any object without Oracle Datapump import instantiation information.
It is an alternative to specifying @FILTER (@GETENV('TRANSACTION','CSN').

To enable instantiation SCN filtering, you must do the following:

1. Your Replicat parameter file must contain DBOPTIONS ENABLE_INSTANTIATION_FILTERING.

2. The instantiation SCNs must be set at the target database for each table. You
can do this using one of the following two methods:
Automatically set the source SCN by the Oracle Datapump upon import if the
tables were prepared at the source database using ADD TRANDATA PREPARECSN or
ADD SCHEMATRANDATA PREPARECSN prior to the Oracle Datapump export.
or Manually set the instantiation source SCN at the target database using this
command.

Syntax

SET_INSTANTIATION_CSN csn FOR [schema.] table FROM source_database_name

csn

The CSN number that instantiation will begin.

[schema.]table

The name of the table to set the instantiation CSN on. If no schema is provided,
the DBLOGIN user will be used.

source_database_name

The global name of the source database for which this is a target.

Example

SET_INSTANTIATION_CSN 12345678 FOR hr.employees FROM DBS1.US.COMPANY.COM

--------------------------------------------------------------------
CLEAR_INSTANTIATION_CSN

CLEAR_INSTANTIATION_CSN

Use CLEAR_INSTANTIATION_CSN on your target database to clear (reverse) the
instantiation CSN manually. This command requires DBLOGIN where the user is
the default Oracle GoldenGate schema.

Syntax

CLEAR_INSTANTIATION_CSN FOR [schema.]table FROM source_database_name

[schema.]table

The name of the table to clear the instantiation CSN on. If no schema is
provided, the DBLOGIN user will be used.

source_database_name

The global name of the source database for which this is a target.

Example

CLEAR_INSTANTIATION_CSN FOR hr.employees FROM DBS1.US.COMPANY.COM

---------------------------------------------------------------------
####################################
#
#ER COMMANDS
#
#
####################################
---------------------------------------------------------------------
INFO ER

INFO ER

Use the INFO ER command to get information on multiple Extract and
Replicat groups as a unit. Use it with wildcards to affect every
Extract and Replicat group that satisfies the wildcard. For
descriptions and optional parameters for this command, refer to the
INFO EXTRACT or INFO REPLICAT command.

Syntax:

INFO ER group wildcard specification

group wildcard specification

The wildcard specification for the groups that you want to affect with
the command. Oracle GoldenGate will automatically increase internal
storage to track up to 100,000 wildcard entries.

Example:

INFO ER *X*

---------------------------------------------------------------------
KILL ER

KILL ER

Use the KILL ER command to forcefully terminate multiple Extract and
Replicat groups as a unit. Use it with wildcards to affect every
Extract and Replicat group that satisfies the wildcard. For
descriptions and optional parameters for this command, refer to the
KILL EXTRACT or KILL REPLICAT command.

Syntax:

KILL ER group wildcard specification

group wildcard specification

The wildcard specification for the groups that you want to affect with
the command. Oracle GoldenGate will automatically increase internal
storage to track up to 100,000 wildcard entries.

Example:

KILL ER *X*

---------------------------------------------------------------------
LAG ER

LAG ER

Use the LAG ER command to get lag information on multiple Extract and
Replicat groups as a unit. Use it with wildcards to affect every
Extract and Replicat group that satisfies the wildcard. For
descriptions and optional parameters for this command, refer to the
LAG EXTRACT or LAG REPLICAT command.

Syntax:

LAG ER group wildcard specification

group wildcard specification

The wildcard specification for the groups that you want to affect with
the command. Oracle GoldenGate will automatically increase internal
storage to track up to 100,000 wildcard entries.

Example:

LAG ER *X*

---------------------------------------------------------------------
SEND ER

SEND ER

Use the SEND ER command to send instructions to multiple Extract and
Replicat groups as a unit. Use it with wildcards to affect every
Extract and Replicat group that satisfies the wildcard. For
descriptions and optional parameters for this command, refer to the
SEND EXTRACT or SEND REPLICAT command.

Syntax:

SEND ER group wildcard specification

group wildcard specification

The wildcard specification for the groups that you want to affect with
the command. Oracle GoldenGate will automatically increase internal
storage to track up to 100,000 wildcard entries.

Example:

SEND ER *X*

---------------------------------------------------------------------
START ER

START ER

Use the START ER command to start multiple Extract and
Replicat groups as a unit. Use it with wildcards to affect every
Extract and Replicat group that satisfies the wildcard. For
descriptions and optional parameters for this command, refer to the
START EXTRACT or START REPLICAT command.

Syntax:

START ER group wildcard specification

group wildcard specification

The wildcard specification for the groups that you want to affect with
the command. Oracle GoldenGate will automatically increase internal
storage to track up to 100,000 wildcard entries.

Example:

START ER *X*

---------------------------------------------------------------------
STATS ER

STATS ER

Use the STATS ER command to get statistics on multiple Extract and
Replicat groups as a unit. Use it with wildcards to affect every
Extract and Replicat group that satisfies the wildcard. For
descriptions and optional parameters for this command, refer to the
STATS EXTRACT or STATS REPLICAT command.

Syntax:

STATS ER group wildcard specification

group wildcard specification

The wildcard specification for the groups that you want to affect with
the command. Oracle GoldenGate will automatically increase internal
storage to track up to 100,000 wildcard entries.

Example:

STATS ER *X*

---------------------------------------------------------------------
STATUS ER

STATUS ER

Use the STATUS ER command to check the status of multiple Extract and
Replicat groups as a unit. Use it with wildcards to affect every
Extract and Replicat group that satisfies the wildcard. For
descriptions and optional parameters for this command, refer to the
STATUS EXTRACT or STATUS REPLICAT command.

Syntax:

STATUS ER group wildcard specification

group wildcard specification

The wildcard specification for the groups that you want to affect with
the command. Oracle GoldenGate will automatically increase internal
storage to track up to 100,000 wildcard entries.

Example:

STATUS ER *X*

---------------------------------------------------------------------
STOP ER

STOP ER

Use the STOP ER command to stop multiple Extract and
Replicat groups as a unit. Use it with wildcards to affect every
Extract and Replicat group that satisfies the wildcard. For
descriptions and optional parameters for this command, refer to the
STOP EXTRACT or STOP REPLICAT command.

Syntax:

STOP ER group wildcard specification

group wildcard specification>

The wildcard specification for the groups that you want to affect with
the command. Oracle GoldenGate will automatically increase internal
storage to track up to 100,000 wildcard entries.

Example:

STOP ER *X*

---------------------------------------------------------------------

####################################
#
#WALLET COMMANDS
#
#
####################################
---------------------------------------------------------------------
CREATE WALLET

Use the CREATE WALLET command to create a master-key wallet. This wallet
stores the master key that is used by Oracle GoldenGate processes to
encrypt the encryption keys that secure data over the network and in trail
files and other Oracle GoldenGate files that store sensitive data.

This command creates an empty wallet that remains open for the duration
of the GGSCI session. The GGSCI console returns messages similar to the
following, indicating that the wallet is present and open.

Created wallet at location './dirwlt'.

Opened wallet at location './dirwlt'.

The wallet is created as an autologinwallet (file extension .sso) to support
automated restarts of Oracle GoldenGate processes without requiring human
intervention to supply the necessary decryption passwords. The wallet file
is created in the directory specified by the GLOBAL parameter WALLETLOCATION,
if present, or otherwise in the default location of dirwltin the Oracle
GoldenGate installation directory.

The wallet is in a platform-independent format. It must either be stored on
a shared file system that is accessible by all systems in the Oracle GoldenGate
environment, or it must be copied to all of those systems initially and every
time the master key changes.

The wallet is permanent within Oracle GoldenGate, but can be manually deleted
with the appropriate command in the operating system, if that becomes necessary.

The use of a wallet and master key is not supported for the iSeries, z/OS,
and NonStop platforms.

See “ADD MASTERKEY”to add a master key value to the wallet.

Syntax

CREATE WALLET

---------------------------------------------------------------------
OPEN WALLET

Use the OPEN WALLET command to open a master-key wallet. Opening a wallet
decrypts the contents and loads them into the GGSCI memory. This command
must be used before using any of the commands that add, renew, or delete
the master keys in the wallet.

The wallet remains open for the rest of the GGSCI session. The name of
the wallet to be opened is taken from the GLOBALS parameter WALLETLOCATION,
if present, or otherwise it is opened from the default location in the
Oracle GoldenGate installation directory.

The use of a wallet and master key is not supported for the iSeries,
z/OS, and NonStop platforms.

Syntax

OPEN WALLET

---------------------------------------------------------------------
PURGE WALLET

Use the PURGE WALLET command to permanently remove master key versions
from the master-key wallet. Only the versions that are marked for deletion
by the DELETE MASTERKEY command are removed. The purge is not reversible.

Note:
For Oracle GoldenGate deployments using a shared wallet, the older versions
of the master key should be retained after the master key is renewed until
all processes are using the newest version. The time to wait depends on the
topology, latency, and data load of the deployment. A minimum wait of 24
hours is a conservative estimate, but you may need to perform testing to
determine how long it takes for all processes to start using a new key.To
determine whether all of the processes are using the newest version,
view the report file of each Extract immediately after renewing the master
key to confirm the last SCN that was mined with the old key. Then, monitor
the Replicat report files to verify that this SCN was applied by all
Replicat groups. At this point, you can delete the older versions of
the master key.

The OPEN WALLET command must be used before using this command or any of
the commands that add, renew, or delete the master keys in the wallet.

After purging a wallet that is not maintained centrally on shared storage,
the updated wallet can be copied to all of the other systems in the Oracle
GoldenGate configuration that use this wallet, so that no purged keys
remain in the configuration. Before doing so, Extract must be stopped and
then all of the downstream Oracle GoldenGate processes must be allowed to
finish processing their trails and then be stopped. After the wallet is
copied into place, the processes can be started again. For detailed
instructions, see Administering Oracle GoldenGate.

The use of a wallet and master key is not supported for the iSeries,
z/OS, and NonStop platforms.

Syntax
PURGE WALLET

---------------------------------------------------------------------
####################################
#
#MASTERKEY COMMANDS
#
#
####################################
---------------------------------------------------------------------
ADD MASTERKEY

Use the ADD MASTERKEY command to add a master key to a master-key wallet.
The master key is used by Extract and Replicat to encrypt the encryption
keys that secure data being sent across the network and in the trail files,
so that those keys can be sent to, and used, by downstream processes. The
master key omits the need to use wallet storage for the keys that actually
encrypt the data.

The master-key wallet must be open to add a key. Use the CREATE WALLET
or OPEN WALLET command to open a wallet. The wallet remains open throughout
the same GGSCI session in which the command was issued.

The master key is generated as a random sequence of bits.

The successful completion of this command returns a message similar to
the following:
Created version 1 of master key 'OGG_DEFAULT_MASTERKEY' in Oracle Wallet
'dirwlt/cwallet.sso

After adding a master key to a wallet that is not maintained centrally on
shared storage, the updated wallet must be copied to all of the other
systems in the Oracle GoldenGate configuration that use this wallet.
Before doing so, Extract must be stopped and then all of the downstream
Oracle GoldenGate processes must be allowed to finish processing their
trails and then be stopped. After the wallet is copied into place, the
processes can be started again. For detailed instructions, see Administering
Oracle GoldenGate.

The use of a wallet and master key is not supported for the iSeries,
z/OS, and NonStop platforms.

Syntax

ADD MASTERKEY

Example

ADD MASTERKEY

---------------------------------------------------------------------
INFO MASTERKEY

Use the INFO MASTERKEY command to view the contents of the master-key wallet.
The default output shows the version history of the master key, with the
creation date of a version and the status of the version. The status can be
one of the following:

* Current: Indicates this is the active version of the master key.

* Available: Indicates this version is not the current one, but can be
made active if needed.

* Deleted: Indicates that this version is marked to be deleted when the
PURGE WALLET command is issued.

The use of a wallet and master key is not supported for the iSeries,
z/OS, and NonStop platforms.

Syntax

INFO MASTERKEY [VERSION version]

VERSION version

Shows detailed information about a specific version of the master key.
The output includes the original creation date, the latest renewal date,
the status, and the hash of AES (Advanced Encryption Standard) Key.

Examples

Example 1

The following example shows the default input without any options.

INFO MASTERKEY

Masterkey Name: OGG_DEFAULT_MASTERKEY
Creation Date: Mon Aug 27 10:00:40 2017
Version: Creation Date: Status:
1 Mon Aug 27 10:00:40 2017 Deleted
2 Mon Aug 27 10:00:46 2017 Available
3 Mon Aug 27 10:02:58 2017 Deleted
4 Mon Aug 27 10:03:02 2017 Deleted
5 Mon Aug 27 10:03:05 2017 Deleted
6 Mon Aug 27 10:03:09 2017 Available
7 Mon Aug 27 10:03:16 2017 Current

Example 2

The following example shows the results of INFO MASTERKEY with VERSION.
The status of Current in the output shows that version 7 is the active version.

INFO MASTERKEY VERSION 7

Masterkey Name: OGG_DEFAULT_MASTERKEY
Creation Date: Mon Aug 27 10:00:40 2017
Version: 7
Renew Date: Mon Aug 27 10:03:16 2017
Status: Current
Key Hash (SHA1): 0xC65ADFA1CF42F9DB2CED3BC39A53F661CDED3304

---------------------------------------------------------------------
RENEW MASTERKEY

Use the RENEW MASTERKEY command to create a new version of the master
encryption key in the master-key wallet. The key name remains the same,
but the bit ordering is different. All versions of a master key remain
in the wallet until they are marked for deletion with the DELETE MASTERKEY
command and then the wallet is purged with the PURGE WALLET command.

The OPEN WALLET command must be used before using this command or any of the
commands that add or delete the master keys or purge the wallet.

A message similar to the following indicates that the command succeeded.

Masterkey 'OGG_DEFAULT_MASTERKEY' renewed to version 2 in wallet at location
'./ dirwlt'.

After renewing a master key in a wallet that is not maintained centrally on
shared storage, the updated wallet must be copied to all of the other systems
in the Oracle GoldenGate configuration that use this wallet. Before doing so,
Extract must be stopped and then all of the downstream Oracle GoldenGate
processes must be allowed to finish processing their trails and then be
stopped. After the wallet is copied into place, the processes can be started
again. For detailed instructions, see Administering Oracle GoldenGate.

The use of a wallet and master key is not supported for the iSeries, z/OS, and
NonStop platforms.

Syntax

RENEW MASTERKEY

Example

This example creates a new version of the master key.

RENEW MASTERKEY

--------------------------------------------------------------------
DELETE MASTERKEY

DELETE MASTERKEY

Use the DELETE MASTERKEY command to mark a version of a master key for
deletion. Routinely deleting older versions of a master key ensures
that they cannot be used maliciously.

The OPEN WALLET command must be used before using this command or any
of the commands that add or renew the master keys or purge the wallet.

To view the version of a master key, use the INFO MASTERKEY command.

This command marks a version for deletion but does not physically remove
it from the wallet. See “PURGE WALLET” to remove the master key version
permanently.

Note:
For Oracle GoldenGate deployments using a shared wallet, the older
versions of the master key should be retained after the master key
is renewed until all processes are using the newest version. The
time to wait depends on the topology, latency, and data load of
the deployment. A minimum wait of 24 hours is a conservative estimate,
but you may need to perform testing to determine how long it takes
for all processes to start using a new key. To determine whether all of
the processes are using the newest version, view the report file of
each Extract immediately after renewing the master key to confirm
the last SCN that was mined with the old key. Then, monitor the
Replicat report files to verify that this SCN was applied by all
Replicat groups. At this point, you can delete the older versions of the
master key.

See “UNDELETE MASTERKEY” to reverse a deletion made by DELETE MASTERKEY.

Once a version number is used, the wallet reserves it forever, and no
other key of the same version can be generated. For example, you cannot
mark version 2 of a key for deletion, then purge the wallet to remove it,
and then issue RENEW MASTERKEY to add a version 2 again. Even though only
version 1 of the key remains in the wallet after the purge, the renewal
generates version 3, not version 2.

The use of a wallet and master key is not supported for the iSeries,
z/OS, and NonStop platforms.

Syntax

DELETE MASTERKEY
{VERSION version | RANGE FROM begin_value TO end_value | ALL}

VERSION version

Specifies a single version to be marked for deletion.

RANGE FROM begin_value TO end_value

Specifies a range of versions to be marked for deletion. The versions
must be contiguous. For example, specifying RANGE FROM 3 TO 6 marks
versions 3, 4, 5, and 6.

ALL

Marks all versions of the master key for deletion, including the currently
active one. When this option is used, it should always be followed by a
RENEW MASTERKEY command to create a new, current version of the master key.

Examples

Example 1

This command marks one version of the master key for deletion and returns a
message similar to the one shown.

DELETE MASTERKEY VERSION 10

Version 10 of Masterkey 'OGG_DEFAULT_MASTERKEY' deleted from wallet at
location './
dirwlt'.

Example 2

This command marks versions 3, 4, 5, and 6 for deletion and returns a
message similar to the one shown.

DELETE MASTERKEY RANGE FROM 3 TO 6

Version 3 of Masterkey 'OGG_DEFAULT_MASTERKEY' deleted from wallet
at location './ dirwlt'.
Version 4 of Masterkey 'OGG_DEFAULT_MASTERKEY' deleted from wallet
at location './ dirwlt'.
Version 5 of Masterkey 'OGG_DEFAULT_MASTERKEY' deleted from wallet
at location './ dirwlt'.
Version 6 of Masterkey 'OGG_DEFAULT_MASTERKEY' deleted from wallet
at location './ dirwlt'.

---------------------------------------------------------------------
UNDELETE MASTERKEY

Use the UNDELETE MASTERKEY command to remove the deletion mark from a
master key version, thus retaining that version if the PURGE WALLET
command is used. Only one version can be unmarked per UNDELETE MASTERKEY
command. See “DELETE MASTERKEY” to mark a version of a master key for
deletion.

The OPEN WALLET command must be used before using this command or any
of the commands that add, renew, or delete the master keys in the wallet.

The use of a wallet and master key is not supported for the iSeries,
z/OS, and NonStop platforms.

Syntax

UNDELETE MASTERKEY VERSION version

VERSION version

The version that is to be unmarked for deletion.

Example

This command unmarks version 3 of the master key and returns a message
similar to the one shown.

UNDELETE MASTERKEY VERSION 3
Version 3 of Masterkey 'OGG_DEFAULT_MASTERKEY' undeleted from wallet
at location './ dirwlt'.

---------------------------------------------------------------------
####################################
#
#CREDENTIALSTORE COMMANDS
#
#
####################################
---------------------------------------------------------------------
ADD CREDENTIALSTORE

Use the ADD CREDENTIALSTORE command to create a credential store. The
credential store manages user IDs and their encrypted passwords (together
known as credentials) that are used by Oracle GoldenGate processes to
interact with the local database. The credential store eliminates the
need to specify user names and clear-text passwords in the Oracle GoldenGate
parameter files. An optional alias can be used in the parameter file
instead of the user ID to map to a userid-password pair in the credential
store.

The credential store is implemented as an autologin wallet within the
Oracle Credential Store Framework (CSF). The use of an LDAP directory
is not supported for the Oracle GoldenGate credential store. The autologin
wallet supports automated restarts of Oracle GoldenGate processes without
requiring human intervention to supply the necessary passwords.

ADD CREDENTIALSTORE creates an empty credentials store in the location that
is specified with the CREDENTIALSTORELOCATION parameter in the GLOBALS file,
if used, or otherwise in the default location of dircrdin the Oracle
GoldenGate installation directory. A credential store can be shared
by multiple instances (installations) of Oracle GoldenGate on the same
or different systems. Store a shared credential store in a shared file
system, and specify this location in each Oracle GoldenGate instance by
using the CREDENTIALSTORELOCATION parameter in each GLOBALS parameter file.

Only one credential store can be used at a time by any given instance of
Oracle GoldenGate. For example, you can have a credential store named
/home/ogg/ credentialsand a credential store named /test/ogg/credentials,
but only one can be used at runtime by a given instance of Oracle GoldenGate.
You can stop the processes to switch to a different credential store, but
make certain to update the CREDENTIALSTORELOCATION parameter in each GLOBALS
parameter file, and change the USERIDALIAS parameters to specify different
aliases if needed.

The use of a credential store is not supported for the iSeries,
z/OS, and NonStop platforms.

For more information about Oracle GoldenGate security options, see
Administering Oracle GoldenGate.

Syntax

ADD CREDENTIALSTORE

---------------------------------------------------------------------
ALTER CREDENTIALSTORE

Use the ALTER CREDENTIALSTORE command to manage user ID and password pairs
in the credential store. This command enables you to add credentials to the
credential store and to specify different aliases for a user. Upon successful
completion, the command returns a message similar to the following:

Credential store altered.

The use of a credential store is not supported for the DBE for i, DB2 z/OS, and
NonStop platforms.

For more information about Oracle GoldenGate security options, see
Administering Oracle GoldenGate.

Syntax

ALTER CREDENTIALSTORE {
ADD USER userid |
REPLACE USER userid |
DELETE USER userid }
[PASSWORD password]
[ALIAS alias]
[DOMAIN domain]

ADD USER userid

Adds the specified user and its alias to the credential store. If the ALIAS
option is not used, the alias defaults to the user name. A credential can
only be entered once unless the ALIAS option is used to specify a different
alias for each one. Unless the PASSWORD option is used, the command prompts
for the password of the specified user. The user can be an actual user name
or a SQL*Net connect string.

REPLACE USER userid

Changes the password of the specified user. If the ALIAS option is not used,
the alias defaults to the user name. You cannot change the alias or domain of
a user with this option, but you can use the ADD USER option to add a new entry
for the user under the desired ALIAS or DOMAIN. Unless the PASSWORD option is
used, the command prompts for the new password for the specified user.

DELETE USER userid

Removes the credential for the specified user from the credential store. If
the ALIAS option is not used, the alias defaults to the user name.

PASSWORD password

The user's password. The password is echoed (not obfuscated) when this
option is used. If this option is omitted, the command prompts for the
password, which is obfuscated as it is typed (recommended as more secure).

ALTER CREDENTIALSTORE ADD USER scott
Password: ********

ALIAS alias

Specifies an alias for the user name. Use this option if you do not want
the user name to be in a parameter file or command. If ALIAS is not used,
the alias defaults to the USER name, which then must be used in parameter
files and commands where a login is required. You can create multiple
entries for a user, each with a different alias, by using the ADD USER option
with ALIAS.

DOMAIN domain

Saves the credential user under the specified domain name. Enables the same
alias to be used by multiple Oracle GoldenGate installations that use the
same credential store. The default domain is Oracle GoldenGate. For example,
the administrators of system 1 might not want system 2 to have access to the
same credentials that are used on system 1. Those credentials can be stored
as ALIAS extract, for example, under DOMAIN system1, while a different set
of credentials can be stored for ALIAS extractunder DOMAIN system2.

Examples

Example 1

This example adds a user named scott but omits the PASSWORD specification,
so the command prompts for Scott's password.

ALTER CREDENTIALSTORE ADD USER scott
Password: ********

Example 2

This example adds the user scott with his password tiger and specifies an alias
for scott that is named scsm2.

ALTER CREDENTIALSTORE ADD USER scott PASSWORD tiger ALIAS scsm2

Example 3

This example adds the user scott under the domain of support.

ALTER CREDENTIALSTORE ADD USER scott ALIAS scsm3 DOMAIN support
Password: ********

Example 4

This example issues two ALTER CREDENTIALSTORE commands, each of which
adds a scott entry, but with a different alias.

ALTER CREDENTIALSTORE ADD USER scott ALIAS scsm2
Password: ********
ALTER CREDENTIALSTORE ADD USER scott ALIAS scsm3
Password: ********

Example 5

The following shows how the DELETE USER option works with and without the
ALIAS option.

The following command deletes the user1 entry for which the ALIAS is the
same as the user name.

ALTER CREDENTIALSTORE DELETE USER user1

The following command deletes the entry for user user1 that is associated
with the alias alias1.

ALTER CREDENTIALSTORE DELETE USER user1 ALIAS alias1
Alias: alias1
Userid: user1

Example 6
This example uses a SQL*Net connect string as the user value. In this case,
the PASSWORD option is omitted. The person issuing the command will be
prompted for the password, which is obfuscated.
ALTER CREDENTIALSTORE ADD USER oggext1@ora1 ALIAS ora1

---------------------------------------------------------------------
INFO CREDENTIALSTORE

Use the INFO CREDENTIALSTORE command to get information about an Oracle
GoldenGate credential store. This information includes the aliases that a
credential store contains and the user IDs that correspond to them. The
encrypted passwords in the credential store are not returned.

The credential store location is identified by the CREDENTIALSTORELOCATION
parameter in the GLOBALS file, if one exists, or otherwise by the default
location of dircrdin the Oracle GoldenGate installation directory.

The use of a credential store is not supported for the iSeries, z/OS,
and NonStop platforms.

For more information about Oracle GoldenGate security options,
see Administering Oracle GoldenGate.

Syntax

INFO CREDENTIALSTORE [DOMAIN domain]

DOMAIN domain

Returns the aliases and user IDs for a specific domain. For security purposes,
if the DOMAIN option is omitted, only the aliases and user IDs under the
default domain of OracleGoldenGateare shown. It is not possible to see DOMAIN
credentials unless the person issuing the INFO CREDENTIALSTORE command knows
the name of the domain. See “ALTER CREDENTIALSTORE” for more information about
domains.

Examples

Example 1

The following example shows the default output of INFO CREDENTIALSTORE.

INFO CREDENTIALSTORE
Domain: OracleGoldenGate
Alias: support1
Userid: scott
Alias: sales1
Userid: scott

Example 2

The following example shows the output when DOMAINis used.
INFO CREDENTIALSTORE DOMAIN support
Domain: Support
Alias: support1
Userid: scott

---------------------------------------------------------------------
DELETE CREDENTIALSTORE

Use the DELETE CREDENTIALSTORE command to remove a credential store from
the system. The credential store wallet and its contents are permanently
deleted.

The use of a credential store is not supported for the DBE for i, DB2 z/OS, and
NonStop platforms

For more information about Oracle GoldenGate security options, see
Administering Oracle GoldenGate.

Syntax

DELETE CREDENTIALSTORE

---------------------------------------------------------------------

####################################
#
#TRAIL COMMANDS
#
#
####################################
---------------------------------------------------------------------

ADD EXTTRAIL

Use ADD EXTTRAIL to create a trail for online processing on the local
system and:

* Associate it with an Extract group.

* Assign a maximum file size.

Syntax

ADD EXTTRAIL trail_name, EXTRACT group_name
MEGABYTES n]
[SEQNO n]

trail_name

The relative or fully qualified path name of the trail. The trail
name can contain only two characters. Oracle GoldenGate appends this
name with a nine-digit sequence number whenever a new file is created.
For example, a trail named dirdat/tr would have files named dirdat/tr000000001,
dirdat/tr000000002, and so forth.

group_name

The name of the Extract group to which the trail is bound. Only one Extract
process can write data to a trail.

MEGABYTES n

The maximum size, in megabytes, of a file in the trail. The default is 500.

SEQNO n

Specifies that the first file in the trail will start with the specified
trail sequence number. Do not include any zero padding. For example, to
start at sequence 3 of a trail named tr, specify SEQNO 3. The actual file
would be named /ggs/dirdat/tr000000003. This option can be used during
troubleshooting when Replicat needs to be repositioned to a certain trail
sequence number. It eliminates the need to alter Replicat to read the
required sequence number.

Examples

Example 1

ADD EXTTRAIL dirdat/aa, EXTRACT finance, MEGABYTES 200

Example 2

ADD EXTTRAIL /ggs/dirdat/tr000000003

---------------------------------------------------------------------
ADD RMTTRAIL

Use ADD RMTTRAIL to create a trail for online processing on a remote system and:

* Assign a maximum file size.

* Associate the trail with an Extract group.

In the parameter file, specify a RMTHOST entry before any RMTTRAIL entries
to identify the remote system and TCP/IP port for the Manager process.

Note:
The RMTTRAIL size (Target Trail) must be greater than or equal to the
EXTTRAIL size (Source Trail), due to trail encryption requirements.

Syntax:

ADD RMTTRAIL trail_name, EXTRACT group_name
[, MEGABYTES n]
[SEQNO n]

trail_name

The relative or fully qualified path name of the trail. The actual trail
name can contain only two characters. Oracle GoldenGate appends this name
with a nine-digit sequence number whenever a new file is created. For example,
a trail named ./ dirdat/tr would have files named ./dirdat/tr000000001,
./dirdat/tr000000002, and so forth.

group_name

The name of the Extract group to which the trail is bound. Only one primary
Extract process can write data to a remote trail.

MEGABYTES n

The maximum size, in megabytes, of a file in the trail. The default is 500.

SEQNO n

Specifies that the first file in the trail will start with the specified
trail sequence number. Do not include any zero padding. For example, to start
at sequence 3 of a trail named tr, specify SEQNO 3. The actual file would
be named /ggs/dirdat/tr000000003. This option can be used during
troubleshooting when Replicat needs to be repositioned to a certain trail
number. It eliminates the need to alter Replicat to read the required
sequence number.

Example

Example 1

ADD RMTTRAIL dirdat/aa, EXTRACT finance, MEGABYTES 200

Example 2

ADD RMTTRAIL /ggs/dirdat/tr000000003

---------------------------------------------------------------------
ALTER EXTTRAIL

Use ALTER EXTTRAIL to change the attributes of a trail that was created
with the ADD EXTTRAIL command (a trail on the local system). The change
takes effect the next time that Extract starts.

Before using this command, stop the Extract using the STOP EXTRACT group_name
command.

Syntax

ALTER EXTTRAIL trail_name, EXTRACT group_name
MEGABYTES n]

trail_name

The relative or fully qualified path name of the trail. For example,
dirdat/aa.

group_name

The name of the Extract group to which the trail is bound.

MEGABYTES n

The maximum size of a file, in megabytes. The default is 500. After using
this option, issue the SEND EXTRACT command with the ROLLOVER option to
close the current trail file and open a new one.

Example

ALTER EXTTRAIL dirdat/aa, EXTRACT finance, MEGABYTES 200

---------------------------------------------------------------------
ALTER RMTTRAIL

Use ALTER RMTTRAIL to change the attributes of a trail that was created
with the ADD RMTTRAIL command (a trail on a remote system). The change takes
effect the next time that Extract starts.

Syntax

ALTER RMTTRAIL trail_name, EXTRACT group_name
MEGABYTES n]

trail_name

The relative or fully qualified path name of the trail. For example,
dirdat/aa.

group_name

The name of the Extract group to which the trail is bound.

MEGABYTES n

The maximum size of a file, in megabytes. The default is 500. After using
this option, issue the SEND EXTRACT command with the ROLLOVER option to close
the current trail file and open a new one.

Example

ALTER RMTTRAIL dirdat/aa, EXTRACT finance, MEGABYTES 200

---------------------------------------------------------------------
DELETE EXTTRAIL

Use DELETE EXTTRAIL to delete the record of checkpoints associated with a
trail on a local system. Checkpoints are maintained in a file bearing the
same name as the group in the dirchk sub-directory of the Oracle GoldenGate
directory.

This command only deletes references to the specified trail from the checkpoint
file. It does not delete the trail files themselves. To delete the trail files,
use the PURGE EXTTRAIL command. See Administering Oracle GoldenGate for more
information about checkpoints.

Syntax

DELETE EXTTRAIL trail_name

trail_name

The relative or fully qualified path name of the trail, including the
two-character trail prefix.

Example

DELETE EXTTRAIL dirdat/et

---------------------------------------------------------------------
DELETE RMTTRAIL

Use DELETE RMTTRAIL to delete the record of checkpoints associated with a
trail on a remote system. Checkpoints are maintained in a file bearing
the same name as the group in the dirchk sub-directory of the Oracle GoldenGate
directory.

This command only deletes references to the specified trail from the
checkpoint file. It does not delete the trail files themselves.

Syntax

DELETE RMTTRAIL trail_name EXTRACT group_name

trail_name

The relative or fully qualified path name of the trail, including the
two-character trail prefix.

group_name

The name of the Extract group to which the trail is bound. If not specified,
DELETE RMTTRAIL deletes the trail reference from all Extract groups that
write to the specified trail.

Example

DELETE RMTTRAIL dirdat/et

---------------------------------------------------------------------
INFO EXTTRAIL

Use INFO EXTTRAIL to retrieve configuration information for a local trail.
It shows the name of the trail, the Extract that writes to it, the position
of the last data processed, and the assigned maximum file size.

Syntax

INFO EXTTRAIL trail_name

trail_name

The relative or fully qualified path name of the trail or a wildcard
designating multiple trails.

Examples

Example 1

INFO EXTTRAIL dirdat/aa

Example 2

INFO EXTTRAIL *

Example 3

The following is sample output of INFO EXTTRAIL.
Extract Trail: c:\gg_81\dirdat\md
Extract: GGSEXT8
Seqno: 2
RBA: 51080
File Size: 100M

---------------------------------------------------------------------
INFO RMTTRAIL

Use INFO RMTTRAIL to retrieve configuration information for a remote trail.
It shows the name of the trail, the Extract that writes to it, the position
of the last data processed, and the assigned maximum file size.

Syntax

INFO RMTTRAIL trail_name

trail_name

The relative or fully qualified path name of the trail or a wildcard
designating multiple trails.

Examples

Example 1

INFO RMTTRAIL dirdat/aa

Example 2

INFO RMTTRAIL *

Example 3

The following is a sample of INFO RMTTRAILoutput.
Extract Trail: /ogg/dirdat/aa
Seqno Length: 9
Flip Seqno Length: no
Extract: OGGPMP
Seqno: 4
RBA: 78066
File Size: 500M

---------------------------------------------------------------------
VIEW PARAMS

Use VIEW PARAMS to view the contents of a parameter file.
Caution:
Do not use this command to view a parameter file that is in a character
set other than that of the local operating system (such as one where
the CHARSET option was used to specify a different character set). The
contents may become corrupted. View the parameter file from outside GGSCI.

Syntax

VIEW PARAMS {MGR | group_name | file_name}

MGR

Shows the Manager parameter file.

group_name

Shows the parameter file for the specified Extract or Replicat group.

file_name

Shows the specified file. By default, the subdirectory dirprm is used if no
path is specified. If the parameter file resides in a directory other than
dirprm, specify the full path name.

Examples

Example 1

VIEW PARAMS finance

Example 2

VIEW PARAMS c:\lpparms\replp.prm

---------------------------------------------------------------------
####################################
#
#PARAMETER COMMANDS
#
#
####################################
---------------------------------------------------------------------
EDIT PARAMS

Use EDIT PARAMS to create or change a parameter file. By default, this
launches Notepad on Windows systems or the vi editor on UNIX systems. You
can change the editor with the SET EDITOR command.

Caution:
Do not use this command to view or edit an existing parameter file that
is in a character set other than that of the local operating system (such
as one where the CHARSET option was used to specify a different character
set). The contents may become corrupted. View the parameter file from
outside GGSCI.

Syntax

EDIT PARAMS {MGR | group_name | file_name}

MGR

Opens a parameter file for the Manager process.

group_name

Opens a parameter file for the specified Extract or Replicat group.

file_name

Opens the specified file. When you create a parameter file with EDIT PARAMS
in GGSCI, it is saved to the dirprm sub-directory of the Oracle GoldenGate
directory. You can create a parameter file in a directory other than dirprm
by specifying the full path name, but you must also specify the full path name
with the PARAMS option of the ADD EXTRACT or ADD REPLICAT command when you
create the process group.

Examples

Example 1

EDIT PARAMS finance

Example 2

EDIT PARAMS c:\lpparms\replp.prm

---------------------------------------------------------------------
SET EDITOR

Use SET EDITOR to change the default text editor for the current session of
GGSCI. The default editors are Notepad for Windows and vi for UNIX. GGSCI
input, including to create parameter files, takes the character set of the
local operating system.

Syntax

SET EDITOR program_name

program_name

Any text editor.

Example

The following example changes the default editor to Wordpad.

SET EDITOR wordpad

---------------------------------------------------------------------

INFO PARAM

Use INFO PARAM to retrieve the parameter definition information. If a name
matches multiple records, they are all displayed. If the query parameter
has child options, they are not displayed in the output though their names
are listed in the Options tab. To display the full record of an option, the
full name in the form of parameter.option should be queried separately.

This parameter infrastructure allows unlimited levels of options. Thus, a
full name of a parameter or option might have numbers of segments, such
as A.B.C.D.

Syntax

INFO PARAM name

name
The name of a parameter, an option, or a full name that is part of the
several names concatenated together using dot ('.') as the delimiter. These
sample names are valid:

* STREAMING

* RMTHOST.STREAMING

* RMTHOST

* RMTHOSTOPTIONS.STREAMING

* TRANLOGOPTIONS.INTEGRATEDPARAM.EAGER_SIZE

The matching with this set of sample names is that STREAMING matches as
an option of both RMTHOST and RMTHOSTOPTIONS.

Example

INFO PARAM RMTHOST

---------------------------------------------------------------------
GETPARAMINFO

Syntax

SEND MGR | group GETPARAMINFO [parameter_name] [FILE output_file]

group

The name of the Extract or Replicat instance or MGR.

parameter_name

The default behavior is to display all parameters in use, meaning those
parameters that have ever been queried by the application, parameters, and
their current values. If you specify a particular parameter, then the output
is filtered by that name.

FILEoutput_file

The name of the text file that your output is redirected to.

Examples

Example 1

This example displays one parameter.

SEND MGR GETPARAMINFO PORT

Example 2

This example displays all parameters loaded from parameter file into Replicat
rep1 and those parameters that the rep1 has accessed.

SEND REPL GETPARAMINFO

Example 3

The following example redirects the output to a file.

SEND MGR GETPARAMINFO FILE mgrfile.out

---------------------------------------------------------------------
####################################
#
#DATABASE COMMANDS
#
#
####################################
---------------------------------------------------------------------
DBLOGIN

Use DBLOGIN to establish a database connection through GGSCI in preparation
to issue other Oracle GoldenGate commands that affect the database. The user
who issues DBLOGIN should have the appropriate database privileges to perform
the functions that are enacted by those commands. Any other special privileges
that are required for a GGSCI command are listed with the reference documentation
for that command.

Requirements When Configuring Extract or Replicat in Integrated Mode (Oracle)

If using DBLOGIN to issue ADD EXTRACT, ALTER EXTRACT, or REGISTER EXTRACT to
initiate integrated capture or ADD REPLICAT, ALTER REPLICAT, or REGISTER REPLICAT
to initiate integrated Replicat against an Oracle Database, the user who issues
DBLOGIN must:

* Have privileges granted through the Oracle dbms_goldengate_auth.grant_admin_privilege
procedure.

* Not be changed while Extract or Replicat is in integrated mode.

Special Database Privileges to Use Log Retention in Classic Capture Mode

When in classic capture mode for an Oracle Database, Extract supports the
log-retention feature, whereby the database retains the logs that Extract
needs. To enable the log-retention feature, DBLOGIN must be issued with special
privileges before using REGISTER EXTRACT with the LOGRETENTION option. For
simplicity, you can log in as the Extract database user if the correct
privileges were granted to that user when Oracle GoldenGate was installed.
Otherwise, log in as a user with the privileges shown in the following table:

Oracle Privileges for Log Retention
Oracle EE How to Grant Privileges version
11.1 and 11.2.0.1 1. Run package to grant Oracle GoldenGate admin privilege.
exec dbms_streams_auth.grant_admin_privilege('user')
2. Grant the 'become user' privilege.
grant become user to user;
11.2.0.2 and later Run package to grant Oracle GoldenGate admin privilege.
exec dbms_goldengate_auth.grant_admin_privilege('user')

Syntax

DBLOGIN {
[SOURCEDB data_source] |
database@host:port] |
USERID {/ | userid} PASSWORD password]

[algorithm ENCRYPTKEY {keyname | DEFAULT}] | USERIDALIAS alias [DOMAIN domain]
| [SYSDBA | SQLID sqlid] [SESSIONCHARSET character_set] }

SOURCEDB data_source

SOURCEDB specifies a data source name. This option is required to identify
one of the following:

* The source or target login database for MySQL and databases that use ODBC.

database@host:port

(MySQL) Specifies a connection string that contains the database name,
host name, and database port number. Can be used to specify a port other
than the default that is specified in the database configuration.

USERID

Supplies a database login credential, if required. Can be used if an Oracle
GoldenGate credential store is not in use. (See the USERIDALIAS option.)
Input varies, depending on the database, as follows:

userid

Specifies the name of a database user or a schema, depending on the
database configuration. For Oracle, a SQL*Net connect string can be
used. To log into a pluggable database in an Oracle multitenant container
database, specify userid as a connect string, such as OGGUSER@FINANCE.
To log into the root container, specify userid as a common user, including
the C## prefix, such as C##GGADMIN@FINANCE.

/
(Oracle) Directs Oracle GoldenGate to use an operating-system login for
Oracle, not a database user login. Use this argument only if the database
allows authentication at the operating-system level. To use this option,
the correct user name must exist in the database, in relation to the
value of the Oracle OS_AUTHENT_PREFIX initialization parameter. For more
information, see the USERID | NOUSERID parameter.

PASSWORD password

Use when authentication is required to specify the password for the
database user. If the password was encrypted by means of the ENCRYPT
PASSWORD command, supply the encrypted password; otherwise, supply the
clear-text password. If the password is case-sensitive, type it that way.

If the PASSWORD clause is omitted, you are prompted for a password, and
the password is not echoed.

algorithm

If the password was encrypted with the ENCRYPT PASSWORD command, specify
the encryption algorithm that was used:

AES128

AES192

AES256

BLOWFISH

ENCRYPTKEY {keyname | DEFAULT}

Specifies the encryption key that was specified with the ENCRYPT PASSWORD
command. Use one of the following:

ENCRYPTKEY keyname
Specifies the logical name of a user-created encryption key in the ENCKEYS
lookup file. Use if ENCRYPT PASSWORD was used with the KEYNAME option.

ENCRYPTKEY DEFAULT
Directs Oracle GoldenGate to generate a Blowfish key. Use if the ENCRYPT
was used with the KEYNAME DEFAULT option.

USERIDALIAS alias [DOMAIN domain]

Supplies a database login credential, if required. Can be used instead of the
USERID option if there is a local Oracle GoldenGate credential store that
contains a credential with the required privileges for this DBLOGIN command.
For more information about using a credential store, see Administering
Oracle GoldenGate.

alias

Specifies the alias of a database user credential that is stored in the
Oracle GoldenGate credential store. To log into a pluggable database in
an Oracle multitenant container database, the user must be stored as a
connect string, such as OGGUSER@FINANCE. To log into the root container,
the user must be stored as a common user, including the C## prefix, such as
C##GGADMIN@FINANCE. For more information about configuring Oracle GoldenGate
for a CDB, see the Oracle GoldenGate documentation for your database.

DOMAIN domain

Specifies the credential store domain for the specified alias. A valid domain
entry must exist in the credential store for the specified alias.

SYSDBA

(Oracle) Specifies that the user logs in as sysdba. This option can be used for
USERID and USERIDALIAS.

SQLID sqlid

(DB2 on z/OS) Issues the SQL command SET CURRENT SQLID = 'sqlid'after the USERID
login (with PASSWORD, if applicable) is completed. If the SET command fails, the
entire DBLOGIN command fails as a unit.

SESSIONCHARSET character_set

(Teradata and MySQL) Sets a database session character set for the
GGSCI connection to the database. All subsequent commands will use the
specified session character set. This command option overrides any SESSIONCHARSET
that is specified in the GLOBALS file.

Examples

Example 1 (Oracle)

DBLOGIN USERIDALIAS alias1

Example 2 (Oracle with non-default domain)

DBLOGIN USERIDALIAS alias1 DOMAIN domain1

Example 3 (Oracle with SYSDBA)

DBLOGIN USERID ogguser@pdb1 SYSDBA password
AACAAAAAAAAAAAJAUEUGODSCVGJEEIUGKJDJTFNDKEJFFFTC AES128, ENCRYPTKEY securekey1

Example 4 (MySQL)

DBLOGIN SOURCEDB mysqldb@host1:3305, USERIDALIAS alias1

Example 5 (MySQL)

DBLOGIN SOURCEDB database USERIDALIAS alias1

Example 6 (SQL Server with Integrated Windows authentication)

DBLOGIN SOURCEDB systemdsn

Example 7 (SQL Server)

DBLOGIN SOURCEDB systemdsn USERIDALIAS alias1

---------------------------------------------------------------------
ENCRYPT PASSWORD

Use ENCRYPT PASSWORD to encrypt a password that is used in an Oracle
GoldenGate parameter file or command.

Syntax

ENCRYPT PASSWORD password
[AES128 | AES192 | AES256 | BLOWFISH]
ENCRYPTKEY {key_name | DEFAULT}

password
The login password. Do not enclose the password within quotes. If the
password is case-sensitive, type it that way.

AES128 | AES192 | AES256 | BLOWFISH
Specifies the encryption algorithm to use.

* AES128uses the AES-128 cipher, which has a key size of 128 bits.

* AES192uses the AES-192 cipher, which has a key size of 192 bits.

* AES256uses the AES-256 cipher, which has a key size of 256 bits.

* BLOWFISH uses Blowfish encryption with a 64-bit block size and a variable-
length key size from 32 bits to 128 bits. Use BLOWFISH only for backward
compatibility with earlier Oracle GoldenGate versions.

If no algorithm is specified, AES128 is the default for all database types
except DB2 on z/OS, where BLOWFISH is the default. AES is not supported for
those platforms.

All of the AES ciphers have a 128-bit block size.

To use AES encryption for any database other than Oracle, the path of the lib
sub-directory of the Oracle GoldenGate installation directory must be specified
as an environment variable before starting any processes:

* Linux: Specify the path as an entry to the LD_LIBRARY_PATH or SHLIB_PATH
variable. For example:

setenv LD_LIBRARY_PATH ./lib:$LD_LIBRARY_PATH

* For Solaris: Specify the path as an entry to the SHLIB_PATH variable.
* For IBMi and AIX: Specify the path as an entry to the LIBPATH variable.
* Windows: Add the path to the PATH variable.

You can use the SETENV parameter to set it as a session variable for the
process.

ENCRYPTKEY {key_name | DEFAULT}

Specifies the encryption key.

key_name

Specifies the logical name of a user-created encryption key in a local
ENCKEYS lookup file. The key name is used to look up the actual key in the
ENCKEYS file. A user-created key and an associated ENCKEYS file is required
when using AES encryption; optional, but recommended, for Blowfish encryption.
To use key_name, generate the key with KEYGEN or another utility, then store
it in an ENCKEYS file on the source and target systems.

DEFAULT

Directs Oracle GoldenGate to generate a random key that is stored in the
trail so that decryption can be performed by the downstream process. This
type of key is insecure and should not be used in a production environment.
Use this option only when BLOWFISH is specified. ENCRYPT PASSWORD returns
an error if DEFAULT is used with any AES algorithm.

Examples

Example 1

ENCRYPT PASSWORD ny14072 BLOWFISH ENCRYPTKEY DEFAULT

Example 2

ENCRYPT PASSWORD ny14072 BLOWFISH ENCRYPTKEY superkey3

Example 3

ENCRYPT PASSWORD ny14072 AES192 ENCRYPTKEY superkey2

---------------------------------------------------------------------
####################################
#
#DDL COMMANDS
#
#
####################################
---------------------------------------------------------------------

DUMPDDL

Use the DUMPDDL command to view the data in the Oracle GoldenGate DDL history
table if the trigger-based DDL capture is in use. This information is the
same information that is used by the Extract process. It is stored in proprietary
format, but can be exported in human-readable form to the screen or to a
series of SQL tables that can be queried by using regular SQL.

DUMPDDL always dumps all of the records in the DDL history table. Use SQL
queries or search redirected standard output to view information about
particular objects and the operations you are interested in. Because the
history table contains large amounts of data, only the first 4000 bytes
(approximately) of a DDL statement are displayed in order to maintain
efficient performance. The format of the metadata is string based. It is
fully escaped and supports table and column names in their native character
set.

Because the information is historical data that is provided by the DDL before
trigger, it reflects the state of an object before a DDL change. Consequently,
there will not be any data for CREATE operations.

Note:
The default name of the before trigger is GGS_DDL_TRIGGER_BEFORE.

Before using DUMPDDL, log into the database as the owner of the history
table by using the DBLOGIN command.

The basic DUMPDDL command outputs metadata to the following tables:

GGS_DDL_OBJECTS Information about the objects for which DDL operations
are being synchronized. SEQNO is the primary key. All
of the other tables listed here contain a SEQNO column
that is the foreign key to GGS_DDL_OBJECTS.
GGS_DDL_COLUMNS Information about the columns of the objects involved
in DDL synchronization.
GGS_DDL_LOG_GROUPS Information about the supplemental log groups involved
in DDL synchronization.
GGS_DDL_PARTITIONS Information about the partitions for objects involved
in DDL synchronization.
GGS_DDL_PRIMARY_KEYS Information about the primary keys of the objects
involved in DDL synchronization.

The SEQNO column is the DDL sequence number that is listed in the Extract and
Replicat report files. It also can be obtained by querying the DDL history
table (default name is GGS_DDL_HIST).

All of these tables are owned by the schema that was designated as the Oracle
GoldenGate DDL schema during the installation of the DDL objects. To view the
structure of these tables, use the DESC command in SQL*Plus.

Syntax

DUMPDDL [SHOW]

SHOW

Dumps the information contained in the history table to the screen in standard
output format. No output tables are produced. All records in the DDL history
table are shown.

---------------------------------------------------------------------
FLUSH SEQUENCE

Use FLUSH SEQUENCE immediately after you start Extract for the first time during
an initial synchronization or a re-synchronization. This command updates an Oracle
sequence so that initial redo records are available at the time that Extract
starts to capture transaction data. Normally, redo is not generated until the
current cache is exhausted. The flush gives Replicat an initial start point
with which to synchronize to the correct sequence value on the target system.
From then on, Extract can use the redo that is associated with the usual cache
reservation of sequence values.

To Use FLUSH SEQUENCE

The following Oracle Database procedures are used by FLUSH SEQUENCE:

Database Procedure User and Privileges e
Source updateSequence Grants EXECUTE to the owner of the Oracle GoldenGate
DDL objects, or other selected user if not using DDL support.
Target replicateSequen Grants EXECUTE to the Oracle GoldenGate Replicat ce
user.

The sequence.sqlscript installs these procedures. Normally, this script is run
as part of the Oracle GoldenGate installation process, but make certain that was
done before using FLUSH SEQUENCE. If sequence.sqlwas not run, the flush fails and
an error message similar to the following is generated:
Cannot flush sequence {0}. Refer to the Oracle GoldenGate for Oracle documentation
for instructions on how to set up and run the sequence.sql script. Error {1}.

2. The GLOBALS file must contain a GGSCHEMA parameter that specifies the schema
in which the procedures are installed. This user must have CONNECT, RESOURCE, and DBA
privileges.

3. Before using FLUSH SEQUENCE, issue the DBLOGIN command as the database user
that has EXECUTE privilege on the updateSequence procedure. If logging into a
multitenant container database, log into the pluggable database that contains
the sequence that is to be flushed.

Note:
For full instructions on configuring Oracle GoldenGate to support sequences,
see the Oracle GoldenGate documentation for your databaseDatabase.

Syntax

FLUSH SEQUENCE owner.sequence

owner.sequence

The owner and name of an Oracle sequence. The schema name cannot be null. You
can use an asterisk (*) wildcard for the sequence name but not for the owner
name.

Example

FLUSH SEQUENCE scott.seq*

---------------------------------------------------------------------
LIST TABLES

Use LIST TABLES to list all tables in the database that match the specification
provided with the command argument. Use the DBLOGIN command to establish a
database connection before using this command. If logging into an Oracle
multitenant container database, log in to the pluggable database that contains
the tables that you want to list.

Syntax

LIST TABLES table

table

The name of a table or a group of tables specified with a wildcard (*).

Example

The following shows a LIST TABLES command and sample output.

list tables tcust*

TCUSTMER
TCUSTORD

---------------------------------------------------------------------
MININGDBLOGIN

Use MININGDBLOGIN to establish a connection to a downstream Oracle Database
logmining server in preparation to issue other Oracle GoldenGate commands
that affect this database, such as REGISTER EXTRACT. Use this command only
if establishing Extract in integrated capture mode for an Oracle Database.

To log into a source Oracle Database that serves as the database logmining
server, use the DBLOGIN command. MININGDBLOGIN is reserved for login to a
downstream mining database.

The user who issues MININGDBLOGIN must:

* Have privileges granted through the Oracle
dbms_goldengate_auth.grant_admin_privilege procedure.

* Be the user that is specified with the TRANLOGOPTIONS MININGUSER parameter
for the Extract group that is associated with this MININGDBLOGIN.

* Not be changed while Extract is in integrated capture mode.

For support and configuration information for integrated capture, see the
Oracle GoldenGate documentation for your database.

Syntax

MININGDBLOGIN {

USERID {/ | userid} PASSWORD password] [algorithm ENCRYPTKEY {keyname |
DEFAULT}] | USERIDALIAS alias [DOMAIN domain] |
[SYSDBA]
}
USERID
Supplies a database login credential. Can be used if an Oracle GoldenGate
credential store is not in use. (See the USERIDALIAS option.) Input varies,
depending on the database, as follows:

userid

Specifies the name of a database user or a SQL*Net connect string. To log
into a pluggable database in an Oracle multitenant container database,
specify useridas a connect string, such as OGGUSER@FINANCE. To log into
the root container, specify useridas a common user, including the C##
prefix, such as C##GGADMIN@FINANCE. For more information about configuring
Oracle GoldenGate for a CDB, see the Oracle GoldenGate documentation for
your database.

/
(Oracle) Directs Oracle GoldenGate to use an operating-system login for
Oracle, not a database user login. Use this argument only if the database
allows authentication at the operating-system level. To use this option,
the correct user name must exist in the database, in relation to the value of
the Oracle OS_AUTHENT_PREFIX initialization parameter. For more information,
see the USERID | NOUSERID parameter.

PASSWORD password

Use when authentication is required to specify the password for the database
user. If the password was encrypted by means of the ENCRYPT PASSWORD command,
supply the encrypted password; otherwise, supply the clear-text password. If
the password is case-sensitive, type it that way.

If the PASSWORD clause is omitted, you are prompted for a password, and the
password is not echoed.

algorithm

If the password was encrypted with the ENCRYPT PASSWORD command, specify the
encryption algorithm that was used:

AES128
AES192
AES256
BLOWFISH

ENCRYPTKEY {keyname | DEFAULT}

Specifies the encryption key that was specified with the ENCRYPT PASSWORD
command. Use one of the following:

ENCRYPTKEY keyname

Specifies the logical name of a user-created encryption key in the ENCKEYS
lookup file. Use if ENCRYPT PASSWORD was used with the KEYNAME option.

ENCRYPTKEY DEFAULT

Directs Oracle GoldenGate to generate a Blowfish key. Use if the ENCRYPT
PASSWORD command was used with the KEYNAME DEFAULT option.

USERIDALIAS alias [DOMAIN domain]

Supplies the alias of a database login credential. Can be used instead of the
USERID option if there is a local Oracle GoldenGate credential store that
contains a credential with the required privileges for this MININGDBLOGIN
command. For more information about using a credential store, see Administering
Oracle GoldenGate.

To log into a pluggable database in an Oracle multitenant container database,
the user must be stored as a connect string, such as OGGUSER@FINANCE. To log
into the root container, the user must be stored as a common user, including
the C## prefix, such as C##GGADMIN@FINANCE. For more information about
configuring Oracle GoldenGate for a CDB, see the Oracle GoldenGate documentation
for your database.

alias

Specifies the alias of a database user credential that is stored in the
Oracle GoldenGate credential store. The user that is specified with
USERIDALIAS must be the common database user.

DOMAIN domain

Specifies the credential store domain for the specified alias. A valid
domain entry must exist in the credential store for the specified alias.

SYSDBA

(Oracle) Specifies that the user logs in as sysdba. This option can be used
for USERID and USERIDALIAS.

Examples

Example 1

MININGDBLOGIN USERIDALIAS oggalias SESSIONCHARSET ISO-8859-11

Example 2

MININGDBLOGIN USERID ogg@ora1.ora, PASSWORD
AACAAAAAAAAAAAJAUEUGODSCVGJEEIUGKJDJTFNDKEJFFFTC AES128, ENCRYPTKEY securekey1

---------------------------------------------------------------------
SET NAMECCSID

Use NAMECCSID to set the CCSID (coded character set identifier) of the
GGSCI session when you need to issue commands for tables in a DB2 for i
database. This command is required if the CCSID of the object names stored
in the SQL catalog tables is different from the CCSID of the system. The SQL
catalog tables are created with the CCSID of the system, but the actual
database object names could be represented with a different CCSID. The
catalog does not indicate this difference when queried, and therefore
Oracle GoldenGate could retrieve the name incorrectly unless NAMECCSIDis
present to supply the correct CCSID value.

To set the CCSID for GLOBALS, Extract, Replicat, or DEFGEN, use the
NAMECCSID parameter.

SET NAMECCSID is not valid if the DBLOGIN command was previously issued,
because that command affects the GGSCI session. To issue SET NAMECCSID
after a DBLOGIN command, restart GGSCI.

To view the current CCSID, use the SHOW command. If the CCSID is not set
through the GGSCI session or through the parameter NAMECCSID, the SHOW
value will be DEFAULT.

Syntax

SET NAMECCSID {CCSID | DEFAULT}

CCSID

A valid DB2 for i coded character set identifier that is to be used for
the GGSCI session.

DEFAULT

Indicates that the system CCSID is to be used for the GGSCI session.

Example

SET NAMECCSID 1141

---------------------------------------------------------------------
####################################
#
#TRANDATA COMMANDS
#
#
####################################

--------------------------------------------------------------------
ADD SCHEMATRANDATA

Valid for Oracle. Use ADD SCHEMATRANDATA to enable schema-level
supplemental logging for a schema. ADD SCHEMATRANDATA acts on all of the
current and future tables in a given schema to automatically log a superset
of available keys that Oracle GoldenGate needs for row identification.

ADD SCHEMATRANDATAis valid for both integrated and classic capture and
does the following:

* Enables Oracle supplemental logging for new tables created with a
CREATE TABLE.

* Updates supplemental logging for tables affected by an ALTER TABLE
to add or drop columns.

* Updates supplemental logging for tables that are renamed.

* Updates supplemental logging for tables for which unique or primary keys
are added or dropped.

By default, ADD SCHEMATRANDATA enables the unconditional logging of the
primary key and the conditional supplemental logging of all unique keys
and foreign keys of any table within the specified schema in the following
order:

1. Primary key.

2. Even if the primary key exists, the unique indexes are supplementally logged.
This is, because the default for Oracle are the scheduling columns!. Unique keys that
contain ADT member columns are also logged. Only unique keys on virtual
columns (function-based indexes) are not logged.

3. If none of the preceding exists, all scalar columns of the table are
logged. (System-generated row-OIDs are always logged.)

ADD SCHEMATRANDATA also supports the conditional or unconditional logging
requirements for using integrated Replicat.

Note:
Apply Oracle Patch 10423000 to the source database if the Oracle version
is earlier than 11.2.0.2.

When to Use ADD SCHEMATRANDATA
ADD SCHEMATRANDATA must be used in the following cases:

* For all tables that are part of an Extract group that is to be
configured for integrated capture. ADD SCHEMATRANDATA ensures that the
correct key is logged by logging all of the keys.

* For all source tables that will be processed in an integrated Replicat
group. Options are provided that enable the logging of the primary, unique,
and foreign keys to support the computation of dependencies among relational
tables being processed through different apply servers.

* When DDL replication is active and DML is concurrent with DDL that creates
new tables or alters key columns. It best handles scenarios where DML can be
applied to objects very shortly after DDL is issued on them. ADD SCHEMATRANDATA
causes the appropriate key values to be logged in the redo log atomically with
each DDL operation, thus ensuring metadata continuity for the DML when it is
captured from the log, despite any lag in Extract processing.

Database-level Logging Requirements for Using ADD SCHEMATRANDATA

Supplemental Logging is only managed (controlled) on the source database.
Minimal supplemental Logguing is a must for the source database so you must put
the source database into forced logging mode and enable minimal supplemental
logging at the database level when using Oracle GoldenGate. This adds row
chaining information, if any exists, to the redo log for update operations.

Additional Considerations for Using ADD SCHEMATRANDATA

* Before using ADD SCHEMATRANDATA, issue the DBLOGIN command. The user who
issues the command must be granted an Oracle GoldenGate administrator user.

SQL> exec dbms_goldengate_auth.grant_admin_privilege('user')

* ADD SCHEMATRANDATA can be used instead of the ADD TRANDATA command when DDL
replication is not enabled. Note, however, that if a table has no primary key
but has multiple unique keys, ADD SCHEMATRANDATA causes the database to log all
of the unique keys. In such cases, ADD SCHEMATRANDATA causes the database to log
more redo data than does ADD TRANDATA. To avoid the extra logging, designate one
of the unique keys as a primary key, if possible.

* For tables with a primary key, with a single unique key, or without a key, ADD
SCHEMATRANDATA adds no additional logging overhead, as compared to ADD TRANDATA.

For more information, see ADD TRANDATA.

* If you must log additional, non-key columns of a specific table (or tables) for
use by Oracle GoldenGate, such as those needed for FILTER statements and KEYCOLS
clauses in the TABLE and MAP parameters, issue an ADD TRANDATA command for those
columns. That command has a COLS option to issue table-level supplemental logging
for the columns, and it can be used in conjunction with ADD SCHEMATRANDATA.

Syntax

ADD SCHEMATRANDATA schema {
[ALLOWNONVALIDATEDKEYS]
[NOSCHEDULINGCOLS | ALLCOLS]}
[NOVALIDATE]
[PREPARECSN {WAIT | LOCK | NOWAIT | NONE}]

schema

The schema for which you want the supplementary key information to be logged.
Do not use a wildcard. To issue ADD SCHEMATRANDATA for schemas in more than one
pluggable database of a multitenant container database, log in to each pluggable
database separately with DBLOGINand then issue ADD SCHEMATRANDATA.

ALLOWNONVALIDATEDKEYS

This option is valid for Oracle 11.2.0.4 and later 11g versions and Oracle 12.1.0.2
and later 12c versions. (Not valid for Oracle 11.2.0.3 or 12.1.0.1.) It includes NON
VALIDATED and NOT VALID primary keys in the supplemental logging. These keys override
the normal key selection criteria that is used by Oracle GoldenGate. If the GLOBALS
parameter ALLOWNONVALIDATEDKEYS is being used, ADD SCHEMATRANDATA runs with
ALLOWNONVALIDATEDKEYS whether or not it is specified. By default, NON VALIDATED
and NOT VALID primary keys are not logged.

NOSCHEDULINGCOLS | ALLCOLS

You can use these options together though the latter option is used. For example, with the
ADD SCHEMATRANDATA oggadm_ext ALLCOL NOSCHEDULINGCOLS command the NOSCHEDULINGCOLS
option would be used. By default, ADD SCHEMATRANDATA enables:

* unconditional logging of the primary key
* conditional supplemental logging of all unique key(s)
* conditional supplemental logging of all foreign key(s) of all current and
future tables in the given schema.

Unconditional log groups log the before images of the specified columns when the table is
changed, regardless of whether the change affected any of the specified columns. Unconditional
log groups are sometimes referred to as "always log groups." Conditional log groups log the
before images of all specified columns only if at least one of the columns in the log group
is changed.

NOSCHEDULINGCOLS

Disables the logging of scheduling columns. Unconditional logging forces the primary
key values to the log whether or not the key was changed in the current
operation. Conditional logging logs all of the column values of a foreign or
unique key if at least one of them was changed in the current operation. The
integrated Replicat primary key, unique keys, and foreign keys must all be
available to the inbound server to compute dependencies. Setting supplemental
logging on the source database impacts the target database when identifying the
unique row and dependency calculations (based on the key columns at the target
system).

ALLCOLS

Enables the unconditional supplemental logging of all supported key and non-key
columns for all current and future tables in the given schema. This option
enables the logging of the keys required to compute dependencies, plus columns
that are required for filtering, conflict resolution, or other purposes. Columns
like LOB, LONG, and ADT are not included.

NOVALIDATE

Valid for all databases supported by ADD SCHEMATRANDATA.
Suppresses additional information about the table being handled being processed
by ADD SCHEMATRANDATA. By default, this option is enabled. The additional
information processing creates a lapse time on command response so this
option can be used to increase response time.

PREPARECSN {WAIT | LOCK | NOWAIT | NONE}

Valid for Oracle for both DML and DDL. Automatically prepares the tables at the source
so the Oracle data pump export dump file will includes Instantiation CSNs. Replicat uses
the per table instantiation CSN set by the Oracle Datapump (on import) to filter out
trail records. On the target, the data pump import populates the system tables and
views with instantiation SCNs using the DBOPTIONS ENABLE_INSTANTIATION_FILTERING
parameter to enable table-level instantiation filtering.

WAIT

Wait for any in-flight transactions and prepare table instantiation.

LOCK

Put a lock on the table (to prepare for table instantiation).

NOWAIT

Default behavior, preparing for instantiation is done immediately.

NONE

No instantiation preparation occurs.

Example

Example 1

The following enables supplemental logging for the schema scott.

ADD SCHEMATRANDATA scott

Example 2

The following example logs all supported key and non-key columns for all current
and future tables in the schema named scott.

ADD SCHEMATRANDATA scott ALLCOLS
Example 3

The following example suppress additional table information processing.

ADD SCHEMATRANDATA acct.emp* NOVALIDATE

---------------------------------------------------------------------
ADD TRANDATA

Use ADD TRANDATA to enable Oracle GoldenGate to acquire the transaction information
that it needs from the transaction records.

Before using this command, use the DBLOGIN command to establish a database
connection.

ADD TRANDATA is valid only for the source databases that are listed here. For other
supported databases, this functionality may exist already or must be configured
through the database interface. See the Oracle GoldenGate configuration guide for
your database for any special requirements that apply to making transaction
information available.

DB2 for i Databases

Use ADD TRANDATA to start the journaling of data. The ADD TRANDATA command calls
STRJRNP F and is the recommended method to start journaling for tables, because it
ensures that the required journal image attribute of Record Images (IMAGES): *BOTH
is set on the STRJRNPF command.

DB2 LUW Database

Use ADD TRANDATA to enable DATA CAPTURE CHANGESon specified tables. By default, ADD
TRANDATA issues the following command to the database:
ALTER TABLE name DATA CAPTURE CHANGES INCLUDE LONGVAR COLUMNS;
You can exclude the LONGVAR clause by using ADD TRANDATA with the EXCLUDELONG option.

DB2 z/OS Database

Use ADD TRANDATA to enable DATA CAPTURE CHANGESon specified tables. By default, ADD
TRANDATA issues the following command to the database:
ALTER TABLE name DATA CAPTURE CHANGES;

Oracle Database

By default, ADD TRANDATA for Oracle enables the unconditional logging of the primary
key and the conditional supplemental logging of all unique key(s) and foreign key(s)
of the specified table.

If possible, use the ADD SCHEMATRANDATA command rather than the ADD TRANDATA command.
The ADD SCHEMATRANDATA command ensures replication continuity should DML occur on an
object for which DDL has just been performed. You can exclude objects from the
schema specification by using the exclusion parameters.

To use the Oracle GoldenGate DDL replication feature, you must use the ADD
SCHEMATRANDATA command to log the required supplemental data.

When using ADD SCHEMATRANDATA, you can use ADD TRANDATA with the COLS option to
any non-key columns, such as those needed for FILTER statements and KEYCOLS clauses
in the TABLE and MAP parameters.

Note:
It is possible to use ADD TRANDATA for Oracle when DDL support is enabled, but
only if you can stop DML on all tables before DDL is performed on them or, if
that is not possible, you can guarantee that no users or applications will issue
DDL that adds new tables whose names satisfy an object specification in a TABLE
or MAP statement. There must be no possibility that users or applications will
issue DDL that changes the key definitions of any tables that are already in
the Oracle GoldenGate configuration.

Take the following into account when using ADD TRANDATA for an Oracle Database:

* If any of the logging details change after Oracle GoldenGate starts extracting
data, you must stop and then start the Extract process that is reading from the
affected table before any data is changed.

* When enabling supplemental logging with ADD TRANDATA, Oracle GoldenGate creates
at least a supplemental log group with the extention of the object ID to a prefix of
GGS_. For example GGS_18342. Depending on the configuration options, additional
supplemental log groups may appear.

For SQL Server
Use ADD TRANDATA to provide the extended logging information that Oracle GoldenGate
needs to reconstruct SQL operations. The SQL Server transaction log does not provide
enough information by default.

Syntax

ADD TRANDATA {[container.]owner.table | schema.table [JOURNAL
library/journal] | library/file [JOURNAL library/journal]}
[NOSCHEDULINGCOLS | ALLCOLS]
[COLS (columns)]
[INCLUDELONG | EXCLUDELONG]
[LOBSNEVER | LOBSALWAYS | LOBSIFCHANGED | LOBSALWAYSNOINDEX]
[NOKEY]
[NOVALIDATE]
[PREPARECSN {WAIT | LOCK | NOWAIT | NONE}]

[container.]owner.table

Valid for DB2 LUW, DB2 for z/OS, Oracle, and SQL Server.

The two-part or three-part name specification. Use a two-part name of owner.table
for all supported databases except an Oracle multitenant container database. Use a
three-part name of container.owner.table for an Oracle multitenant container database.
A wildcard can be used for any component. Used with a wildcard, ADD TRANDATA filters
out names that match the names of system objects. To use ADD TRANDATA for objects that
are not system objects but have names that match those of system objects in a wildcard
pattern, issue ADD TRANDATA for those objects without using a wildcard.

schema.table [JOURNAL library/journal] |

library/file [JOURNAL library/journal]

Valid for DB2 for i.

Specifies the SQL schema and name of a table or the native library and file name.
If a default journal is set with the DEFAULT JOURNAL command, you can omit the JOURNAL
option; otherwise it is required.

NOSCHEDULINGCOLS | ALLCOLS

Valid for Oracle
These options satisfy the logging requirements of an integrated Replicat that will
be processing the tables that you are specifying with ADD TRANDATA. By default, ADD
TRANDATA enables:

NOSCHEDULINGCOLS

Disables the logging of scheduling columns. The primary key, unique keys, and foreign
keys are needed for the dependency computation of the integrated Replicat

ALLCOLS

Enables the unconditional supplemental logging of all of the key and non-key
columns of the table. This option enables the logging of the keys required to
compute dependencies, plus all other columns for use in filtering, conflict
resolution, or other purposes.

COLS (columns)

Valid for all databases supported by ADD TRANDATA.
Use the COLS option to log specific non-key columns. Can be used to log columns
specified in a KEYCOLS clause and to log columns that will be needed for filtering
or manipulation purposes, which might be more efficient than fetching those values
with a FETCHCOLS clause in a TABLE statement. Separate multiple columns with commas,
for example NAME, ID, DOB.

INCLUDELONG | EXCLUDELONG

Valid for DB2 LUW.

Controls whether or not the ALTER TABLE issued by ADD TRANDATA includes the INCLUDE
LONGVAR COLUMNS attribute. INCLUDELONG is the default. When ADD TRANDATA is issued with
this option, Oracle GoldenGate issues the following statement:
ALTER TABLE name DATA CAPTURE CHANGES INCLUDE LONGVAR COLUMNS;
When EXCLUDELONG is used, the following is the command:

ALTER TABLE name DATA CAPTURE CHANGES;

When EXCLUDELONG is used, Oracle GoldenGate does not support functionality that requires
before images of tables that include LONGVAR columns. Examples of this functionality
are the GETUPDATEBEFORES, NOCOMPRESSUPDATES, and NOCOMPRESSDELETES parameters. To
support this functionality, changes to LONGVAR columns in the transaction logs must
include both the before and after images of the column value.

LOBSNEVER | LOBSALWAYS | LOBSIFCHANGED | LOBSALWAYSNOINDEX

Note:
The ADD TRANDATA command will overwrite the LOB setting that is currently set for
the table. To change the setting afterwards, you must use the sp_setrepcol script.

LOBSNEVER

Prevents LOB data from being propagated.
Note this exception: If the LOB column
is inserted with a NULL value, or if it is skipped in an INSERT operation, then
Extract will write that column to the trail with NULL data.

LOBSALWAYS

Does two things: it uses sp_setrepcol to set LOB replication to ALWAYS_REPLICATE
(always replicate LOB data whether or not it has changed in a transaction), and
it marks the table to use an index on replication (by means of the USE_INDEX
of sp_setreptable). Because a LOB is marked for replication in a single transaction,
this can take a long time, and USE_INDEX reduces that time by creating a global
nonclustered index for every LOB. A shared-table lock is held while the global
nonclustered index is created.

LOBSIFCHANGED

Replicates LOB data only if it was changed during a transaction. This reduces
replication overhead but does not protect against inconsistencies that could
occur on the target outside the replication environment. This is the default.

LOBSALWAYSNOINDEX

Sets LOB replication to ALWAYS_REPLICATE (always replicate LOB data whether or not
it has changed in a transaction). This adds overhead, but protects against
inconsistencies that could occur on the target outside the replication environment.
LOBSALWAYSNOINDEX does not mark the table to use an index on replication. The
benefit is that no lock is held while ADD TRANDATA is being executed.

Note:

When using the ALWAYS_REPLICATE option, if a LOB column contains a NULL value, and
then another column in the table gets updated (but not the LOB), that LOB will not
be captured even though ALWAYS_REPLICATE is enabled.
You can check the LOB settings of a table with the INFO TRANDATA command, after ADD
TRANDATA has been used for that table. It shows the LOB settings for all of the LOB
columns.

NOKEY

Valid for all databases supported by ADD TRANDATA.

Suppresses the supplemental logging of primary key columns. If using NOKEY, use the
COLS option to log alternate columns that can serve as keys, and designate those
columns as substitute keys by using the KEYCOLS option of the TABLE or MAP parameter.

NOVALIDATE

Valid for all databases supported by ADD TRANDATA.
Suppresses additional information about the table being handled being processed
by ADD TRANDATA. By default, this option is enabled. The additional information
processing creates a lapse time on command response so this option can be used to
increase response time.

PREPARECSN {WAIT | LOCK | NOWAIT | NONE}

Valid for Oracle for both DML and DDL. Automatically prepares the tables at the source
so the Oracle Datapump Export dump file will includes Instantiation CSNs. Replicat
uses the per table instantiation CSN set by the Oracle Datapump (on import) to filter
out trail records. On the target, the data pump import populates the system tables
and views with instantiation SCNs using the DBOPTIONS ENABLE_INSTANTIATION_FILTERING
parameter to enable table-level instantiation filtering.

WAIT

Wait for any in-flight transactions and prepare table instantiation.

LOCK

Put a lock on the table (to prepare for table instantiation).

NOWAIT

Default behavior, preparing for instantiation is done immediately.

NONE

No instantiation preparation occurs.

Examples

Example 1

The following example causes one of the following: the primary key to be logged
for an Oracle table; supplemental data to be logged for a SQL Server table.

ADD TRANDATA finance.acct

Example 2

The following example enables the unconditional supplemental logging of all of the
key and non-key columns for the table named acct.

ADD TRANDATA acct ALLCOLS

Example 3

The following Oracle example causes the primary key to be logged plus the non-key
columns name and address.

ADD TRANDATA finance.acct, COLS (name, address)

Example 4

The following Oracle example prevents the primary key from being logged, but logs
the non-key columns name and pid instead.

ADD TRANDATA finance.acct, NOKEY, COLS (name, pid)

Example 5

The following example adds logging though does not prepare the table for
instantiation.

ADD TRANDATA acct PREPARECSN NONE

Example 6

The following example suppress additional table information processing.

ADD TRANDATA acct.emp* NOVALIDATE
--------------------------------------------------------------------
DELETE SCHEMATRANDATA

DELETE SCHEMATRANDATA

Use DELETE SCHEMATRANDATA to remove the Oracle schema-level supplemental logging
that was added with the ADD SCHEMATRANDATA command. Use the DBLOGIN command to
establish a database connection before using this command. The user that is
specified with this command must have the privilege to remove supplemental log groups.

By default, this command attempts to remove the supplemental logging of the key
columns that are used by Oracle GoldenGate (can be the primary key, a unique key,
KEYCOLS columns, or all columns) and also the scheduling columns. The scheduling
columns are the primary key, all of the unique keys, and all of the foreign keys.
To delete the logging of the Oracle GoldenGate key columns, but not the scheduling
columns, include the NOSCHEDULINGCOLS option with DELETE SCHEMATRANDATA. If ADD
SCHEMATRANDATA was issued with the ALLCOLS option, use DELETE SCHEMATRANDATA with
the ALLCOLS option to remove the supplemental logging of all of the columns,
including the Oracle GoldenGate key columns.

Syntax

DELETE SCHEMATRANDATA schema [NOSCHEDULINGCOLS | ALLCOLS]

schema

The schema for which you want supplemental logging to be removed. Do not use a
wildcard. If the source is an Oracle multitenant container database, make certain
to log into the pluggable database that contains the schema for which you want
to remove the logging. See DBLOGIN for more information.

NOSCHEDULINGCOLS

Prevents the command from removing the supplemental logging of the scheduling
columns of the tables in the specified schema. The scheduling columns are the
primary key, all of the unique keys, and all of the foreign keys of a table.

ALLCOLS

Removes the supplemental logging of all of the columns of the tables in the
specified schema.

Examples

Example 1

DELETE SCHEMATRANDATA scott

Example 2

DELETE SCHEMATRANDATA scott ALLCOLS
--------------------------------------------------------------------
DELETE TRANDATA

DELETE TRANDATA

Use DELETE TRANDATA to do one of the following:

* DB2 LUW and DB2 on z/OS: Alters the table to DATA CAPTURE NONE.

* Oracle: Disable supplemental logging.

* SQL Server: Stops extended logging for a table.

By default, this command attempts to remove the supplemental logging of the
key columns that are used by Oracle GoldenGate (can be the primary key, a unique
key, KEYCOLS columns, or all columns) and also the scheduling columns. The
scheduling columns are the primary key, all of the unique keys, and all of the
foreign keys. To delete the logging of the Oracle GoldenGate key columns, but
not the scheduling columns, include the NOSCHEDULINGCOLS option with DELETE
TRANDATA. If ADD TRANDATA was issued with the ALLCOLS option, use DELETE TRANDATA
with the ALLCOLS option to remove the supplemental logging of all of the columns,
including the Oracle GoldenGate key columns.
Use the DBLOGIN command to establish a database connection before using this
command. The user specified with this command must have the same privileges
that are required for ADD TRANDATA.

Syntax

DELETE TRANDATA [container.]owner.table [NOSCHEDULINGCOLS | ALLCOLS]

[container.]owner.table

The pluggable database (if this is an Oracle multitenant container database),
owner and name of the table or file. A wildcard can be used for any name
component.

NOSCHEDULINGCOLS

Prevents the command from removing the supplemental logging of the scheduling
columns of the specified table. The scheduling columns are the primary key,
all of the unique keys, and all of the foreign keys of a table.

ALLCOLS

Removes the supplemental logging of all of the columns of the specified table.

Examples

Example 1

DELETE TRANDATA finance.acct

Example 2

DELETE TRANDATA finance.ac*

Example 3

DELETE TRANDATA finance.acct ALLCOLS
--------------------------------------------------------------------
INFO SCHEMATRANDATA

INFO SCHEMATRANDATA

Use INFO SCHEMATRANDATA to determine whether Oracle schema-level supplemental
logging is enabled for the specified schema or if any instantiation information
is available. Use the DBLOGIN command to establish a database connection before
using this command.

Syntax

INFO SCHEMATRANDATA schema

schema

The schema for which you want to confirm supplemental logging. Do not use a wildcard.
To get information on the appropriate schema in an Oracle multitenant container
database, make certain to log into the correct pluggable database with DBLOGIN.

Example

INFO SCHEMATRANDATA scott
--------------------------------------------------------------------
INFO TRANDATA

INFO TRANDATA

Use INFO TRANDATA to get the following information:

* DB2 LUW and DB2 on z/OS: Determine whether DATA CAPTURE is enabled or not.

* Oracle: Determine whether supplemental logging is enabled, and to show the
names of columns that are being logged supplementally. If all columns are being
logged, the notation ALL is displayed instead of individual column names.

Displays any SCN instantiation information.

* SQL Server: Determine whether or not extended logging is enabled for a table.

Use the DBLOGIN command to establish a database connection before using this command.

Syntax

INFO TRANDATA [container.]owner.table

[container.]owner.table

The pluggable database (if this is an Oracle multitenant container database), owner
and name of the table or file for which you want to view trandata information. The
owner is not required if it is the same as the login name that was specified by the
DBLOGIN command. A wildcard can be used for the table name but not the owner name.

NOVALIDATE

Suppresses additional information about the table being handled being processed by
ADD TRANDATA. By default, this option is enabled. The additional information
processing creates a lapse time on command response so this option can be used to
increase response time.

Examples

Example 1

INFO TRANDATA finance.acct

Example 2

INFO TRANDATA finance.ac*

Example 3

INFO TRANDATA finance.ac* NOVALIDATE

####################################
#
#CHECKPOINT TABLE COMMANDS
#
#
####################################
---------------------------------------------------------------------
ADD CHECKPOINTTABLE

Not valid for Replicat for Java, Oracle GoldenGate Applications Adapter, or
Oracle GoldenGate for Big Data.

Use ADD CHECKPOINTTABLE to create a checkpoint table in the target database.
Replicat uses the table to maintain a record of its read position in the trail
for recovery purposes.

The use of a checkpoint table is strongly recommended, because it causes
checkpoints to be part of the Replicat transaction. This allows Replicat to
recover more easily in certain circumstances than when a checkpoint file alone
is used. However, do not use a checkpoint table when configuring Replicat to
operate in integrated mode against an Oracle target database. It is not
required in that mode.

One table can serve as the default checkpoint table for all Replicat groups in
an Oracle GoldenGate instance if you specify it with the CHECKPOINTTABLE parameter
in a GLOBALS file. More than one instance of Oracle GoldenGate (multiple installations)
can use the same checkpoint table. Oracle GoldenGate keeps track of the checkpoints
even when the same Replicat group name exists in different instances.

Use the DBLOGIN command to establish a database connection before using this command.
Do not change the names or attributes of the columns in this table. You may, however,
change table storage attributes.

For more information about using a checkpoint table, see Administering Oracle GoldenGate.

Syntax

ADD CHECKPOINTTABLE [[container. | catalog.]owner.table]

container. | catalog.

The Oracle pluggable database, if applicable. If this option is
omitted, the catalog or pluggable database defaults to the one that is associated with
the SOURCEDB, USERID, or USERIDALIAS portion of the DBLOGIN command (depending on
the database).

owner.table

The owner and name of the checkpoint table to be created. The name cannot contain any
special characters, such as quotes, backslash, dollar sign, and percent symbol. The name
of a MySQL checkpoint table can contain no more than 30 characters.

The owner and name can be omitted if you are using this table as the default checkpoint
table and it is listed with CHECKPOINTTABLE in the GLOBALS file.

It is recommended, but not required, that the table be created in a schema dedicated to
Oracle GoldenGate. If an owner and name are not specified, a default table is created
based on the CHECKPOINTTABLE parameter in the GLOBALS parameter file.

Record the name of the table, because you will need it to view statistics or delete the
table if needed.

Examples

Example 1

The following adds a checkpoint table with the default name specified in the GLOBALS
file.

ADD CHECKPOINTTABLE

Example 2

The following adds a checkpoint table with a user-defined name.

ADD CHECKPOINTTABLE ggs.fin_check

--------------------------------------------------------------------
CLEANUP CHECKPOINTTABLE

CLEANUP CHECKPOINTTABLE

Not valid for Replicat for Java, Oracle GoldenGate Applications Adapter, or Oracle
GoldenGate Big Data.

Use CLEANUP CHECKPOINTTABLE to remove checkpoint records from the checkpoint table
when there is no checkpoint file associated with it in the working Oracle GoldenGate
directory (from which GGSCI was started). The purpose of this command is to remove
checkpoint records that are not needed any more, either because groups were changed
or files were moved.

Use the DBLOGIN command to establish a database connection before using this command.

Syntax

CLEANUP CHECKPOINTTABLE [[container. | catalog.]owner.table]

container. | catalog.

The Oracle pluggable database, if applicable. If this option is omitted, the catalog
or pluggable database defaults to the one that is associated with the SOURCEDB, USERID,
or USERIDALIAS portion of the DBLOGIN command (depending on the database).

owner.table

The owner and name of the checkpoint table to be cleaned up. If an owner and name are
not specified, the table that is affected is the one specified with the CHECKPOINTTABLE
parameter in the GLOBALS parameter file.

Example

CLEANUP CHECKPOINTTABLE ggs.fin_check

--------------------------------------------------------------------
DELETE CHECKPOINTTABLE

DELETE CHECKPOINTTABLE

Not valid for Replicat for Java, Oracle GoldenGate Applications Adapter, or Oracle
GoldenGate Big Data.

Use DELETE CHECKPOINTTABLE to drop a checkpoint table from the database. Use the DBLOGIN
command to establish a database connection before using this command.

To stop using a checkpoint table while the associated Replicat group remains active,
follow these steps:

1. Run GGSCI.

2. Stop Replicat.

STOP REPLICAT group

3. Delete the Replicat group and then add it back with the following commands.

DELETE REPLICAT group
ADD REPLICAT group, EXTTRAIL trail, NODBCHECKPOINT

4. Exit GGSCI, then start it again.

5. Start Replicat again.

START REPLICAT group

6. Log into the database with the DBLOGIN command, using the appropriate authentication
options for the database.

7. Delete the checkpoint table with DELETE CHECKPOINTTABLE.

If the checkpoint table is deleted while Replicat is still running and transactions
are occurring, Replicat will abend with an error that the checkpoint table could not
be found. However, the checkpoints are still maintained on disk in the checkpoint file.
To resume processing, add the checkpoint table back under the same name. Data in the
trail resumes replicating. Then, you can delete the checkpoint table.

Syntax

DELETE CHECKPOINTTABLE [[container. | catalog.]owner.table] [!]

container. | catalog.

The Oracle pluggable database, if applicable. If this option is omitted, the catalog
or pluggable database defaults to the one that is associated with the SOURCEDB, USERID,
or USERIDALIAS portion (depending on the database) of the DBLOGIN command.

owner.table

The owner and name of the checkpoint table to be deleted. An owner and name are not
required if they are the same as those specified with the CHECKPOINTTABLE parameter
in the GLOBALS file.

!
Bypasses the prompt that confirms intent to delete the table.

Example

DELETE CHECKPOINTTABLE ggs.fin_check
--------------------------------------------------------------------
INFO CHECKPOINTTABLE

INFO CHECKPOINTTABLE

Not valid for Replicat for Java, Oracle GoldenGate Applications Adapter, or Oracle
GoldenGate Big Data.

Use INFO CHECKPOINTTABLE to confirm the existence of a checkpoint table and view the
date and time that it was created. It returns a message similar to the following:

Checkpoint table HR.CHKPT_TBLE created 2017-01-06 11:51:53.

Use the DBLOGIN command to establish a database connection before using this command.

Syntax

INFO CHECKPOINTTABLE [[container. | catalog.]owner.table]

container. | catalog.

The Oracle pluggable database, if applicable. If this option is omitted, the catalog or
pluggable database defaults to the one that is associated with the SOURCEDB, USERID,
or USERIDALIAS portion of the DBLOGIN command (depending on the database).

owner.table

The owner and name of the checkpoint table. An owner and name are not required if
they are the same as those specified with the CHECKPOINTTABLE parameter in
the GLOBALS file.

Example

INFO CHECKPOINTTABLE ggs.fin_check
--------------------------------------------------------------------
UPGRADE CHECKPOINTTABLE

UPGRADE CHECKPOINTTABLE

Not valid for Replicat for Java, Oracle GoldenGate Applications Adapter, or Oracle
GoldenGate Big Data.

Use the UPGRADE CHECKPOINTTABLE command to add a supplemental checkpoint table when
upgrading Oracle GoldenGate from version 11.2.1.0.0 or earlier.

Syntax

UPGRADE CHECKPOINTTABLE [[container. | catalog.]owner.table]

container. | catalog.

The Oracle pluggable database, if applicable. If this option is omitted, the catalog or
pluggable database defaults to the one that is associated with the SOURCEDB, USERID, or
USERIDALIAS portion of the DBLOGIN command (depending on the database).

owner.table

The owner and name of the checkpoint table. An owner and name are not required if
they are the same as those specified with the CHECKPOINTTABLE parameter in the
GLOBALS file.

Example

UPGRADE CHECKPOINTTABLE ggs.fin_check

---------------------------------------------------------------------
####################################
#
#ORACLE TRACE TABLE COMMANDS
#
#
####################################
---------------------------------------------------------------------
ADD TRACETABLE

Use ADD TRACETABLE to create a trace table in the Oracle Database. The trace table
must reside in the schema of the Oracle GoldenGate Extract user, as configured with
the USERID or USERIDALIAS parameter. The trace table prevents Replicat transactions
from being extracted again in a bidirectional synchronization configuration.

Use the DBLOGIN command to establish a database connection before using this command.

The trace table has the following description:

Name Null? Type Description
GROUP_ID NOT NULL VARCHAR2(8) The name of the Replicat group or special run process.
DB_USER VARCHAR2(30) The user ID of the Replicat group or special run process.
LAST_UPDATE DATE The timestamp of the transaction.

Syntax

ADD TRACETABLE [[container.]owner.table]

container

The pluggable database, if the database is a multitenant container database (CDB).

owner.table

Optional, use only to specify a trace table with a name that is different from the
default of GGS_TRACE. The owner must be the same owner that is specified with the
USERID or USERIDALIAS parameter in the Extract parameter file.
To use the default name, omit this argument. Whenever possible, use the default table
name. When using a trace table name other than the default of GGS_TRACE, specify it
with the TRACETABLE parameter in the Extract and Replicat parameter files. Record the
name, because you will need it for the parameter files and to view statistics or
delete the table.

Examples

Example 1

The following adds a trace table with the default name of GGS_TRACE.

ADD TRACETABLE

Example 2

The following adds a trace table with a user-defined name of ora_trace.

ADD TRACETABLE ora_trace

--------------------------------------------------------------------
DELETE TRACETABLE

DELETE TRACETABLE

Use DELETE TRACETABLE to delete a trace table. Use the DBLOGIN command to establish
a database connection before using this command.

Syntax

DELETE TRACETABLE [[container.]owner.table]

container

The pluggable database, if the database is a multitenant container database (CDB).

owner.table

The owner and name of the trace table to be deleted. An owner and name are not
required if the owner is the same as that specified with the USERID or USERIDALIAS
parameter and the trace table has the default name of GGS_TRACE.

Example

DELETE TRACETABLE ora_trace
--------------------------------------------------------------------
INFO TRACETABLE

INFO TRACETABLE

Use the INFO TRACETABLE command to verify the existence of the specified trace
table in the local instance of the database. If the table exists, Oracle
GoldenGate displays the name and the date and time that it was created;
otherwise Oracle GoldenGate displays a message stating that the table does
not exist. Use the DBLOGIN command to establish a database connection before
using this command.

Syntax

INFO TRACETABLE [[container.]owner.table]

container

The pluggable database, if the database is a multitenant container database (CDB).

owner.table

The owner and name of the trace table to be verified. An owner and name are
not required if the owner is the same as that specified with the USERID or
USERIDALIAS parameter and the trace table has the default name of GGS_TRACE.

Example

INFO TRACETABLE ora_trace

----------------------------------------------------------------------
####################################
#
#PMSRVR COMMANDS
#
#
####################################

----------------------------------------------------------------------
INFO PMSRVR

Use the INFO PMSRVR command to determine whether or not the Oracle GoldenGate
Performance Metrics Server is running. This command is an alias for STATUS
PMSRVR.

Syntax:
INFO PMSRVR

----------------------------------------------------------------------
START PMSRVR

Use the START PMSRVR command to start the Oracle GoldenGate Performance Metrics
Server process.

Syntax:
START PMSRVR

When PMSRVR is started for the first time, the sequence of commands must be:

START PMSRVR
START MANAGER
START *
START JAGENT

Thereafter, the sequence of commands is not important because the datastore is already
created.

----------------------------------------------------------------------
STATUS PMSRVR

Use the STATUS PMSRVR command to determine whether or not the Oracle
GoldenGate Performance Metrics Server is running. This command is an alias for
INFO PMSRVR.
Syntax:
STATUS PMSRVR

----------------------------------------------------------------------
STOP PMSRVR

Use the STOP PMSRVR command to stop the Oracle GoldenGate Performance Metrics
Server process.

Syntax:
STOP PMSRVR [!]

! (Exclamation point character) Bypasses the prompt that confirms the intent
to stop the Performance Metrics Server.

Examples:

STOP PMSRVR

STOP PMSRVR !

---------------------------------------------------------------------

####################################
#
#JAGENT COMMANDS
#
#
####################################

----------------------------------------------------------------------
INFO JAGENT

Use the INFO JAGENT command to determine whether or not the Oracle GoldenGate Monitor
JAgent is running. This command is an alias for STATUS JAGENT. For more information,
see Administering Oracle GoldenGate Monitor.

Syntax

INFO JAGENT

--------------------------------------------------------------------
START JAGENT

START JAGENT

Use the START JAGENT command to start the Oracle GoldenGate Monitor JAgent process
in a non-clustered environment. In a Windows cluster, start JAgent from the Cluster
Administrator. For more information, see Administering Oracle GoldenGate Monitor.

Syntax

START JAGENT

--------------------------------------------------------------------
STATUS JAGENT

STATUS JAGENT

Use the STATUS JAGENT command to determine whether or not the Oracle GoldenGate
Monitor JAgent is running. This command is an alias for INFO JAGENT. For more
information, see Administering Oracle GoldenGate Monitor.

Syntax

STATUS JAGENT

--------------------------------------------------------------------
STOP JAGENT

STOP JAGENT

Use the STOP JAGENT command to stop the Oracle GoldenGate Monitor JAgent process
in a non-clustered environment. In a Windows cluster, stop JAgent from the Cluster
Administrator. For more information, see Administering Oracle GoldenGate Monitor.

Syntax

STOP JAGENT [ ! ]

!
(Exclamation point character) Bypasses the prompt that confirms the intent to
stop the JAgent.

Examples

Example 1

STOP JAGENT

Example 2

STOP JAGENT !

---------------------------------------------------------------------
####################################
#
#HEARTBEAT TABLE COMMANDS
#
#
####################################
---------------------------------------------------------------------
ADD HEARTBEATTABLE

Use ADD HEARTBEATTABLE to create the objects necessary to use the automatic
heartbeat functionality. This command:

* creates a heartbeat seed table, heartbeat table, and heartbeat history table,

* creates the GG_LAG and GG_LAG_HISTORY views,

* creates the GG_UPDATE_HB_TAB and GG_PURGE_HB_TAB procedures that are called by
the scheduler jobs,

* creates the scheduler jobs that periodically update the heartbeat and seed table,
and purge the history table,

* populates the seed table.

The default seed, heartbeat, and history table names are GG_HEARTBEAT_SEED, GG_HEARTBEAT,
and GG_HEARTBEAT_HISTORY respectively. The tables, procedures, and scheduler jobs are
created in the GGSCHEMA mentioned in GLOBALS file. The default names can be overridden
by specifying HEARTBEATTABLE hbschemaname.hbtablename in the GLOBALS file. In this
case, the tables, procedures, and jobs are created in the schema, hbschemaname. The
seed and history table are created by appending a _SEED and _HISTORY to the table,
hbtablename.

This command requires a DBLOGIN. On a CDB database, a PDB login is required.

For Oracle, the ADD HEARTBEATTABLE has to be performed in every PDB that you want
to generate heartbeats for in CDB mode.

For DB2 LUW, you must set the DB2_ATS_ENABLE property with the db2set
DB2_ATS_ENABLE=yes command.

Syntax

ADD HEARTBEATTABLE
[, FREQUENCY number in seconds]
[, RETENTION_TIME number in days] |
[, PURGE_FREQUENCY number in days]
[, PARTITIONED]
[, NOADDTRANDATA ]
[, TARGETONLY]

FREQUENCY

Specifies how often the heartbeat seed table and heartbeat table are updated.
For example, how frequently heartbeat records are generated. The default is
60 seconds.

RETENTION_TIME

Specifies when heartbeat entries older than the retention time in the history
table are purged. The default is 30 days.

PURGE_FREQUENCY

Specifies how often the purge scheduler is run to delete table entries that
are older than the retention time from the heartbeat history. The default
is 1 day.

PARTITIONED

Enables partitioning in the heartbeat history table with intervals of 1 day.

NOADDTRANDATA

Disables supplemental logging for the heartbeat table and the heartbeat seed table.
By default supplemental logging is enabled for both tables. This options not available
with SQL Server.

TARGETONLY

Disables supplemental logging on both the heartbeat seed and heartbeat tables.
It does not create a scheduler job for updating the heartbeat table.

Examples

Example 1

The following command creates default heartbeat tables, procedures, and jobs.

ADD HEARTBEATTABLE

Example 2

The following command creates the heartbeat tables, procedures, and jobs with
custom frequency, retention time, and purge frequency.

ADD HEARTBEATTABLE, frequency 120, retention_time 10, purge_frequency 2

Example 3

The following command creates the heartbeat tables, procedures and jobs with
partitioning enabled in the heartbeat history table.

ADD HEARTBEATTABLE, partitioned

---------------------------------------------------------------------
ALTER HEARTBEATTABLE

Use ALTER HEARTBEATTABLE to alter existing seed, heartbeat, and history table
options that you set with ADD HEARTBEATTABLE.

This command requires a DBLOGIN. On a CDB database, a PDB login is required.

Syntax

ALTER HEARTBEATTABLE
[FREQUENCY number in seconds]
[RETENTION_TIME number in days] |
[PURGE_FREQUENCY number in days]
[TARGETONLY | NOTARGETONLY]

FREQUENCY

Alter frequency to zero (0) is equivalent to pausing the heartbeat. Heartbeat
records can be resumed by altering frequency to a value greater than 0.

RETENTION_TIME

Changes the heartbeat retention time specified, in days.

PURGE_FREQUENCY

Changes the repeat interval, in days, of the purge heartbeat table.

TARGETONLY | NOTARGETONLY

TARGETONLY modifies the existing heartbeat seed and heartbeat
tables by disabling supplemental logging on both tables. It drops the
existing scheduler job for updating the heartbeat table.

NOTARGETONLY modifies existing heartbeat seed and heartbeat tables by
enabling supplemental logging on both tables. It creates a new scheduler
job for updating the heartbeat table.

Examples

ALTER HEARTBEATTABLE FREQUENCY 60

ALTER HEARTBEATTABLE RETENTION_TIME 30

ALTER HEARTBEATTABLE PURGE_FREQUENCY 1

---------------------------------------------------------------------
DELETE HEARTBEATTABLE

Use DELETE HEARTBEATTABLE to delete tables, procedures, schedulers, and views.
This command requires a DBLOGIN. On a CDB database, a PDB login is required.

Syntax

DELETE HEARTBEATTABLE group_name

group_name

The name of the process to be cleaned.

---------------------------------------------------------------------
DELETE HEARTBEATENTRY

Use DELETE HEARTBEATENTRY to delete the records in the heartbeat table with
the specified process name either in the incoming or outgoing path columns.
This command required a DBLOGIN. On a CDB database, a PDB login is required.

Syntax

DELETE HEARTBEATENTRY group_name

group_name

The name of the process to be cleaned.

---------------------------------------------------------------------
INFO HEARTBEATTABLE

Use INFO HEARTBEATTABLE to display information about the heartbeat tables
and options configured in the database.

This command requires a DBLOGIN. On a CDB database, a PDB login is required.

Syntax

INFO HEARTBEATTABLE

---------------------------------------------------------------------
ADD PROCEDURETRANDATA

Use ADD PROCEDURETRANDATA to add supplemental logging for Procedural Replication.

This command requires a DBLOGIN. On a CDB database, a PDB login is required.

Syntax

ADD PROCEDURETRANDATA

---------------------------------------------------------------------
DELETE PROCEDURETRANDATA

Use DELETE PROCEDURETRANDATA to remove supplemental logging for Procedural Replication.

This command requires a DBLOGIN. On a CDB database, a PDB login is required.

Syntax

DELETE PROCEDURETRANDATA

---------------------------------------------------------------------
INFO PROCEDURETRANDATA

Use INFO PROCEDURETRANDATA to display supplemental logging information about Procedural Replication.

This command requires a DBLOGIN. On a CDB database, a PDB login is required.

Syntax

INFO PROCEDURETRANDATA

---------------------------------------------------------------------
!
Use the ! command to execute a previous GGSCI command without modifications. To
modify a command before executing it again, use the FCcommand (see "FC"). To
display a list of previous commands, use the HISTORY command (see "HISTORY").
The ! command without arguments executes the most recent command. Options enable
you to execute any previous command by specifying its line number or a text
substring. Previous commands can be executed again only if they were issued
during the current session of GGSCI, because command history is not maintained
from session to session.

Syntax
! [n | -n | string]

Executes the command from the specified GGSCI line. Each GGSCI command line
is sequenced, beginning with 1 at the start of the session.
-n

Executes the command issued n lines before the current line.
string

Executes the last command that starts with the specified text string.
Example 1-1 Examples
Example 1
! 9

Example 2
! -3

Example 3
! sta

---------------------------------------------------------------------
ALLOWNESTED | NOALLOWNESTED

Use the ALLOWNESTED and NOALLOWNESTED commands to enable or disable the use of
nested OBEY files. A nested OBEY file is one that contains another OBEY file.

When you exit your GGSCI session, the next GGSCI session will revert back to
NOALLOWNESTED.

Syntax

ALLOWNESTED | NOALLOWNESTED

ALLOWNESTED

Enables the use of nested OBEY files. The maximum number of nested levels is 16.

NOALLOWNESTED

This is the default. An attempt to run a nested OBEY file in the default mode of
NOALLOWNESTED will cause an error that is similar to the following:

ERROR: Nested OBEY scripts not allowed. Use ALLOWNESTED to allow nested scripts.

---------------------------------------------------------------------

####################################
#
#MISCELLANEOUS COMMANDS
#
#
####################################
---------------------------------------------------------------------
!
Executes the previous command without modifications.

Syntax

! [ n ]

---------------------------------------------------------------------
CREATE SUBDIRS

Use CREATE SUBDIRS when installing Oracle GoldenGate. This command creates the
default directories within the Oracle GoldenGate home directory. Use CREATE SUBDIRS
before any other configuration tasks..

Syntax:

CREATE SUBDIRS

---------------------------------------------------------------------
DEFAULTJOURNAL

Use the DEFAULTJOURNAL command to set a default journal for multiple tables
or files for the ADD TRANDATA command when used with a DB2 for i database,
instead of having to use the JOURNAL keyword. Issue this command before issuing
ADD TRANDATA. Any ADD TRANDATA command used without a journal assumes the
journal from DEFAULTJOURNAL. To remove the use of a default journal, use
the CLEAR option. To display the current setting of DEFAULTJOURNAL, you can
issue the command without arguments.

Syntax

DEFAULTJOURNAL [library/journal] [CLEAR]

library/journal

The native name of the journal that you want to use as the default journal
for ADD TRANDATA.

CLEAR

Stops the use of a default journal for ADD TRANDATA.

---------------------------------------------------------------------
FC

Use FC to display edit a previously issued GGSCI command and then execute it
again. Previous commands are stored in the memory buffer and can be displayed
by issuing the HISTORY command (see “HISTORY”).

Displaying Previous Commands

Issuing FC without arguments displays the most recent command. Options enable
you to execute any previous command by specifying its line number or a text
substring.

Previous commands can be edited only if they were issued during the current
GGSCI session, because history is not maintained from one session to another.

Editing Commands

The FC command displays the specified command and then opens an editor with a prompt
containing a blank line starting with two dots. To edit a command, use the space bar
to position the cursor beneath the character in the displayed command where you
want to begin editing, and then use one of the following arguments. Arguments are
not case-sensitive and can be combined:

Argument Description
i text Inserts text. For example:
GGSCI (SysA) 24> fc 9
GGSCI (SysA) 24> send mgr
GGSCI (SysA) 24.. i childstatus
GGSCI (SysA) 24> send mgr childstatus

r text Replaces text. For example:
GGSCI (SysA) 25> fc 9
GGSCI (SysA) 25> info mgr
GGSCI (SysA) 25.. rextract extjd
GGSCI (SysA) 25> info extract extjd

d Deletes a character. To delete multiple characters, enter an d for each d
one. For example:
GGSCI (SysA) 26> fc 10
GGSCI (SysA) 26> info extract extjd, detail
GGSCI (SysA) 26.. dddddddd
GGSCI (SysA) 26> info extract extjd

text Replaces the displayed command with the text that you enter on a one-for-one
basis. For example:
replacement text

GGSCI (SysA) 26> fc 10
GGSCI (SysA) 26> info mgr
GGSCI (SysA) 26.. extract extjd
GGSCI (SysA) 26> info extract extjd

To execute the command, press Enter twice, once to exit the editor and once to issue
the command. To cancel an edit, type a forward slash (/) twice.

Syntax

FC [n | -n | string]

Displays the command from the specified line. Each GGSCI command line is sequenced,
beginning with 1 at the start of the session.

-n

Displays the command that was issued n lines before the current line.

string

Displays the last command that starts with the specified text string.

Examples

Example 1

FC 9

Example 2

FC -3

Example 3

FC sta

---------------------------------------------------------------------
HELP

Use HELP to obtain information about an Oracle GoldenGate command. Without
additional options, HELP returns a list of commands. The command option
restricts the output to the specified command.

Syntax

HELP [command]

command

The command for which you want help.

Example

HELP add replicat

---------------------------------------------------------------------
HISTORY

Use HISTORY to view a list of the most recently issued GGSCI commands since
the startup of the GGSCI session. You can use the ! command or the FC command
to re-execute a command in the list.

Syntax

HISTORY [n]

Returns a specific number of recent commands, where n is any positive number.

Example
HISTORY 7

The result of this command would be similar to:
1: start manager
2: status manager
3: info manager
4: send manager childstatus
5: start extract extjd
6: info extract extjd
7: history

---------------------------------------------------------------------
INFO ALL

Use INFO ALL to display the status and lag (where relevant) for all Manager,
Extract, and Replicat processes on a system. When Oracle Grid Infrastructure
Agents (XAG) Clusterware components are in use, the relevant information is
also displayed. The basic command, without options, displays only online
(continuous) processes. To display tasks, use either INFO ALL TASKS or INFO
ALL ALLPROCESSES.

The Status and Lag at Chkpt(checkpoint) fields display the same process status
and lag as the INFO EXTRACT and INFO REPLICAT commands.

If Replicat is in coordinated mode, INFO ALL shows only the coordinator thread.
To view information about individual threads, use INFO REPLICAT.

Example 1-2 Sample INFO ALL Output
Program Status Group Lag at Chkpt Time Since Chkpt
MANAGER RUNNING
EXTRACT ABENDED EXTCUST 00:00:00 96:56:14
EXTRACT STOPPED INITDL
EXTRACT STOPPED INITDBL

Syntax

INFO ALL [TASKS | ALLPROCESSES]

TASKS

Displays information only for tasks.

ALLPROCESSES

Displays information for online processes and tasks.

Examples

Example 1

INFO ALL TASKS

Example 2

INFO ALL ALLPROCESSES

---------------------------------------------------------------------
INFO MARKER

Use INFO MARKER to review recently processed markers from a NonStop
system. A record is displayed for each occasion on which GGSCI, Logger,
Extract, or Replicat processed the marker.

Markers can only be added on a NonStop system, using Oracle GoldenGate for
NonStop for HP NonStop software.

The following is an example of the output.

Processed Added Diff Prog Group Node
2017-02-16:14:41:15 2017-02-16:14:41:08 00:00:07 Extract PQACMD \QAMD
GROUPCMD REPLICAT RQACMD CLOSEFILES
2017-02-16:14:41:13 2017-02-16:14:41:08 00:00:05 Extract PQACMD \QAMD
TACLCMD REPLICAT RQACMD FUP PURGEDATA $QA16.QAETAR
Where:

* Processed is the local time that a program processed the marker.

* Added is the local time at which the marker was inserted into the NonStop
audit trails or log trails.

* Diff is the time difference between the Processed and Added values. Diff
can serve as an indicator of the lag between the user application and
Extract and Replicat activities.

* Prog shows which process processed the marker, such as GGSCI, Logger,
Extract or Replicat.

* Group shows the Extract or Replicat group or Logger process that processed
the marker. N/A is displayed if GGSCI processed the marker.

* Node shows the node where the marker was inserted into the audit trails.

* There might be an additional column if user-defined text was included in
the ADD MARKER statement.

Syntax

INFO MARKER [COUNT number]
COUNT number

Restricts the list to a specified number of the most recent markers.

---------------------------------------------------------------------
OBEY

Use OBEY to process a file that contains a list of Oracle GoldenGate commands.
OBEY is useful for executing commands that are frequently used in sequence.

You can call one OBEY file from another one. This is called a nested OBEY file.
You can nest up to 16 OBEY files. To use nested OBEY files, you must enable the
functionality by first issuing the ALLOWNESTED command. See “ALLOWNESTED |
NOALLOWNESTED”.

Syntax

OBEY file_name

file_name

The relative or fully qualified path name of the file that contains the list of
commands.

Examples

Example 1

OBEY ./mycommands.txt

The preceding command executes a file that looks similar to the following example:

add extract fin, tranlog, begin now
add exttrail dirdat/aa, extract fin
add extract hr, tranlog, begin now
add exttrail dirdat/bb, extract hr
start extract *
info extract *, detail

Example 2

The following example illustrates a nested OBEY file. Assume an OBEY file named
addcmds.txt. Inside this file, there is another OBEY command that calls the OBEY
file named startcmds.txt, which executes another set of commands.
OBEY ./addcmds.txt

(This OBEY statement executes the following:)

add extract fin, tranlog, begin now add exttrail ggs/dirdat/aa, extract fin add
extract hr, tranlog, begin now add exttrail ggs/dirdat/bb, extract hr add replicat
fin2, exttrail ggs/dirdat/aa, begin now add replicat hr2, exttrail ggs/dirdat/bb,
begin now obey ./startcmds.txt

(The nested startcmds.txt file executes the following:)
start extract *
info extract *, detail
start replicat *
info replicat *, detail

--------------------------------------------------------------------
SHELL

Use SHELL to execute shell commands from within the GGSCI interface.

Syntax

SHELL command

command

The system command to execute.

Examples

Example 1

SHELL dir dirprm/*

Example 2

SHELL rm ./dat*

---------------------------------------------------------------------
SHOW

Use SHOW to display the Oracle GoldenGate environment.

Syntax

SHOW

Example

The following is sample SHOW output. Additional entries may be displayed,
depending on the database type.

Parameter settings:
SET DEBUG OFF
Current directory: C:\GG_81
Using subdirectories for all process files
Editor: notepad
Reports (.rpt) C:\GG_81\dirrpt
Parameters (.prm) C:\GG_81\dirprm
Replicat Checkpoints (.cpr) C:\GG_81\dirchk
Extract Checkpoints (.cpe) C:\GG_81\dirchk
Process Status (.pcs) C:\GG_81\dirpcs
SQL Scripts (.sql) C:\GG_81\dirsql
Database Definitions (.def) C:\GG_81\dirdef

---------------------------------------------------------------------
VERSIONS

Use VERSIONS to display operating system and database version information. For
ODBC connections, the driver version is also displayed. To include database
information in the output, issue a DBLOGIN command before issuing VERSIONS to
establish a database connection.

Syntax

VERSIONS

---------------------------------------------------------------------
VIEW GGSEVT

Use VIEW GGSEVT to view the Oracle GoldenGate error log (ggserr.log file). This
file contains information about Oracle GoldenGate events, such as process
startup, shutdown, and exception conditions. This information is recorded in
the system error log, too, but viewing the Oracle GoldenGate error log sometimes
is more convenient and may retain events further back in time.

The display can be lengthy. To exit the display before reaching the end, use
the operating system's standard methods for terminating screen output.

Syntax

VIEW GGSEVT

Example

The following is sample VIEW GGSEVT output:

2017-01-08 11:20:56 GGS INFO 301 GoldenGate Manager for Oracle,
mgr.prm: Command received from GUI (START GGSCI ).
2017-01-08 11:20:56 GGS INFO 302 GoldenGate Manager for Oracle,
mgr.prm: Manager started GGSCI process on port 7840.
2017-01-08 11:21:31 GGS INFO 301 GoldenGate Manager for Oracle,
mgr.prm: Command received from GUI (START GGSCI ).

---------------------------------------------------------------------
VIEW REPORT

Use VIEW REPORT to view the process report or the discard filet that is
generated by Extract or Replicat. Each process generates a new report and
discard file upon startup.

Reports and discard files are aged whenever a process starts. Old files are
appended with a sequence number, for example finance0.rpt, finance1.rpt, and
so forth, or discard0.dsc, discard1.dsc, and so forth. To view old files, use
the [n] option. To view the current report or discard file, use the command
without the [n] option.

Syntax

VIEW REPORT {group_name[n] | file_name}

group_name

The name of the Extract or Replicat group. The command assumes the report
file named group.rpt or the discard file named group.dscin the Oracle GoldenGate
dirrpt sub-directory.

The number of an old report. Report files are numbered from 0 (the most recent)
to 9 (the oldest).

file_name

The relative file name if stored in the default location, or the full path name
if not stored in the default location.

Examples

Example 1

The following displays an old report file (number 3) for the orders group.

VIEW REPORT orders3

Example 2

The following displays a specific discard file identified by its file name.
Note that the file name has a non-default file extension.

VIEW REPORT dirrpt/orders.rpt