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.

2. Navigation

Logdump 5 > POS 41220118        -- jump directly to a byte offset
Logdump 6 > NEXT                -- read and print the next record (alias: N)
Logdump 7 > NEXT 10              -- print the next 10 records in one go

There’s no native PREV in most Logdump builds — moving backward means re-opening from a known earlier position and reading forward again. This is the single biggest reason to always note the RBA of anything interesting as you go; you cannot casually step back the way you can in a text editor.

Trick: keep a running scratch note of RBAs as you scan (good record: RBA 41150004, first bad record: RBA 41220118). When you need to backtrack, POS straight to the noted value instead of re-scanning from the file start.

3. Filtering to the Table You Care About

Logdump 8 > FILTER TABLE ORDERS.CUSTOMER_PROFILE
Logdump 9 > NEXT

Trail files are almost never single-table — filtering is what makes NEXT useful instead of scrolling through every table’s traffic to find the one row you need.

Logdump 10 > FILTER MATCH ANY ORDERS.CUSTOMER_PROFILE, ORDERS.ORDER_NOTES

Trick: FILTER TABLE is case-sensitive against how the table appears in the trail, which is normally uppercase for Oracle sources. If a filter silently returns nothing, check case before assuming the table isn’t in this trail file at all.

Logdump 11 > FILTER CLEAR         -- remove all filters, go back to seeing everything

4. Counting Without Printing

When you just need volume, not content — e.g. confirming a table has any activity in this file at all before committing to a full scan:

Logdump 12 > FILTER TABLE ORDERS.CUSTOMER_PROFILE
Logdump 13 > COUNT
Scanned 184402 records, 3114 match FILTER criteria

This is dramatically faster than NEXT-ing through manually, and it’s the fastest way to sanity-check “did anything for this table even land in this file” before spending time on a targeted search.

5. Understanding Transaction Boundaries

Every record header includes a TransInd field that most people skim past — it tells you where a record sits inside its transaction, which matters enormously when a multi-statement transaction spans a trail file boundary or when you’re trying to reconstruct exactly what a single commit did:

TransInd value Meaning
. (whole/only) This record is the entire transaction — a single-statement commit
B Begin of a multi-record transaction
M Middle of a multi-record transaction
E End of a multi-record transaction (commit boundary)

Trick: if you’re investigating a specific commit and only find the E record, don’t assume that’s the whole story — POS backward using the transaction’s XID/CSN token to find the B record and everything in between, or you’ll misdiagnose a transaction based on only its last statement.

6. Compressed Updates vs. Full Row Images

Update records don’t always carry every column — GoldenGate can send only the columns that actually changed, which is efficient but easy to misread if you don’t know which mode a pipeline is running in:

Logdump 14 > NEXT

BeforeAfter: A  (after image)
Column     4 (x0004), Len    24   EMAIL : [email protected]

Notice there’s no PHONE or STATUS column in this record at all — not because they’re empty, but because they didn’t change and this Extract is running with compressed updates (the default). If you’re trying to reconstruct a row’s full current state from a single update record, you can’t — you need the last full image plus every compressed delta since.

-- Extract parameter that changes this behaviour
GETUPDATEBEFORES
NOCOMPRESSUPDATES

Trick: if a pipeline was configured with NOCOMPRESSUPDATES, every update record carries the full row, which makes single-record analysis much easier at the cost of trail volume. Check the Extract parameter file before assuming a “missing” column in an update record means bad data — it may just mean unchanged data.

7. Finding a Specific Row Without Knowing the RBA

If you know a business key (an order ID, a customer ID) but not where in the trail it lives, brute-force scanning is painful. A faster approach:

  1. Filter to the table.
  2. Use DETAIL ON (not DATA) and NEXT in large batches to scan quickly.
  3. Once you’re in roughly the right time range (cross-reference against GHDR ON timestamps), switch to DETAIL DATA and scan record-by-record for the key value.
Logdump 15 > FILTER TABLE ORDERS.CUSTOMER_PROFILE
Logdump 16 > DETAIL ON
Logdump 17 > NEXT 500
-- watch header timestamps to bracket the right time range, then:
Logdump 18 > DETAIL DATA
Logdump 19 > NEXT

There’s no indexed lookup by column value in Logdump — trail files are sequential logs, not queryable stores. Narrowing by timestamp first is the practical workaround.

8. Reading the File Header

Before diving into records, the file header itself is worth checking — it tells you which process wrote the file and the SCN/time range it covers, which is the fastest way to confirm you’ve opened the right trail file at all:

Logdump 20 > FILEHEADER ON
Logdump 21 > OPEN ./dirdat/rt000412

Trail File: rt000412
Created by: EXTRACT PMP1
Compatibility: 21.3
First record time: 2026-07-08 00:00:11
Last record time:  2026-07-08 23:59:58

Trick: when investigating an issue near midnight or a trail-file rollover, check adjacent files’ header time ranges before assuming the record you want is in the file you happened to open — it may be one file earlier or later.

9. Non-Interactive / Scripted Logdump

For repeatable checks (support bundles, automated pre-restart validation), Logdump accepts a command script instead of an interactive session:

cat > check_table.dlc <<'EOF'
OPEN ./dirdat/rt000412
GHDR ON
DETAIL DATA
FILTER TABLE ORDERS.CUSTOMER_PROFILE
COUNT
EXIT
EOF

$GG_HOME/logdump check_table.dlc > check_table_output.txt

Trick: this is the basis for building a lightweight automated “does this table have unexpected volume in the last trail file” check without a human opening Logdump interactively every time — pipe the output into grep/awk for alerting.

Quick Reference

Command Purpose
OPEN <file> Load a trail file
GHDR ON Show record headers
DETAIL DATA / DETAIL ON Show full column values / structure only
USETOKEN ON Decode GoldenGate tokens
POS <RBA> Jump to a byte offset
NEXT [n] Read forward one or more records
FILTER TABLE <schema.table> Restrict output to one table
FILTER MATCH ANY <t1>, <t2> Restrict output to a set of tables
FILTER CLEAR Remove active filters
COUNT Count matches without printing them
FILEHEADER ON Show trail file metadata (creator, time range)
EXIT Close Logdump

Summary

Logdump rewards a disciplined habit more than memorised syntax: always turn on headers and detail before scanning, filter to the table you care about immediately, use COUNT before committing to a full manual scan, and track TransInd when a transaction’s story matters as much as any single record. The commands are simple; the skill is knowing which one saves you from reading records you don’t need.