Oninit® Logwalker — For DBAs
You already know onlog -l. You know it shows addresses, record types, and per-type extras in column-positional form, that the spacing and rendering shift between IDS releases, and that parsing it out of a real-world incident log is half pattern-matching and half folklore. Logwalker gives you the same view in plain-English form — LSN-prefixed, type-named, partnum-resolved to <db>.<table> — and keeps the onlog-compatible 6-column shape one flag away when your scripts need it.
Day-to-day uses
- Forensic record search. A customer ships you a defect report ("the row was there at 10:04 and gone at 10:14"). Walk the relevant uniqid, filter to HDELETE,HUPBEF,HUPAFT, and grep for the partnum or rowid. You get the BEGIN's pid and timestamp, the COMMIT's timestamp, and (with --decode-rows) the actual column values that changed.
- Replication catch-up. When CDC replication falls behind or skips records, walk the source log over the same LSN window the target reports it processed. Logwalker's HUMAN line sits cleanly next to the target's per-row replay so you can correlate by xid + LSN.
- Schema change audit. Filter to BLDCL plus PTEXTEND, CHALLOC, CHFREE, ERASE, PTRUNCATE, TRUNCATE; you get every partition-shape change in the log with the operator's pid, the timestamp, and the target partition name.
- Capacity reasoning. CHALLOC / CHFREE records carry chunk + first_page + n_pages. A short logwalker walk filtered to those types tells you which transactions allocated or freed pages on which chunk — the kind of question that's painful to answer from onstat snapshots after the fact.
Performance and footprint
| Property | Detail |
|---|---|
| I/O pattern | Sequential pread()s of one chunk page at a time against the raw chunk file. No engine bypass — the bytes are the same the engine writes; logwalker just reads them through the OS page cache. |
| Memory | Fixed bounded buffers; the largest is the 1 MiB record-reassembly buffer (matches the ripper's ONI_LOG_MAX_RECORD cap). RSS stays under 30 MiB even with --decode-rows against a 2K-table schema. |
| Startup cost | Phase-1 catalog (systabnames): one sysmaster SELECT, ~2–3 seconds on a 2K-partition instance. Phase-2 column maps (--decode-rows only): one SELECT per accessible database; cost scales with the number of databases, not the row count. |
| Output | Plain text to stdout. Use >, tee, grep, awk, the way you'd treat any structured log line. |
Safety
- O_RDONLY on every open(); pread() on every read.
- No writes to sysmaster (CONNECT only, no BEGIN WORK).
- Pre-flight refusal: sysmaster CONNECT, uniqid resolve, and chunk R_OK all gated before any record is emitted. Diagnostic on stderr names which gate failed and why.
- Catalog snapshot is taken at startup and never refreshed during the walk — reproducibility of a given walk's output is exact.
Operational story
Logwalker has no daemon, no state directory, no on-disk config. Build it from source against your CSDK, drop the binary on the host that owns the log dbspace, and invoke it. You can leave the binary out of $INFORMIXDIR/bin entirely and ship it in /usr/local/bin or wherever the operator-tools live; $INFORMIXDIR isn't on the binary's search path. Backups and HA failovers don't need to know it exists; restart procedures don't need to coordinate with it; an oninit -ky sequence has zero effect on a running logwalker beyond breaking the sysmaster connection at startup (and only at startup).
Backed by Oninit, the team known across the Informix community as "the Down System Specialists". Reach us at support@oninit.com or +1 913 732 8892 (US) / +44 20 8133 7529 (UK).