Quantcast
Channel: Oracle DBA – Tips and Techniques
Viewing all articles
Browse latest Browse all 232

Using the FORMAT RELEASE parameter to handle GoldenGate Version Differences

$
0
0
Recently I encountered this error while doing a GoldenGate replication from an Oracle 11g R2 source database to an Oracle 10g R2 target database.

ERROR OGG-01389 File header failed to parse tokens. File /u01/app/goldengate/dirdat/gv000000, last offset 915, data: 0x 
Reading the GoldenGate documentation I came across this section which read:

“A trail or extract file must have a version that is equal to, or lower than, that of the process that reads it. Otherwise the process will abend.” 
The source GoldenGate environment in my case was 11.2.1.0.0 and the target GoldenGate environment was 11.1.1.1

So it looks like the extract file generated by GG version 11.2.1.0 was not compatible with the 11.1.1 replicat process which is reading the trail file.

To overcome this problem we had to use the parameter FORMAT RELEASE in the extract parameter file.

Quoting the documentation  :

FORMAT RELEASE <major>.<minor>
Specifies the metadata format of the data that is sent by Extract to a trail, a file, or (if a remote task) to another process. 
The metadata tells the reader process whether the data records are of a version that it supports. The metadata format depends on the version of the Oracle GoldenGate process.
So we want to change the format of the trail file to the (lower) GoldenGate version of the target environment. 

In the extract parameter file we have to add in this case the line:

rmttrail /u01/app/goldengate/dirdat/yy, format release 11.1

Test Case:

Source GoldenGate environment

./ggsci Oracle GoldenGate Command Interpreter for Oracle Version 11.2.1.0.0 OGGCORE_11.2.1.0.0_PLATFORMS_120131.1910_FBO

Target GoldenGate environment

./ggsci

Oracle GoldenGate Command Interpreter for Oracle
Version 11.1.1.1.2 OGGCORE_11.1.1.1.2_PLATFORMS_111004.2100

Add the Extract 

GGSCI (pdemora061rhv.asgdemo.asggroup.com.au) 4> add extract testext tranlog begin now
EXTRACT added.

GGSCI (pdemora061rhv.asgdemo.asggroup.com.au) 5> add rmttrail /u01/app/goldengate/dirdat/gv extract testext
RMTTRAIL added.

GGSCI (pdemora061rhv.asgdemo.asggroup.com.au) 8> view params testext

extract testext
userid ggs_owner, password ggs_owner
rmthost 10.32.206.62, mgrport 7809
rmttrail /u01/app/goldengate/dirdat/gv
table sh.gavin;

Add the Replicat
GGSCI (pdemora062rhv.asgdemo.asggroup.com.au) 4> add replicat testrep exttrail /u01/app/goldengate/dirdat/gv
REPLICAT added.

GGSCI (pdemora062rhv.asgdemo.asggroup.com.au) 6> edit params testrep

REPLICAT testrep
ASSUMETARGETDEFS
USERID ggs_owner,PASSWORD ggs_owner
MAP SH.GAVIN, TARGET SH.GAVIN;

Now start the Extract and Replicat processes and note the status …. We see that the Replicat process has abended.
GGSCI (pdemora061rhv.asgdemo.asggroup.com.au) 12> info extract testext

EXTRACT    TESTEXT   Last Started 2012-06-21 04:27   Status RUNNING
Checkpoint Lag       00:00:00 (updated 00:00:03 ago)
Log Read Checkpoint  Oracle Redo Logs
                     2012-06-21 04:29:48  Seqno 219, RBA 27456512
                     SCN 0.5335461 (5335461)

GGSCI (pdemora062rhv.asgdemo.asggroup.com.au) 8> info replicat testrep

REPLICAT   TESTREP   Last Started 2012-06-21 04:28   Status ABENDED
Checkpoint Lag       00:00:00 (updated 00:03:27 ago)
Log Read Checkpoint  File /u01/app/goldengate/dirdat/gv000000
                     First Record  RBA 0

This is the error we see in the Replicat report :

2012-06-21 04:28:29 ERROR OGG-01389 File header failed to parse tokens. File /u01/app/goldengate/dirdat/gv000000, last offset 915, data: 0x
Now stop the Extract process and add the FORMAT RELEASE parameter
GGSCI (pdemora061rhv.asgdemo.asggroup.com.au) 13> stop extract testext

Sending STOP request to EXTRACT TESTEXT ...
Request processed.

GGSCI (pdemora061rhv.asgdemo.asggroup.com.au) 14> edit params testext

extract testext
userid ggs_owner, password ggs_owner
rmthost 10.32.206.62, mgrport 7809
rmttrail /u01/app/goldengate/dirdat/gv, format release 11.1
table sh.gavin;

We want the extract to now start writing to a new trail file in the older (11.1) format  compatible with the target GG version. So we use the ETROLLOVER command for this purpose.
GGSCI (pdemora061rhv.asgdemo.asggroup.com.au) 15> alter extract testext, etrollover

2012-06-21 04:32:40  INFO    OGG-01520  Rollover performed.  For each affected output trail of Version 10 or higher format, after starting the source extract,
issue ALTER EXTSEQNO for that trail's reader (either pump EXTRACT or REPLICAT) to move the reader's scan to the new trail file;  it will not happen automatically.
EXTRACT altered.

On the Target side, we want the Replicat process to read the new trail file when it starts up and not the one with the higher 11.2 version it was reading initially when it abended
GGSCI (pdemora062rhv.asgdemo.asggroup.com.au) 7> alter replicat testrep  extseqno 1
REPLICAT altered.

We now start the Replicat process and see that it is running fine and reading the next sequence in the trail file which is gv000001
GGSCI (pdemora062rhv.asgdemo.asggroup.com.au) 8> start replicat testrep

Sending START request to MANAGER ...
REPLICAT TESTREP starting

GGSCI (pdemora062rhv.asgdemo.asggroup.com.au) 9> info replicat testrep

REPLICAT   TESTREP   Last Started 2012-06-21 04:41   Status RUNNING
Checkpoint Lag       00:00:00 (updated 00:00:01 ago)
Log Read Checkpoint  File /u01/app/goldengate/dirdat/gv000001
                     First Record  RBA 1049

Viewing all articles
Browse latest Browse all 232

Trending Articles