Troubleshooting
The list below covers the issues operators most commonly raise during the first weeks of an DBVoyeur deployment. None of them require source changes; all of them are configuration or environmental.
Common questions
| Symptom | Likely cause | What to check |
|---|---|---|
| No traffic appearing in the repository | Capture is bound to the wrong interface, or the database is reached over a different IP than configured. | Confirm the database listener address with netstat -an on the DB host; confirm the DBVoyeur capture interface is the one carrying that traffic. |
| Statements captured but no SQL text | The client is using a connection-pool driver that issues prepared statements only once per pool lifetime. | DBVoyeur caches the prepare keyed by the SQL handle. Restart the DBVoyeur capture so it sees the next prepare; from then on every execute is associated with its text. |
| Bind values blanked out | A redaction rule is matching, deliberately or otherwise. | Check the redaction config for the database in question; rules apply by database, schema, table, and column. |
| Response times look implausibly high | The clock on the DBVoyeur host is drifting relative to the database host, or the capture is on a saturated SPAN port. | Confirm NTP is healthy on both hosts; if running on SPAN, check for drop counters on the mirror port. |
| Some sessions are missing | Traffic is taking an unmonitored path — e.g. an additional listener address, or a TLS-terminated path the capture can’t decode. | Confirm all listener addresses are being mirrored; for TLS-terminated traffic, deploy DBVoyeur on the DB host where the traffic is in clear. |
| Repository disk usage growing faster than expected | An application is logging an unusually high statement rate, or detail-tier retention is set longer than intended. | Use the standard top-N report; tune the retention tiers for the noisy application without affecting the others. |
Frequently asked questions
| Question | Answer |
|---|---|
| Does DBVoyeur require any change to my application? | No. The application connects to the database as it always did. DBVoyeur observes the wire. |
| Does it require a database-side agent? | No. There is no extension, no event session, no audit hook, no shared library to install in the database server. |
| What is the production risk? | DBVoyeur is read-only. In the co-resident deployment, the only risk surface is the CPU/RAM footprint of the capture process — bounded, and ~1–2% of one core. In the separate-host deployment the database host is unaffected. |
| Can it see encrypted traffic? | Yes, when deployed on the database host (where the traffic is in clear by the time it reaches the database process). The separate-host deployment requires the mirror to be taken from a point where the traffic is in clear, or a key escrow arrangement. |
| How long does first install take? | Less than a working day for a single database; less than a week for a representative estate of mixed databases. |
| Does it support cloud-managed databases? | Yes for managed instances that expose the wire protocol unchanged (most do). For fully proprietary cloud query services, contact Oninit to confirm coverage. |
| How is it licensed? | Per monitored database instance, with multi-instance and multi-DB-type licensing available. Contact Oninit for current pricing. |
When to call Oninit
If a symptom in the table above is not resolved by the suggested check, or if you are deploying DBVoyeur into an environment with unusual networking (overlay networks, service meshes, multi-homed hosts), call Oninit on +1 913 732 8892 (US) or +44 20 8133 7529 (UK), or email support.info@oninit.com.