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 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 11.2.0.3 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.