Oracle Notes

Sharing Oracle technology knowledge and experiences.

Posts Tagged ‘Oracle’

Using Oracle GoldenGate’s Logdump Utility

Posted by sdefilip on August 5, 2010


A recent client had a problem which required the use of the OGG Logdump utility to verify whether a particular table row had been extracted and placed in the Replicat trail file for replication to the target.  In this post, I will outline the steps that were used to find the answer.

1.   Begin logdump session:

            $ logdump

          GoldenGate Log File Dump Utility

          Version Build 001

          Copyright (C) GoldenGate Software, Inc. 1995-2009.

          The GoldenGate software may include other code written by third parties;

          details regarding such third party code, including applicable copyright,

          legal and licensing notices are available at


2.    Open Replicat Trail File


Logdump 1>open ./dirdat/ad000053

Current LogTrail is /shared/oradb/GoldenGate/pnet01d/dirdat/ad000053

Logdump 2 >ghdr on       <–shows record header info about transaction

Logdump 3 >detail data     <— adds  hex and ASCII data values to the

                                                        column information                       

Logdump 4 >next            <—  moves to the first record; advances by one



2010/08/04 21:22:18.134.541 FileHeader           Len   928 RBA 0

Name: *FileHeader*

 3000 01ad 3000 0008 4747 0d0a 544c 0a0d 3100 0002 | 0…0…GG..TL..1…

 0002 3200 0004 ffff fffd 3300 0008 02f1 b33c d650        | ..2…….3……<.P

 840d 3400 0031 002f 7572 693a 7473 7332 6130 3137 | ..4..1./uri:tss2a017

 6e33 3a3a 7368 6172 6564 3a6f 7261 6462 3a47 6f6c  |::shared:oradb:Gol

 6465 6e47 6174 653a 706e 6574 3031 6436 0000 1300 |denGate:anondb02

 112e 2f64 6972 6461 742f 6164 3030 3030 3533 3700 |…/dirdat/ad0000537

 0001 0138 0000 0400 0000 3539 0000 0800 0000 001d | …8……59……..

(above is header data in hex and char)

2010/08/04 22:36:23.000.000 Insert               Len   456 RBA 6608  <–this is

                                                                                                                                an insert

                                                                                                                                 at this rba

Name: FIN_AUDIT.FIN_GL_ATTR      <— source object


Logdump 5>next      <— shows next record which contains continuing header

                                            info; “next’ or ‘n’ also  scans through records in

                                            sequential order


Hdr-Ind    :     E  (x45)     Partition  :     .  (x00)

UndoFlag   :     .  (x00)     BeforeAfter:     A  (x41)

RecLength  :     0  (x0000)   IO Time    : 2010/08/04 21:22:17.611.797

IOType     :   151  (x97)     OrigNode   :     0  (x00)

TransInd   :     .  (x03)     FormatType :     R  (x52)

SyskeyLen  :     0  (x00)     Incomplete :     .  (x00)

AuditRBA   :          0       AuditPos   : 0

Continued  :     N  (x00)     RecCount   :     0  (x00)


2010/08/04 21:22:17.611.797 RestartOK            Len     0 RBA 936


After  Image:                                             Partition 0   G  s


3.    Search for Timestamp in Trail File


Logdump 6 >sfts 2010-08-04       <–searches for the timestamp ‘2010-08-04’

Scan for timestamp >= 2010/08/04 04:00:00.000.000 GMT    <— timestamp


Column    41 (x0029), Len    31 (x001f)       <–column info with data

 0000 3230 3130 2d30 382d 3034 3a32 323a 3336 3a30 | ..2010-08-04:22:36:0

 372e 3839 3333 3139 3030 30                       | 7.893319000RecLength :9 (x0000)   IO Time    : 2010/08/04 21:22:17.611.797

 Since we were looking for any records that were inserted on 2010/08/04, we have found a valid entry in the Replicat trail file that verifies that the record has been placed in the file on the target side by the OGG Collector component.

 A few other of my favorite, very useful  Logdump commands are:

 >filter include filename FIN_AUDIT.FIN_GL_ATTR   

     Which will filter out all records that do not contain the table name

     specified and narrow down the set of records that subsequent commands

     will operate on until a “>filter clear” is issued

>pos FIRST

      Which will go to the first record in the file

 >pos <rba>

       Which will go to a specific rba in the trail file

 >log to <filename>.txt

        Which will log your Logdump session

There are several other useful commands for examining trail files or redo logs.  See the Oracle GoldenGate Troubleshooting Guide  for a complete list.



Posted in Data Integration, Data Warehouse, Golden Gate, Oracle GoldenGate, Oracle Troubleshooting, Replication, Tips | Tagged: , , , , | 1 Comment »

Useful Oracle GoldenGate Troubleshooting Commands

Posted by sdefilip on July 15, 2010

Troubleshooting Commands


If there are any errors, the extract would appear as STOPPED. In this case, you have to investigate the errors.

First, check the report file C:\OGG10G\dirrpt\EMP_EXT.rpt.

Next, see if there are any indicative messages in the log files ggserr.log and sqlnet.log, which are in the main C:\OGG10G directory.

The ggserr.log file contains event information such as:

2009-12-02  14:53:26  GGS INFO        301   Oracle GoldenGate

Manager for Oracle, mgr.prm:  Command received from GGSCI on host (START EXTRACT  EMP_EXT ).

2009-12-02  14:53:26  GGS INFO        302   Oracle GoldenGate Manager for Oracle, mgr.prm:


These events can also be seen in the following way:



2009-12-02 15:09:34  GGS INFO        302  Oracle GoldenGate Manager for Oracle,

mgr.prm:  EXTRACT EMP_EXT starting.

2009-12-02 15:13:26  GGS INFO        399  Oracle GoldenGate Command Interpreter

for Oracle:  GGSCI command (AnonDB): EDIT PARAM emp_ext.

The sqlnet.log file may show errors such as

TNS-12557: TNS:protocol adapter not loadable

This particular error indicates a database connection issue, so you need to explore at the listener level. Make sure the Path includes the Oracle Home bin subdirectory right at the start. There may be other TNS errors that may indicate other solutions.

EMP_EXT.rpt may show an error such as the following:

2009-12-08 13:01:27  GGS ERROR       182  OCI Error beginning

session (status = 28009-ORA-28009: connection as SYS should be as SYSDBA or SYSOPER).

2009-12-08 13:01:27  GGS ERROR       190  PROCESS ABENDING.

This indicates that the Extract process is trying to log on as sys without being the SYSDBA. Simply change the login in the parameter file for the Extract to “system”.

I should note here that specifying SYSDBA at the end of the login line in the Extract parameter file doesn’t work, although it does work with the DBLOGIN command in GGSCI that you will see next.

The ggserr.log file may show similar errors:

2009-12-03 00:43:16  GGS INFO        399  Oracle GoldenGate

Command Interpreter for Oracle:  GGSCI command (AnonDB): start manager.

2009-12-03 00:43:25  GGS ERROR       182  Oracle GoldenGate

Manager for Oracle, mgr.prm:  OCI Error during OCIServerAttach

(status = 12154-ORA-12154: TNS:could not resolve the connect identifier specified).

2009-12-03 00:43:25  GGS ERROR       190  Oracle GoldenGate

Manager for Oracle, mgr.prm:  PROCESS ABENDING.

This indicates an issue with the login credentials supplied in the Manager parameter file, mgr.prm. The Manager has not started as a result.

Another possible error can be seen in the Extract report file. For example, EMP_EXT.rpt can have this error:

2009-12-07 16:40:08  GGS ERROR       190  No minimum supplemental

logging is enabled. This may cause extract process to handle key

update incorrectly if key column is not in first row piece.

2009-12-07 16:40:08  GGS ERROR       190  PROCESS ABENDING.

The solution to this is obviously to enable supplemental logging at the database level. C


The first step is to use the GGSCI command DBLOGIN to connect to the database, so that other commands can be issued that will work on the database.

Note that DBLOGIN works fine as follows:

GGSCI ( AnonDB) 1>

DBLOGIN USERID system@localhost:1521/FIPRD3 PASSWORD fipassword1

Successfully logged into database.

Now you need to add a checkpoint table for the employees table that you are replicating:


Successfully created checkpoint table HR.EMPLOYEES_CHKPT.

Checkpoints that are stored in this table refer to the current read and write positions of the Replicat process. This is used to prevent the loss of data in case the process needs to be restarted, or if there is any fault in the server or a hiccup in the network that would otherwise result in data loss. The other advantage is that multiple Extract or Replicat processes can be read from the same set of trails by using checkpoints.

Checkpoints are optional in the sense that they are not required for Extract and Replicat processes that run in batch mode, because such processes can always be restarted. However, checkpoints are necessary in the case of continuously operating Extract and Replicat processes.. They are normally maintained as files in the dirchk subdirectory, but in the case of Replicat they can optionally be stored in the database in the checkpoint table.

If you specify the checkpoint table in the GLOBALS parameter file, the above command can use that specification. In this scenario, the command could simply be


No checkpoint table specified, using GLOBALS specification (hr.employees_chkpt).

Successfully created checkpoint table HR.EMPLOYEES_CHKPT.

You can now add the Replicat group as follows, specifying the exact same EXTTRAIL that was used by the Extract group set up in the first database. So the Replicat group feeds on or consumes the trail created by the Extract group:

GGSCI (AnonDB) 4> ADD REPLICAT emp_rep, EXTTRAIL C:\OGG10G\dirdat\et, CHECKPOINTTABLE hr.employees_chkpt,


Edit the parameter file for this Replicat group as follows:

GGSCI (AnonDB) 5> EDIT PARAM emp_rep

In the new file, enter the following:

REPLICAT emp_rep

USERID system@localhost:1521/FIPRD3, PASSWORD fipassword1


MAP hr.employees, TARGET hr.employees;

Because the tables have exactly the same DDL structure, you use the ASSUMETARGETDEFS parameter.

Now you can start the Replicat group:

GGSCI (AnonDB) 6> start REPLICAT emp_rep

Sending START request to MANAGER (‘GGSMGR’) …


Wait a few seconds to see the status; if you try immediately, the status may say “stopped.” When you see the status asrunning”, check the detailed information, and also issue an info all command to show all running processes:

GGSCI (AnonDB) 7> status REPLICAT emp_rep


GGSCI (AnonDB) 8> status REPLICAT emp_rep


GGSCI (AnonDB) 11> info REPLICAT emp_rep detail

REPLICAT   EMP_REP   Last Started 2009-12-08 13:35   Status RUNNING

Checkpoint Lag       00:00:00 (updated 00:00:01 ago)

Log Read Checkpoint  File C:\OGG10G\dirdat\et000001

2009-12-08 13:33:24.000000  RBA 985

Extract Source                          Begin             End

C:\OGG10G\dirdat\et000001               2009-12-08 13:33  2009-12-08 13:33

C:\OGG10G\dirdat\et000000               * Initialized *   2009-12-08 13:33

Current directory    C:\OGG10G

Report file          C:\OGG10G\dirrpt\EMP_REP.rpt

Parameter file       C:\OGG10G\dirprm\EMP_REP.prm

Checkpoint file      C:\OGG10G\dirchk\EMP_REP.cpr

Checkpoint table     HR.EMPLOYEES_CHKPT

Process file         C:\OGG10G\dirpcs\EMP_REP.pcr

Error log            C:\OGG10G\ggserr.log

GGSCI (AnonDB) 12> info all

Program     Status      Group       Lag           Time Since Chkpt


EXTRACT     RUNNING     EMP_EXT     00:00:00      00:00:03

REPLICAT    RUNNING     EMP_REP     00:00:00      00:00:06

Posted in Best Practices, CDC, Data Integration, Data Warehouse, Oracle GoldenGate, Oracle Troubleshooting, Tips | Tagged: , , , , | Leave a Comment »