Capturing SQL-Workload with native database functions
For capturing SQL Workloads product specific database functions are used. The capturing process is transparent and only realized with the help of methods provided by the native database utilities. For example, by using the Audit Facility, the Event Monitor for DB2 and Auditing for Oracle databases.
Universal use of Replay function
The workloads recorded on the source database can be replayed on all relational database systems supporting the JDBC driver. Recorded workloads from different database systems can be replayed.
Decoupling the replay function from the source database
Before replaying the prepare step, the SQLReplayer transforms the recorded SQL workload into comma-separated files. These files are used as input for the replay function and can easily be modified before starting the replay. For example the recorded workload can be duplicated for executing load tests by the SQLReplayer.
Optimal monitoring changes by using the Speedgain Performance Monitoring Suite
The Speedgain database performance tools can ideally be used for monitoring the replay of the SQL workload. The replayed SQL statements can be separated for each run comparing the results among each other and against the original workload behaviour. For example, you can answer the question of how a certain SQL statement works under different database configurations. The SQLReplayer can also be used independently of the Speedgain Monitoring tools.
In the current version the SQLReplayer one can capture the SQL workload from DB2 LUW databases. Support for recording and replaying Oracle workloads is already planned. The recorded workload can be repeatedly replayed against all relational database systems. The behaviour of each replay run can be compared on the statement level to each other and against the original results.
Finding the optimal setup
Configuring and tuning a database for optimal performance is the same as tuning a Formula 1 race car for unique race track conditions. In one case one adjusts the engine while the other one modifies the underlying SQL Workoad both having the common objective of high maximum performance.
Simulation of current and planned requirements independent of operation
By applying growth projections upon the current database and server configuration one can determine whether the dimensioning fulfills future size requirements. So for example one can simulate an increasing number of customers and the ability of the infrastructure to support processing windows.
Test and evaluate alternatives
Universal ways for recording and replaying the workload combined with the decoupling from the source database at replay time offer many use case and testing scenarios:
– Comparison of database technologie, e.g. BLU vs non-BLU
– Comparison of parallelism,e.g. MPP vs SMP
– Comparison of OS, e.g. AIX vs Linux
Evaluation of cost-saving database alternatives
The replaying of recorded workloads offers a view of new database results providing a means to estimate the real cost of migrating the SQL statements.
Minimize your risks and save money
The SQLReplayer enables one to test potential new infrastructures using the basis of the real production workload. So prior to investing money into new infrastructure such as server systems, networks, storage, cloud services, etc. one can see actual results. A much safer bet than relying on synthetic performance and load tests.