Solution Overview — For Migration DBAs
You are the person who has to sign off that the target database actually does what the source did. Without tooling, that means hand-checking a sample of queries and hoping the sample was representative. DBReplay gives you the whole captured workload, classified and compared, instead of a sample.
What changes during a migration
| Task | Without DBReplay | With DBReplay |
|---|---|---|
| Know how much SQL actually translates cleanly | Guess, or wait for testers to report failures as they find them. | A coverage report, by distinct statement template and weighted by execution volume, before a single replay runs. |
| Tell a real translation bug from an expected difference | Chase every mismatch by hand. | A closed vocabulary of dispositions (drop, replace, passthrough, expected-difference) applied explicitly, never silently. |
| Prove the target has the same data, not just similar-looking data | Spot-check row counts on a handful of tables. | Per-row, per-column comparison across the full captured workload, reported as matched, mismatched, or excluded — with a reason for every exclusion. |
| Decide what to do with a static SQL package | Manually inspect every package for read/write behaviour. | Read/write classification comes from the captured protocol traffic itself; a package that wrote is flagged as a coverage risk automatically if it's dropped. |
| Hand evidence to the migration sign-off meeting | A verbal account and whatever spreadsheet survived the project. | A signed report: source and target versions, capture integrity, coverage by template and by volume, every mismatch with its cause. |
The coverage number you can trust
DBReplay reports coverage three ways — mapped, explicitly dispositioned, and unhandled — rather than merging the first two into a single flattering percentage. It reports both by distinct statement template and by execution volume, because “99% of templates translate” can still mean the remaining 1% is most of your transaction volume. Unhandled SQL is a hard gate: a statement with neither a mapping nor an explicit disposition stops the run rather than passing through unnoticed.
What you can stop doing
- Hand-writing test queries and hoping they're representative of what production actually sends.
- Chasing down whether a result mismatch is a translation bug, an engine difference, or your own test data being stale.
- Re-running a full test pass from scratch every time the migration rule set changes.
- Explaining, after the fact, why a query that looked fine in testing behaves differently under real concurrency.
DDL and stored procedures in the workload
A procedure that gets created or altered mid-capture and then called is flagged as an error, with the exact position in the stream, so the sound prefix of the run can still be used. Table and index DDL are flagged as warnings with a concrete downstream consequence attached — a new object with no storage mapping, or a plan change that segments the performance comparison at that point — not just a generic “DDL seen” notice.
Next step
Request a scoping call. The first artefact you'll see is a coverage report from your own captured workload against the target engine — before anything is replayed. Email support.info@oninit.com.