Running Oracle OLTP workloads in HP Integrity VM 4.3

8
Workload generator configuration
Swingbench is a workload generator that runs against Oracle databases. Swingbench has an OLTP workload and a
DSS workload. For this set of measurements, the OLTP workload was used as our customers indicated that they are
predominantly interested in running OLTP workloads in their Integrity VM guests.
The Swingbench OLTP workload used in this analysis is called
SOE. It comprises five transactions that are run repeatedly. The
default workload mix used by Swingbench version 2.3 induces
a large amount of row lock contention. While this may be a
valid workload, severe row lock contention is not typical of
most production environments, at least not for extended periods
of time. The SOE workload profile mix was modified in
Swingbench version 2.4 to reduce the row lock contention
inherent in the 2.3 profile. The result is a higher transaction
rate and read/write concurrency. For these reasons the
Swingbench 2.4 workload profile was used for this effort.
The database was populated using Datagenerator (part of the
Swingbench suite). Datagenerator creates a database file of a
specified size and an index file roughly twice the size of the
database. Thus the overall dataset is three times the size of the
database file itself.
For each run, the following Swingbench parameters were used:
• Minimum think time: 1 millisecond
• Maximum think time: 2 millisecond
• Duration of run: 30 minutes
• Oracle AWR snapshots were collected at 10 minutes and 30 minutes during each run. This yields AWR reports
covering 20 minutes of the workload.
Varying the workload characteristics
Most Oracle databases experience different workload characteristics throughout the day, week, and month based on
the number of users attached to the database instance, any batch processing, and so on. Two of the more common
performance variables that change based on workload are the amount of physical disk I/O and the CPU utilization
of the database server. We therefore felt it was important to test different workload characteristics in this benchmark.
This was accomplished by controlling the size of the Oracle dataset and the number of Swingbench users.
The size of the Oracle dataset varied throughout the benchmark effort to test different physical disk I/O levels. A
small dataset requires less physical disk I/O after the dataset is fully populated in the Oracle SGA. A larger dataset
requires more physical disk I/O throughout the run.
Similarly, the number of Swingbench users varied throughout the benchmark effort in order to test different CPU
utilization levels. A small number of users require less CPU resources on the system under test, whereas a large
number of users demand more CPU utilization.