Replicat Abends with OGG-06057 SPLIT_TRANS_RECS changed

Replicat Abends with ERROR OGG-06057 The value of SPLIT_TRANS_RECS was changed after Replicat ABENDED. Previous value: 10000 post GGS Goldengate Deployment Upgrade

How to Safely Restart an Oracle GoldenGate Replicat After ABEND and Clear SPLIT_TRANS_RECS Warning

Managing Oracle GoldenGate (OGG) replication in enterprise environments often involves handling process failures (ABENDs) or parameter mismatches.
Recently, in one of my test environments (rohit-env), the integrated Replicat ROHITGG_REP1 abended and started throwing this message repeatedly:

ERROR – The value of SPLIT_TRANS_RECS was changed after Replicat ABENDED. Previous value: 10000.

Even though the parameter was removed from the parameter file, the warning persisted after each restart.

In this post, I’ll explain why this happens, how to fix it safely, and what each technical term (Sequence, RBA, CSN, Checkpoint, etc.) means so you can clearly understand what’s happening inside GoldenGate.

Understanding the GoldenGate Data Flow

GoldenGate replicates data changes from Source Database → Trail Files → Target Database through a pipeline:

Extract → Trail File(s) → Replicat

• Extract (Capture): Reads committed transactions from the source database redo logs and writes them into trail files.
• Trail Files: Binary files that store change data sequentially (insert/update/delete).
• Replicat (Delivery): Reads from the trail files and applies those changes to the target database.

Both Extract and Replicat track how far they’ve processed using checkpoints.

Key GoldenGate Terms Explained

Let’s break down what each common checkpoint term means when you see it in the Admin Service or INFO command.

1. Sequence Number

• Think of it as a trail file number.
• Each trail file generated by Extract has a sequential number.
• For example:./dirdat/vc4177 ./dirdat/vc4178 & ./dirdat/vc4179

Here, the sequence numbers are 4177, 4178, and 4179. When Extract switches to a new file, the sequence number increases by 1.

Purpose: Helps identify which trail file Replicat should currently read from.

2. RBA (Relative Byte Address) / Offset

• This is the byte position within the trail file that marks exactly where Replicat is reading or Extract is writing.
• Example:Sequence: 4177 Offset (RBA): 542900657

This means Replicat is processing file vc4177 and has successfully applied changes up to byte 542,900,657 in that file.

3. CSN (Commit Sequence Number)

• A database-level marker representing the commit order of a transaction.
• CSNs increase as transactions are committed in the source database.
• In integrated mode, GoldenGate uses the CSN to identify where to begin or stop applying data (especially during instantiation or rebuilds).

Purpose: Ensures transaction order consistency between source and target.
Example message: Instantiation CSN filtering is enabled at CSN 749941222541

4. Checkpoints

A checkpoint is the saved position of a process (Extract or Replicat) showing how far it has successfully read or applied data.

GoldenGate uses different types of checkpoints and its description

Starting The point where the process began when it was first added.

RecoveryThe position from which recovery starts if the process abends.

CurrentThe latest position (Seq + RBA) up to which all transactions have been successfully processed.

BoundedRecoveryBegin/EndInternal markers for where bounded recovery starts and ends (used for fault tolerance).

5. Bounded Recovery

Bounded Recovery (BR) is a transaction recovery mechanism for long-running or large transactions. When a Replicat abends, BR ensures it doesn’t reprocess already committed data.

You’ll often see entries like:

BoundedRecoveryBegin SeqNo: 121179 RBA: 1959523856

BoundedRecoveryEnd SeqNo: 118190 RBA: 620718392

Purpose: Enables fast and reliable recovery after failure — only uncommitted or pending transactions are re-applied.

Why the SPLIT_TRANS_RECS Warning Appears –

When the Replicat abends, GoldenGate saves its last runtime configuration (including parameter values) in checkpoint tables. If you later change or remove a parameter (like SPLIT_TRANS_RECS) and restart, GoldenGate compares the old cached value with the new parameter set.

If they don’t match, you get this warning:

The value of SPLIT_TRANS_RECS was changed after Replicat ABENDED.

Even if the parameter is gone, GoldenGate still “remembers” the old value until a clean checkpoint is written.

Step-by-Step Resolution (with Explanation)

Step 1. Identify the Last Safe Checkpoint

From Admin Service → Extracts → Checkpoints:

Sequence: 4181
Offset: 1694424975


From Admin Service → Replicats → Checkpoints:

Sequence: 4177
Offset: 542900657


Meaning:
The Replicat has successfully applied all changes up to 4177:542900657, and Extract has produced data up to 4181:1694424975.So, restarting from the Replicat’s own last applied point is completely safe.

Step 2. Alter the Replicat Position

In GoldenGate Web Console:

• Go to Replicats → ROHITGG_REP1 → ⋯ (menu) → Alter Checkpoint.
• Select Position in Trail.
• Enter:
• Sequence Number: 4177
• RBA Offset: 542900657
• Click Submit.

This resets the checkpoint pointer and clears stale cached values.

What actually happens internally:
GoldenGate creates a new checkpoint header entry in the checkpoint table.
This overwrites the abended state and reinitializes the runtime metadata.

Step 3. Start the Replicat

Click the Start (▶) button.

You should see logs like:

OGG-02530 Integrated Replicat successfully attached to inbound server OGG$ROHITGG_REP1
OGG-02756 Definition for table SCHEMA.inv_material_txns obtained from the trail file.
OGG-03506 Positioning to trail file ./dirdat/vc4177 at RBA 542900657


Meaning:
The Replicat has attached to the database inbound server and is reading from your specified Seq/RBA — all good.

Step 4. Verify Progress

Go to:

• Replicats → Checkpoint Tab — Sequence and RBA should keep increasing.
• Statistics Tab — Lag will reduce over time.
• Report / Error Log — Ensure no new errors appear.

Once a clean checkpoint is taken, the SPLIT_TRANS_RECS message will no longer show up.

Outcome Summary

Step Result ALTER REPLICAT Clears stale cached valuesReplicat RestartsSafely from last applied record Warning Removed SPLIT_TRANS_RECS mismatch gone Data Preserved, no duplication or loss

Conclusion

In our rohit-env example, the Replicat was safely restarted from its last applied trail position (4177:542900657), and the persistent SPLIT_TRANS_RECS warning disappeared once a clean checkpoint was taken.

By understanding these internal mechanics—especially Sequence, RBA, and Checkpoint—you gain full control of your replication recovery process.

GoldenGate is incredibly resilient when handled correctly.Always restart from the Replicat’s own last applied checkpoint, not the Extract’s latest position, and you’ll never risk data loss or duplication.