Oninit® DBReplay
Oninit® DBReplay is a database migration proof tool. It takes a passively captured production SQL workload from a source database, replays it against a target database, and produces evidence that the two produced the same results — together with a performance comparison between them.
The source and target do not have to be the same database product, version, operating system, or deployment platform. DBReplay can be used to validate migrations between different versions of the same database engine, between different operating systems or hardware platforms, between traditional bare-metal or virtual-machine deployments and modern containerized environments such as Docker, Kubernetes, or OpenShift, or between entirely different database vendors.
That means it can provide evidence for migrations such as Informix-to-Informix across version or OS changes, Db2 z/OS-to-Db2 LUW, on-premises-to-cloud moves, or cross-vendor migrations such as Db2-to-Informix, Informix-to-PostgreSQL, and other supported source/target combinations.
It exists for one critical moment in a migration: the point where someone has to stand up and say the new system is ready to take production traffic. DBReplay turns that into an evidenced claim instead of a confident guess.
Rather than proving merely that the application starts, that the SQL executes, or that a migration test suite passes, DBReplay asks the more important question:
When presented with the same real production workload, does the target database produce the same observable results as the source — and how does its performance compare?
Built for cross-engine equivalence
Like-for-like replay tools — the same engine on both sides, used to regression-test a patch or a config change — are a mature, solved problem. DBReplay's job starts where those stop: proving that a workload captured against one database engine produces equivalent results on a different one. Db2 for z/OS to Db2 LUW or Amazon RDS is the engagement that drove the current build-out, but the architecture is generic — engine coverage is gated by wire decoders, not by the comparison or reporting layer.
Scope boundaries — stated up front
| What DBReplay does | What it deliberately does not do |
|---|---|
| Works entirely from artefacts your team produces — a capture file and a catalog extract. | Connect to your live source system. There is no live credential, no live query, nothing to approve in a network or firewall review beyond the capture step itself. |
| Proves the captured workload replays on the target and produces the same dataset. | Design the physical target database. That is your DBA or architect's deliverable; DBReplay proves the result once it exists. |
| Proves the workload is equivalent given equivalent stored procedures. | Prove the procedures themselves are equivalent. Their migration is an input to this exercise, not an output of it. |
| Asserts technical soundness — computable, evidenced, in the report. | Render an acceptance verdict. Acceptance is a business decision, and it stays yours. |
How it works
| Stage | What happens |
|---|---|
| Capture | A passive wire (or stream) capture on the source side records the real workload — statements, bind values, timing, session boundaries — without touching the source database as a client. |
| Pre-process | The capture and a catalog extract are classified statement by statement: runs unmodified, translated safely, translated with uncertain semantics, or not yet handled. Nothing unhandled is allowed to run silently. |
| Dialect translation | Statements needing a rewrite for the target engine are converted through a neutral intermediate form, never rewritten "optimal" — only what preserves the proof. |
| Replay | The workload runs against the target, reproducing the source's statement order and concurrency, paced to the captured wall clock. As the same users, from a secret store rather than the capture. |
| Comparison | Every result set is hashed and compared as a multiset against what the source returned. Non-deterministic values are classified and excluded, never silently matched. |
| Report | A signed, provenance-stamped report: what matched, what didn't, why, and how the two engines' performance compared — statement by statement, ranked by the time that actually matters. |
At a glance
| Topic | Detail |
|---|---|
| What it proves | That a migrated workload produces the same results on the target engine, plus how its performance compares. |
| What it needs | A capture artefact and a source catalog extract. Nothing live. |
| Coverage today | Db2 LUW and Db2 z/OS DDF (DRDA); broader engine coverage follows the same wire-decoder pattern. |
| Output | A signed evidence report, plus a live view of the run while it happens. |
| Delivery model | Product with consulting attached, licensed per migration project. |
| Read-only against the source | DBReplay never connects to or modifies the source system. |
Why use it
Migrations fail late and expensively when "it looks fine in testing" turns out to have meant a handful of manually-checked queries against a handful of manually-checked rows. DBReplay replaces that with a statement-by-statement, row-by-row account of the entire captured workload — the evidence a cutover decision should actually rest on.