Shared memory
Not every database connection travels over a network. On Informix, a client running on the database server itself can connect through shared memory — the client and the engine exchange requests through a memory segment they both attach to, rather than through a socket. It is the fastest way to connect, and it is common for local applications, batch jobs and scheduled work.
Why other monitoring does not see it
A shared-memory connection never produces a packet. Nothing enters the network stack, nothing crosses an interface, and nothing reaches a switch. Any product that monitors databases by capturing network traffic — including DBVoyeur's own network capture — therefore sees nothing at all from these connections.
The consequence is worth stating plainly, because it is easy to miss: this traffic is not partially captured or captured with less detail. It is absent, and nothing in a report indicates that anything is missing. An estate can run substantial local workload — overnight batch, maintenance jobs, local application servers — and see none of it in a network-based monitor while everything appears healthy.
How DBVoyeur captures it
DBVoyeur reads the statement inside the client process, at the moment the client hands it over to the database. At that instant the SQL exists as ordinary text in the client's own memory, before any transport is involved.
This is a read-only observation, using standard Linux kernel tracing. Nothing is modified: the application is not altered, recompiled, restarted or reconfigured, no library is substituted, and no proxy is introduced. The client continues to talk to the engine exactly as before, and neither end behaves differently because neither are aware that DBVoyeur is watching. The passive model that applies to network capture applies here too — the observation simply happens somewhere else.
Captured shared-memory activity appears alongside network activity in the same reports, identified as its own connection so you can tell at a glance which statements arrived which way.
What it requires
| Requirement | Why |
|---|---|
| DBVoyeur runs on the database host | The traffic exists only inside that machine, which is one of the reasons capture runs there. A network-only capture point could not see shared-memory connections at all — see operations. |
| Linux | The capture uses kernel facilities available on current Linux distributions. |
| Enabled deliberately | Shared-memory capture is a separate capability, switched on when you want it. With it off, DBVoyeur behaves exactly as a network monitor and nothing observes the database host's processes. |
What is captured, and what is not
Shared-memory capture works statement by statement rather than connection by connection. That distinction matters, and it works in your favour: DBVoyeur does not need to have seen a session start in order to report it. Sessions that were already running when capture starts are captured normally, including long-lived batch jobs and application connections. This is the opposite of network capture, where a connection that was already open when the agent started cannot be interpreted — see operations. Short-lived local connections are captured for the same reason: each statement stands on its own.
The limits are of a different kind, and it is worth being plain about them.
| Limit | What it means in practice |
|---|---|
| Coverage is per client program | The most important one. DBVoyeur observes shared-memory activity inside specific, configured client executables. A local program that is not covered is not captured at all, however long it runs or however much work it does. Extending coverage to an additional client program is a configuration step, not a code change — but it is a step somebody has to take. |
| A statement is recorded when its result returns | A statement that never completes — the client is killed mid-query, or the session is cancelled — is not reported. Completed work is unaffected. |
| Very large statements are shortened | Statement text beyond a generous limit is truncated for transport. The statement is still reported; only the tail of the text is lost. |
| Extreme bursts | Under sustained bursts far above normal rates a small number of events can be dropped rather than queued indefinitely. DBVoyeur sheds rather than blocks, and never slows the application down. |
| User attribution on pre-existing sessions | The user name is learned when a session logs in. For a session that was already connected before capture started, statements are still captured but may be attributed to the connecting account rather than the end user. |
None of these are peculiar to shared memory; they apply to any capture that reads inside the client process. They are stated here because shared memory is the case where that capture method is the only option — there is no packet to fall back on.
Short-lived and very fast sessions
A common concern is whether brief local work — a script that connects, runs a single statement and exits in a fraction of a second — is quick enough to slip past. It is not. Because capture is per statement rather than per connection, instrumentation applies to a client program from its first instruction, so a session that lives for a tenth of a second is captured in full, as are rapid statements issued back to back within one session. There is no warm-up period and no minimum session duration.
The caveat is about which programs, not about how fast they are. Speed is not the limiting factor here; coverage is. A short-lived session of a client program that DBVoyeur is configured to observe is captured; a long-running session of a program it is not configured to observe is not captured at all. When reviewing shared-memory coverage, the question worth asking is “which local programs are included?” rather than “are the quick ones being missed?”
A word of advice that has nothing to do with monitoring: if you find a lot of very short-lived sessions in these reports, that is usually worth acting on in its own right. Establishing a database connection is expensive relative to the work most short sessions perform — the engine allocates session structures, authenticates, sets up the session environment and then tears it all down again, often to run a single statement. A workload that connects, issues one statement and disconnects can spend considerably more effort on the connection than on the query. Persistent connections or a connection pool are almost always the better pattern for repeated local work; reserve connect-per-task for genuinely occasional jobs. DBVoyeur will happily report either, but seeing thousands of one-statement sessions is generally a finding, not a monitoring artefact.
One further limit, stated for completeness: at sustained rates far above normal production — many thousands of statements per second from local clients on a single host — DBVoyeur sheds events rather than queueing them without bound or slowing the application. Ordinary bursts are captured intact; an extreme, sustained flood may be sampled rather than complete.
The alternative: move local clients to TCP
There is a simpler option, and for many sites it is the better one. If local applications connect over TCP instead of shared memory — to the ordinary listener, over the loopback interface — their traffic becomes visible to standard network capture with no additional capability required.
The trade-off is performance: shared memory avoids the network stack entirely, so it is faster, and applications that issue many small statements will notice the difference. Against that, network capture is simpler to deploy and reason about. Which way to go depends on how chatty your local workload is and on how much you value the simpler deployment; Oninit will help you weigh it for your estate rather than pushing a single answer.
A note on Java
Java applications are unaffected by any of this. The Informix JDBC driver is a pure-Java implementation that connects over the network, so Java clients cannot use shared memory even when running on the database server. Their traffic is captured by DBVoyeur's ordinary network capture like any other network client.