Deployment

Background

A live production database server will typically receive concurrent SQL traffic from several application servers, each of which may exist in a number of permutations of client libraries and versions, along with a varying & unpredictable component of ad hoc traffic from tools such as Toad, iSQL, and Microsoft Excel – again in rapidly multiplying permutations.

Efforts to duplicate this level of complexity in a lab environment usually fall short.

Either the lab team must re-create all of the permutations of client libraries, or it will strip out this very significant complexity for the sake of convenience, creating something that is easy to implement, but – in the manner of high-school science problems – sufficiently divorced from reality to call into question any subsequent findings (“Assume a spherical cow of uniform density…”).

iReplay solves this problem by intelligently re-processing raw network traffic, allowing a single iReplay server to accurately reproduce the complexity and concurrency of your original SQL load, just as if it had originated from your original mix of applications and client libraries.

In this installation, a capture process runs on the source database host, and the iReplay server on a dedicated Linux host. iPut runs in the background to transfer captured data to the iReplay Server, avoiding heavy disk use on the source host.

This means that there is no need to duplicate application servers or client libraries in your lab environment; you need only duplicate the database instance itself, and bring it into the same state as existed at the start of the capture process.

In addition to a test version of your database server, you will need the iReplay software components as outlined in the tables below & above right.