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.
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>