Are you migrating a key database?

Then you should first measure how this proposed change will impact the performance of your current production workload

When you’re making changes to a business-critical database – whether you’re deploying a version upgrade or a patch, or migrating off the underlying OS or hardware platform – you should first assess the impact this proposed change will have on the performance and stability of your current SQL workload.  This way, you can make an educated go/no-go decision before you actually deploy the change into your business-critical production environment.

While database changes and migrations should generally result in performance and stability improvements (or cost reductions), this is not always the case.  For example, many database upgrades are intended to improve query performance – but what you may find is that while some SQL requests will see improved performance, some actually see a decline.  Similarly, most patches are intended to address stability issues – but while they may fix some problems, they may cause regression errors somewhere else.  And most OS and hardware platform migrations are conducted for modernization and/or cost-reduction reasons – but there is a potential risk of performance and/or stability issues after migration.

These risks are due to the characteristics of *your* specific production workloads.  You may not get the same benefits or performance metrics as what a vendor sees in their lab tests (which are run against generic workloads and simulations).  So it is important to test the proposed change in your lab against your own workloads.  The challenge, however, is: “how do I create a workload that has the scale, the concurrency, and the complexity of my actual production workload?”  Creating a credible test workload is not easy …

With the artificial workloads generated by traditional load simulation tools, there is always a risk that – despite the testing you do – performance and stability issues could arise when you move your change into production ... This is because testing using a workload simulation does not truly reflect what you may see when your actual workloads come into play.  So there is a growing shift towards testing that is real-world ... testing that uses a full-scale replica of what actually happens in your production environment.

This is where iReplay comes in.  iReplay is a next-generation testing tool that records your complete production workload, and then recreates that exact workload in a non-production environment for testing purposes.  This is not a simulation or approximation of the production workload – this is your actual production workload, captured and replayed at full original scale, with all the queries, sessions, timing/pacing, and concurrency.

As a result of testing with iReplay, the risks involved with database upgrades can be minimzed and the impact of proposed migrations can be assessed more quickly and accurately.


Learn more about iReplay at 


Contact us at