Using the GGSCI Command-line Interface

GGSCI is the Oracle GoldenGate command-line interface. You can use GGSCI to issue the
complete range of commands that configure, control, and monitor Oracle GoldenGate.
To start GGSCI, change directories to the Oracle GoldenGate installation directory, and then run
the ggsci executable file.

Using Command History

The execution of multiple commands is made easier with the following tools:
Use the HISTORY command to display a list of previously executed commands.
Use the ! command to execute a previous command again without editing it.
Use the FC command to edit a previous command and then execute it again.

configuring GLOBALS File

The GLOBALS file stores parameters that relate to the Oracle GoldenGate instance as a whole.
This is in contrast to runtime parameters, which are coupled with a specific process such as
Extract. The parameters in the GLOBALS file apply to all processes in the Oracle GoldenGate
instance, but can be overridden by specific process parameters. A GLOBALS parameter file may
or may not be required for your Oracle GoldenGate environment.
When used, a GLOBALS file must exist before starting any Oracle GoldenGate processes,
including GGSCI. The GGSCI program reads the GLOBALS file and passes the parameters to
processes that need them.
To create a GLOBALS file

Use EDIT PARAMS to create or change a parameter file. By default, this

command launches Notepad on Windows systems or the vi editor on UNIX
systems. You can change the editor with the SET EDITOR command.

From the Oracle GoldenGate installation location, run GGSCI and enter the following
command, or open a file in a text editor.
In the file, enter the GLOBALS parameters, one per line.
NOTE The ./ portion of this command must be used, because the GLOBALS file must
reside at the root of the Oracle GoldenGate installation dir

GGSCI (node1) 1> edit params ./GLOBALS

Then enter the following parameter & value

GGSCHEMA ggs_admin

Then save the file & exit

If you used a text editor, save the file as GLOBALS (uppercase, without a file extension) at the
root of the Oracle GoldenGate installation directory. If you created the file correctly in GGSCI,
the file is saved that way automatically. Do not move this file.
Exit GGSCI. You must start from a new GGSCI session before issuing commands or starting
processes that reference the GLOBALS file.

GGSCI (node1) 4> exit

Checkprm utility

This utility can be used to validate a parameter file (.prm).

It is located in the home of the GoldenGate installation.

[oracle@node1 gghome]$ ./ggsci

similarly create GLOBALS on the target also, on the target create a checkpointtable

Oracle GoldenGate Checkpoint Table

When database checkpoints are being used, Oracle GoldenGate creates a checkpoint table with a
user-defined name in the database upon execution of the ADD CHECKPOINTTABLEcommand,
or a user can create the table by using the chkpt_db_create.sql script

[oracle@lnxsrv5 ggsoft]$ ls chkpt*

chkpt_ora_create.sql
[oracle@lnxsrv5 ggsoft]$
There are two tables: the main checkpoint table and an auxiliary checkpoint table that is created
automatically. The auxiliary table, known as the transaction table, bears the name of the primary
checkpoint table appended with _lox. Each Replicat, or each thread of a coordinated Replicat,
uses one row in the checkpoint table to store its progress information.

At checkpoint time, there typically are some number of transactions (among the
total ntransactions) that were applied, and the rest are still in process. For example, if Replicat is
processing a group of n transactions ranging from CSN1 to CSN3. CSN1 is the high watermark
and CSN3 is the low watermark. Any transaction with a CSN higher than the high watermark has
not been processed, and any transaction with a CSN lower than the low watermark has already
been processed. Completed transactions are stored in the LOG_CMPLT_XID column of the
checkpoint table. Any overflow of these transactions is stored in the transaction table (auxiliary
checkpoint table) in the LOG_CMPLT_XID column of that table.

Currently, Replicat (or each Replicat thread of a coordinated Replicat) applies transactions
serially (not in parallel); therefore, the high watermark (the LOG_CSN value in the table) is
always the same as the low watermark (the LOG_CMPLT_CSN value in the table), and there
typically is only one transaction ID in the LOG_CMPLT_XID column. The only exception is
when there are multiple transactions sharing the same CSN.
Do not change the names or attributes of the columns in these tables. You can change table
storage attributes as needed.

Checkpoint table definition

Column Description
GROUP_NAME The name of a Replicat group using this table for
(primary key) checkpoints. There can be multiple Replicat groups using
the same table. This column is part of the primary key.
GROUP_KEY A unique identifier that, together with GROUPNAME,
(primary key) uniquely identifies a checkpoint regardless of how many
Replicat groups are writing to the same table. This column
is part of the primary key.
SEQNO The sequence number of the input trail that Replicat was
reading at the time of the checkpoint.
RBA The relative byte address that Replicat reached in the trail
identified by SEQNO. RBA + SEQNO provide an absolute
position in the trail that identifies the progress of Replicat
at the time of checkpoint.
AUDIT_TS The timestamp of the commit of the source transaction.
CREATE_TS The date and time when the checkpoint table was created.
LAST_UPDATE_TS The date and time when the checkpoint table was last
updated.
CURRENT_DIR The current Oracle GoldenGate home directory or folder.
LOG_CSN Stores the high watermark, or the upper boundary, of the
CSNs. Any transaction with a CSN higher than this value
has not been processed.
LOG_XID Not used. Retained for backward compatibility.
LOG_CMPLT_CSN Stores the low watermark, or the lower boundary, of the
CSNs. Any transaction with a lower CSN than this value
has already been processed.
LOG_CMPLT_XIDS Stores the transactions between the high and low
watermarks that are already applied.
VERSION The version of the checkpoint table format. Enables future
enhancements to be identified as version numbers of the
table.

Transaction table definition

Column Description
GROUP_NAME The name of a Replicat group using this table for
checkpoints. There can be multiple Replicat groups
using the same table. This column is part of the
primary key of the transaction table.
GROUP_KEY A unique identifier that, together
with GROUPNAME, uniquely identifies a
checkpoint regardless of how many Replicat groups
are writing to the same table. This column is part of
the primary key of the transaction table.
LOG_CMPLT_CSN The foreign key that references the checkpoint table.
This column is part of the primary key of the
transaction table.
LOG_CMPLT_XIDS_SEQ Creates unique rows in the event there are so many
overflow transactions that multiple rows are required
to store them all. This column is part of the primary
key of the transaction table.
LOG_CMPLT_XIDS Stores the overflow of transactions between the high
and low watermarks that are already applied.

on the target creating globals file and adding a checkpointtable

GGSCI (lnxsrv5) 1> view params ./GLOBALS

ggschema ggs_admin
syslog none
checkpointtable ggs_admin.checkpoint

GGSCI (lnxsrv5) 2>

GGSCI (lnxsrv5) 2> dblogin userid ggs_admin,password ggs_admin
Successfully logged into database.

GGSCI (lnxsrv5 as ggs_admin@tgtprod) 3> add checkpointtable

No checkpoint table specified. Using GLOBALS specification (ggs_admin.checkpoint)...

Successfully created checkpoint table ggs_admin.checkpoint.

GGSCI (lnxsrv5 as ggs_admin@tgtprod) 4> info checkpointtable

No checkpoint table specified. Using GLOBALS specification (ggs_admin.checkpoint)...

Checkpoint table ggs_admin.checkpoint created 2017-08-26 14:24:30.

GGSCI (lnxsrv5 as ggs_admin@tgtprod) 5>

Storing and Calling Frequently Used Command Sequences

You can automate a frequently-used series of commands by using an OBEY file and
the OBEY command. The OBEY file takes the character set of the local operating system. To
specify a character that is not compatible with that character set, use Unicode notation.

To use OBEY

Create and save a text file that contains the commands, one command per line. This is
your OBEY file. The name can be anything supported by the operating system. You can nest
other OBEY files within an OBEY file.

Run GGSCI.

(Optional) If using an OBEY file that contains nested OBEY files, issue the following command.
This command enables the use of nested OBEY files for the current session of GGSCI and is
required whenever using nested OBEY files.

In GGSCI, call the OBEY file by using the OBEY command.

OBEY file_name

Where:
file_name is the relative or fully qualified name of the OBEY file.

The following example illustrates an OBEY command file for use with the OBEY command. It
creates and starts Extract and Replicat groups and retrieves processing information.
ADD EXTRACT myext, TRANLOG, BEGIN now
START EXTRACT myext

ADD REPLICAT myrep, EXTTRAIL /ggs/dirdat/aa

START REPLICAT myrep

INFO EXTRACT myext, DETAIL

INFO REPLICAT myrep, DETAIL

Command history

GGSCI (lnxsrv5) 4> history

GGSCI Command History

1: obey obe.file
2: start mgr
3: info mgr
4: history

GGSCI (lnxsrv5) 5> !3

info mgr

Manager is running (IP port lnxsrv5.7819, Process ID 3160).

GGSCI (lnxsrv5) 6>