Using LogDump & RBA’s to Reposition a REPLICAT Process

When a REPLICAT process ABEND’s it can be dificult to pinpoint why, and trying to get over the error and allow the REPLICAT to continue can be tricky.

In this example, my source is an Oracle Linux 12c machine running EXTRACT, my target is a Windows Server 2016 machine running MSSQL/REPLICAT.

The Error:

In this example, we are presented with the following errors in the REPLCIAT report after it has ABENDED

2019-08-15 18:21:20  WARNING OGG-03014  Source column COLUMN_NAME has more characters than target column COLUMN_NAME can hold. Some source characters will not be mapped during conversion from source character set UTF-8 to target character set UTF-16.

2019-08-16 09:28:56  ERROR   OGG-01163  Bad column length (357) specified for column COLUMN_NAME in table TABLE.X, maximum allowable length is 255.

From the same report, we need to garner what RBA the fault occured at, you can see this here:

Last log location read:
     FILE:      C:GoldenGatedirdat/1p000003921
     SEQNO:     3921
     RBA:       4982061
     TIMESTAMP: 2019-08-16 09:28:53.053432
     EOF:       NO
     READERR:   0

With this information, open LogDump, prepare the application, and move to your RBA:

Logdump 1 > open C:GoldenGatedirdat/1p000003921 (use your filename here)
Logdump 2 > ghdr on
logdump 3 > detail on
logdump 4 > detail data
logdump 5 > ggstoken on
logdump 6 > ggstoken detail
logdump 7 > pos 4982061 (use your RBA here)

Type “N” and hit enter, for next, and it will display information about the specific statement being executed with the REPLICAT trail file. I’ve shown an example below, but blurred most of the information for infosec reasons. You can see that the description field has a large amount of data in it, so the error seen in the report is likely correct.

At this point, you should evaluate why this has occured, and attempt to overcome the issue. In my case here, this was due to the client owning the source DB increasing the field length of description without consulting me as the OGG Administrator. This caused a difference in the source tables to what was define in the DEFGEN generated table definitions. I show how to fix this in THIS ARTICLE, but let’s just assume for now you want to ignore that, and move on from this error to continue the REPLICAT at a different “safe” RBA.

Hit “N” and enter again to move to the next RBA statement, when you’ve looked at the record and the field data, determined you want to move to this RBA, note the RBA from the first few lines:

2019/08/16 09:28:53.004.584 GGSUnifiedUpdate     Len  1657 RBA 4985338
Name: DATABASE.TABLE_Y  (TDR Index: 1)

Take that RBA back to GGSCI and reposition the REPLICAT as shown below. Start the REPLICAT:

GGSCI (ogg-sv-uat) 12> alter replicat RMSS2001 extrba 4985338

GGSCI (ogg-sv-uat) 12> start replicat RMSS2001

You should now see the REPLICAT has continued fomr the next RBA you chose and will be RUNNING:

GGSCI (ogg-sv-uat) 12> info replicat RMSS2001
 
REPLICAT   RMSS2001  Last Started 2019-08-16 11:33   Status RUNNING
Checkpoint Lag       00:00:00 (updated 00:00:01 ago)
Process ID           41180
Log Read Checkpoint  File C:GoldenGatedirdat/1p000004156
                     2019-08-27 10:56:44.009352  RBA 1134564
 
GGSCI (ogg-sv-uat) 13>