Trail-Files

The previous investigation had an abend and an error code to start from. This one is harder precisely because there isn’t one — Replicat is running, lag is zero, the report file is clean, and yet a nightly reconciliation job is flagging rows where the target’s EMAIL column contains what looks like a phone number. When replication looks completely healthy but the data is wrong, the investigation has to start from the data itself, not from a log. ...

The previous two posts walked through specific investigations. This one is the reference behind them — the Logdump commands worth knowing well, plus the tricks that separate a five-minute trail file check from an hour of scrolling through raw hex. 1. Session Setup: Get Readable Output First The default Logdump view is barely usable — raw hex with minimal structure. Every session should start the same way: Logdump 1 > OPEN ./dirdat/rt000412 Logdump 2 > GHDR ON Logdump 3 > DETAIL DATA Logdump 4 > USETOKEN ON Command What it does Skip it and you get GHDR ON Shows the record header — timestamp, RBA, operation type Records with no context on when/what DETAIL DATA Shows actual column values, decoded Raw hex offsets only DETAIL ON (without DATA) Shows column names/lengths but not values Structure without content — useful when scanning fast USETOKEN ON Decodes GoldenGate’s internal tokens (source DB type, CSN, transaction ID) Tokens print as unreadable hex Trick: if you’re scanning hundreds of records just to find where a table’s activity starts, use DETAIL ON without DATA — it’s faster to read and enough to spot the record you actually want, then flip to DETAIL DATA once you’re near it. ...

GoldenGate replication has three stages, and each one fails differently under load: Extract can fall behind on redo mining, the Pump/Distribution path can saturate the network, and Replicat can bottleneck applying changes to the target. Tuning the wrong stage wastes time and rarely moves the needle — the first job is always figuring out where the lag actually is. 1. Locate the Bottleneck Before Touching Parameters Every tuning exercise starts with LAG and INFO, not with changing parameters blindly. ...

When Replicat abends, the error message tells you what failed, but rarely why. INFO REPLICAT and the report file point you at a table and an error code — to actually understand the data that caused it, you need to open the trail file itself with Logdump, GoldenGate’s trail-file inspection utility. This post walks through a real investigation end to end, from the initial abend to the actual root cause sitting inside the raw record bytes. ...

Oracle GoldenGate is the industry standard for heterogeneous, real-time data replication and change data capture (CDC). Despite being in use for decades, its internal mechanics are frequently misunderstood, leading to poorly tuned deployments that bottleneck at the wrong layer. This article dissects the architecture from the redo log all the way to the target apply. Architecture Overview A GoldenGate pipeline has three logical tiers: Capture — the Extract process mines redo/archive logs on the source database. Distribution — the Data Pump (a secondary Extract) reads local trail files and transmits them to a remote trail on the target host. Apply — the Replicat process reads the remote trail and applies changes to the target database. Each tier operates independently, connected only through trail files — sequential, compressed binary files that serve as a persistent, durable queue between processes. ...