Oninit® Logwalker — Why It Matters
When an Informix transaction goes wrong — a corrupted row, an unexplained delete, a partition that disappeared between two backups — the truth lives in the logical log. The log records exactly what happened, in order, with timestamps and operator identity. The problem is reading it. The legacy onlog -l dump is terse, positional, undocumented; it tells you a thing happened but not what.
Oninit® Logwalker is a single command-line tool that opens an Informix logical log file and prints, in plain English, what every record in it means — one line per record, with the canonical LSN, the transaction id, and a typed description: INSERT into mydb.orders (rowid 0x101, 169 bytes), UPDATE before-image on inventory (rowid 0x42a, 200 bytes), BEGIN transaction (pid=2671, started 2026-05-12 14:03:51). With --decode-rows it goes a step further and renders the row image as (col1=val1, col2=val2, …) against your live schema.
What you get
- Plain-English log records. Every type of record the engine writes has a typed human-readable description. No more guessing what column 7 of onlog's output meant on this release.
- Schema-aware row decoding. Point it at your sysmaster, opt into --decode-rows, and HINSERT / HUPAFT / HUPBEF / HDELETE bodies render with your actual column names and values from your actual tables.
- Drop-in onlog replacement. Pass --compat onlog and the output is byte-for-byte compatible with onlog -l's 6-column form — so existing scripts that already parse onlog keep working.
- Transaction grouping. Pass --group-by-xid and every transaction's records are wrapped with explicit BEGIN / COMMIT framing markers, with an (xid REUSED) tag the moment Informix recycles an xid value back into a new transaction.
- Backed by Oninit, the team known across the Informix community as "the Down System Specialists". Built by the same people who designed Oninit® Log Ripper for live CDC capture; Logwalker reuses the Ripper's byte-level reader so the log interpretation is the same in both tools.
Read-only by construction
Every open() uses O_RDONLY. Every read uses pread(). No modifications to any chunk, any $INFORMIXDIR file, any sysmaster table. No write privilege ever requested or used. The binary refuses to start with a [CRITICAL] diagnostic if it can't read every chunk in the resolved extent map — either you can see the whole log, or you don't get a partial walk.
If you have an Informix log file and you need to know what happened in it, this is the shortest path to a clean, readable answer.
Talk to us
Email support@oninit.com or call +1 913 732 8892 (US) / +44 20 8133 7529 (UK) to arrange a copy and a short walkthrough on a non-production instance.