Oninit Logo
The Down System Specialists
+1-913-732-8892
+44-2081-337529
Partnerships Contact

Oninit® Snooper — For the DBA

You already know how this goes. The application team says it's slow. The server stats look fine. onstat -g sql truncates the statement you actually want to see. tcpdump gives you bytes you can't read. Server tracing either isn't on or is so noisy it's useless. Meanwhile somebody's on the bridge waiting for an answer.

oni_snoop is the tool that closes that gap. It's a SQLI-aware passthrough proxy: clients connect to it, it forwards every byte verbatim to the real IDS, and in parallel it decodes every PFPDU in both directions and writes a line-per-PFPDU TSV log.

What you get on a hot incident

SignalWhere it lands in the log
Per-round-trip latency round_us on the closing server-side ONI_EOT. One awk -F'\t' '$5=="ONI_EOT" && $7+0 > 50000' finds every round trip slower than 50 ms.
Per-statement latency stmt_us rolls up the time since the most recent PREPARE / COMMAND. You see which SQL owns the time, not just which exchange does.
Mid-response stalls gap_us on every line. Server-side think-time between TUPLE batches, network pauses, latch waits — all visible without any inference.
The actual SQL the server received sql="..." in the summary column on every PREPARE / COMMAND. No truncation at the IDS-trace boundary.
Decoded result rows v0=42 v1='Alice' v2=30 on each ONI_TUPLE — rendered from a per-connection schema cache populated by every DESCRIBE reply. Covers CHAR / VARCHAR / SMALLINT / INTEGER / SERIAL / INT8 / BIGINT / DATE today.
Errors with full context sqlcode=-201 isam=0 msg="syntax error" on every ONI_ERR / ONI_PUTERR. The exchange that produced it is on the lines immediately above.

What you don't have to set up

  • No sqlhosts edits. Point --listen at the address the client already uses; point --upstream at the real IDS.
  • No onconfig changes. No IDS restart. No client rebuild.
  • No CSDK on the host running the snoop. It's a single statically linked, stripped ~1 MB binary — no libifsql.so, no glibc-version constraints.
  • No application instrumentation. The application doesn't know the snoop is there.

What it deliberately doesn't do

  • It does not modify bytes in either direction. Read-only by construction.
  • It does not inject PFPDUs.
  • It does not block the forwarder on its own decode work — bytes leave the wire before any parsing happens; each connection has its own 256 KiB ring buffer and a dedicated logger pthread.
  • It does not desync. Unknown tokens log one line and resync at the next ONI_EOT.

Output you can already grep

Fixed 10-column TSV, one line per PFPDU. Tabs and newlines inside fields are escaped to \t / \n, so cut -f, awk -F'\t', and Perl -F'\t' all work as-is. No custom parser, no Wireshark plugin, no server trace dump. The schema is the contract; new information lands in the existing summary column or in tagged comment lines.

Drop it on a test environment this week. Email support@oninit.com or call +1 913 732 8892 to get the binary and a short README of the two flags that matter: --listen and --upstream.

The bigger picture

If you really understand what Snooper does, you realize it fundamentally changes how Informix applications can be deployed.

It allows existing Informix applications to run against any database without modification. By decoupling legacy systems from their original data layer, it removes the need for costly rewrites and enables safe, phased modernization. Organizations can preserve proven application logic while moving data and infrastructure forward—reducing risk, cost, and disruption.

To discuss how Oninit ® can assist please call on +1-913-732-8892 or alternatively just send an email specifying your requirements.


You get all this for free.. think about what you get if you pay us