Capture Topology
The capture container goes where the packets are, not where the database is. That sounds obvious, and it's the single most common source of a capture that looks healthy and isn't — because the traffic that matters never reached the point someone assumed it would.
The question to ask is where the clients live
A tap or SPAN host in front of the source system works when the traffic genuinely crosses an external, physical wire. It does not work when clients are redirected internally — over an internal switching fabric that a tap in front of the system never sees — because nothing on that path reaches a physical wire at all. An external tap in that situation sees nothing, and gives no indication that anything is missing. The real risk is not which system holds the data, it's whether the traffic is external at all.
Clustered and data-sharing sources
Where the source runs as a data-sharing or clustered group, clients are often redirected to a member-specific address after the initial connection handshake. Capturing only the group's shared address sees handshakes and little else. Capturing a single member gets a weighted, non-random share of the traffic — and more seriously, it can corrupt the concurrency picture the whole comparison relies on: statements that look disjoint in a single-member capture may have been genuinely concurrent with traffic on another member, and that invalidates any ordering-based finding downstream. Nothing in a single-member capture indicates this is happening.
Client-side capture sidesteps the problem entirely — it's member-agnostic by construction. Capturing at every member simultaneously also works, but needs clock synchronisation tighter than most sites run day to day once statement durations get sub-millisecond.
DBReplay's capture-side sanity check reports the members it actually observed from the handshake and compares that against the configured, expected set — and separately flags any configured endpoint that saw zero traffic, since an idle member and a wrong address otherwise look identical.
Client platform matters independently
Where client-side capture is the chosen route — whether because the traffic never reaches an external wire, or because the source is encrypted (see TLS) — the client platform is its own qualifying question, separate from what the source database itself runs on. This route needs a modern Linux kernel and a resolvable TLS library on the client; a client running a different operating system, or one built in a way that hides its own TLS symbols, closes this route regardless of how the source itself is configured.
Two topologies, two different ways of failing
| Wire capture | Client-side capture | |
|---|---|---|
| Failure mode | Loud — drop counters increment, the decoder desyncs, the gap is measurable. | Silent — only sees instrumented processes; an uninstrumented one produces no traffic and no counter, indistinguishable from idle. |
| What establishes coverage | Drop and desync counters are sufficient on their own. | Drop counters alone are not enough — coverage is established by reconciling which processes were actually instrumented against the expected inventory. |
| Timestamp point | At the tap, on the wire. | Before encryption on send, after decryption on receive — a different interval, never mixed with wire timestamps in one comparison. |
Trial capture answers most of this empirically
A plain packet capture — no DBReplay software, no target, nothing to approve beyond the capture request itself — is the first thing every engagement does, and it's worth running before any topology decision is finalised. Where traffic is unencrypted, the same file answers most open questions about the environment directly: whether the capture point actually sees representative volume, which members or paths carry traffic, and whether the decoder handles what's actually on the wire. Pick a busy window for it, not a representative one — a quiet window gives flattering numbers that won't survive the real one.