Maintaining Replicat Continuity Using DISCARDFILE and REPERROR —

Background

During large-scale replication projects, it’s common to encounter intermittent GoldenGate Replicat failures caused by table mismatches, structural drift, or metadata latency.
A single DML error on one table can pause the entire data flow — not ideal when uptime and throughput are top priorities.

To avoid this bottleneck while preserving full error visibility, we can configure Replicat to automatically discard bad transactions instead of halting — allowing continuous replication for unaffected objects.

This post describes the method I used in one of my deployments (we’ll call it the RohitDW stack) to achieve stable replication while capturing every failure for later analysis.

Objective

• Keep Replicat alive and processing even when certain tables fail.
• Capture complete failure context (table name, SQL, timestamp, error code) for post-fix validation.
• Avoid silent data loss while maintaining consistent throughput.

Replicat Parameter Block

Here’s the parameter block that forms the foundation of this setup.

-- Define a discard file to capture failed transactions
DISCARDFILE ./dirrpt/GGPROC01.dsc, APPEND, MEGABYTES 2048

-- Continue for all DML errors but write full details to the discard file
REPERROR (DEFAULT, DISCARD)

-- Keep running on DDL issues; log them normally
DDLERROR DEFAULT IGNORE

-- Rotate report files daily and add a heartbeat log every 10K operations
REPORTROLLOVER AT 00:00
REPORTCOUNT EVERY 10000


Sample Outputs

From ggserr.log

2025-10-08 22:59:47 ERROR OGG-01438 Error mapping from RGL_APPDB.ROHITDW_PERSONS


From GGPROC01.dsc

************************************************************
Date: 2025-10-08 22:59:47
Operation: UPDATE
Source Table: RGL_APPDB.ROHITDW_PERSONS
Target Table: RH_ANALYTICSDW.ROHITDW_PERSONS
Error: ORA-01403: no data found
RBA: 00000234.0000000012.00000123
************************************************************


In this setup:

• ggserr.log shows a short summary for quick alerts.
• GGPROC01.dsc stores detailed diagnostic context for re-sync planning.

Using DISCARDFILE in OCI GoldenGate (Managed Service)

For deployments running on GoldenGate Service in OCI (no host access required):

1. Navigate to GG Console → Replicats → Reports tab.
2. Locate the file ending with .dsc — for example, GGPROC01.dsc.
3. Click View or Download to review all failed transactions and tables.
4. Alternatively, connect via AdminClient and run:

VIEW DISCARDFILE GGPROC01

Extracting Failing Tables

Once replication has stabilized, extract the unique list of affected tables for reconciliation:

grep -h "Error mapping from" GGPROC01.dsc
| awk '{for(i=1;i<=NF;i++){if($i=="from"){print $(i+1)}}}'
| sort -u > failed_tables_rohitdw.txt


The resulting file will look like:

RGL_APPDB.ROHITDW_PERSONS
RGL_APPDB.ROHITDW_ASSIGNMENTS
RGL_APPDB.ROHITDW_LOCATIONS


You can use this list to drive re-instantiation or schema validation.

Post-Stabilization Steps

After verifying that replication lag is stable and discard volume has stopped growing:

1. Review all failing tables from failed_tables_rohitdw.txt.
2. Fix column or datatype mismatches, or refresh those tables from source.
3. Stop the Replicat and remove the temporary error-bypass configuration:
   -- Remove these once stable REPERROR (DEFAULT, DISCARD) DDLERROR DEFAULT IGNORE
4. Restart in normal strict-error mode to resume standard behavior.

Why This Works

This pattern ensures:

• Continuous replication during transient mismatches.
• Complete visibility for later cleanup.
• No blind data skips — everything is traceable via the discard file.
• Lightweight overhead — no custom scripts or manual table excludes needed.

Key Takeaways

Benefit Description Resilience Replicat continues despite transient schema drift. Auditability Every failed operation is logged with full SQL context.Progress Visibility REPORTCOUNT provides heartbeat messages confirming forward movement.Easy CleanupThe discard file doubles as your to-do list for future resync.