Load Testing Dbvisit Replicate

Dbvisit Replicate Load Testing using SwingBench – Database Replication

Clients running high available Oracle databases must be able to minimize the downtime associated to many different critical maintenance tasks such as database upgrades, hardware refreshes, migrations from single instance to RAC, etc.

Database replication solutions come very handy in these situations. They allow a copy of the current (source or production database) and new (destination or new production database) environments to run side by side, keeping both fully synchronized by propagating all the changes from the current environment into the new one.

While choosing a database replication solution to support these types of maintenance operations, three critical technical details need to be considered:

  • Volume of changes to be replicated
  • Data types and type of changes involved
  • Complexity of the replication solution

From a volume of changes perspective, the key point is that the replication solution needs to be able to efficiently capture, propagate and apply all the changes from the current production environment to the new one.

At cutover time, it is critical that both environments are fully synchronized. In this case, all that needs to be done is shutting down the current production environment and pointing clients to the new one. Life goes on with very little downtime required.

If the two environments are not fully synchronized at cutover time, then after the current production environment goes down, the new production environment will only be available when all pending changes are finally applied. Clients will be waiting to be able to connect to the new production environment.

While certifying or testing replication solutions, load generation tools can be used to produce transactions against a source database and test the efficiency of the replication process.

dbvisit logo
  • Dbvisit Replicate Load Testing using SwingBench

    For this simulation we will be using the SwingBench database stressing tool to produce load against a source database which will be captured, propagated and applied to a destination database using Dbvisit Replicate. The source and destination databases are running Oracle and running on Linux.

    The Swingbench database stressing tool provides a couple of out of the box benchmarks. We will be using the Order Entry one which needs to be installed on the source database.

After going through the configuration steps as specified by Dbvisit’s documentation, the MINE process is started on the source database.

And the APPLY process is started on the destination database.

At this point, since there is no load being generated yet, Replicate’s console shows the source and destination databases are fully synchronized.

Using Swingbench’s console, many different aspects of the Order Entry benchmark can be customized.

After configuring the Order Entry benchmark, the simulation can be started. Swingbench’s console shows the different types of loads being executed against the source database.

While the benchmark is being executed, Replicate’s console shows the progress of the MINE and APPLY processes.

After a while, Swingbench’s console shows that the benchmark has been completed.

Ideally, the source and destination databases should be fully synchronized at the time the benchmark is completed. Any lack of synchronization at this point represents database downtime from the end user perspective.

It is important to notice that besides the out of the box benchmarks, Swingbench also accepts the simulation of user-defined transactions which allows for a more realistic prototype.

Our team of experts can help you custom build test cases as well as migrating your databases with near-zero downtime using Dbvisit Replicate.  Please contact us for a no obligation quote today.