Oracle Performance Benchmarking with HammerDB

Benchmarking is essential for assessing the performance and scalability of Oracle databases, particularly when simulating real-world transaction-heavy workloads. Whether you are planning a cloud migration, comparing infrastructure options, or validating a configuration change, benchmarks provide the quantitative evidence needed to make informed decisions.

This guide covers the fundamentals of Oracle benchmarking, compares the major tools available, and provides a step-by-step walkthrough for running the TPROC-C (TPC-C) benchmark using HammerDB on Tessell for Oracle. It also covers benchmark metrics, best practices, and multi-cloud benchmarking considerations for 2026.

What Is Oracle Database Benchmarking?

Oracle database benchmarking is the process of running standardized workloads against an Oracle database instance to measure performance under controlled conditions. Key metrics include transactions per second (TPS), new orders per minute (NOPM), I/O operations per second (IOPS), query latency, and throughput. These metrics allow DBAs and cloud architects to evaluate hardware, storage, network, and configuration choices objectively.

Organizations benchmark Oracle databases for several reasons. During cloud migrations, benchmarks establish baselines on the source environment and validate that target environments deliver comparable or better performance. For capacity planning, benchmarks reveal the point at which a given configuration starts to degrade under load. Benchmarks also support FinOps optimization by comparing cost-per-transaction across cloud providers and instance types, helping teams identify the most cost-effective infrastructure for their workload profile.

Oracle Benchmark Tools: HammerDB vs SLOB vs Swingbench

Several tools exist for benchmarking Oracle databases, each designed for different workload types. The three most widely used are HammerDB, SLOB, and Swingbench. Understanding their differences is critical for selecting the right tool for your testing objective.

HammerDB (TPROC-C / TPROC-H)

HammerDB is an open-source, multi-database benchmarking tool hosted by the Transaction Processing Performance Council (TPC). It implements TPROC-C (derived from TPC-C for OLTP workloads) and TPROC-H (derived from TPC-H for analytical workloads). HammerDB supports Oracle, PostgreSQL, SQL Server, MySQL, and MariaDB, making NOPM (New Orders Per Minute) a cross-database comparable metric. HammerDB v5.0 introduced improved time-based profiling and enhanced CLI automation. It is the recommended tool for transaction throughput benchmarking.

SLOB (Silly Little Oracle Benchmark)

SLOB is an Oracle-specific tool created by Kevin Closson, designed for I/O and storage performance testing. Unlike HammerDB, SLOB is non-transactional and generates pure I/O workloads that isolate storage layer performance from application-level overhead. It is ideal for evaluating NVMe, flash storage, and cloud block storage performance. Tessell has published SLOB benchmark results comparing NVMe-backed storage performance across cloud providers.

Swingbench

Swingbench is a free, Java-based, Oracle-specific load generator created by Dominic Giles (Oracle). It supports Order Entry (OLTP), Sales History (DSS), and JSON workloads. Swingbench is particularly useful for Oracle RAC testing and multi-schema concurrent load generation. The April 2025 release added JSON-based result storage. Swingbench is not officially supported by Oracle but is widely used within the Oracle community.

Tool Comparison

For transaction processing benchmarks that simulate real-world OLTP workloads, HammerDB is the recommended choice. The remainder of this guide focuses on running HammerDB TPROC-C benchmarks against Oracle.

What Is the TPC-C (TPROC-C) Benchmark?

TPC-C is a standard OLTP benchmark that simulates order processing across multiple warehouses, measuring transaction throughput and latency. It was defined by the Transaction Processing Performance Council (TPC) and is the industry standard for evaluating database transaction processing capability.

HammerDB implements an open-source derivative called TPROC-C (Transaction Processing over C). TPROC-C follows the same workload model as TPC-C but is not an officially audited TPC benchmark. This distinction matters: TPC-C results require formal auditing and cannot be directly compared with TPROC-C results. However, TPROC-C provides a reliable, repeatable, and free method for comparative benchmarking across environments.

The benchmark simulates five transaction types: New Order, Payment, Order Status, Delivery, and Stock Level. It uses a configurable number of warehouses to scale the dataset and concurrent virtual users to simulate load. The primary metric is NOPM (New Orders Per Minute), which counts completed New Order transactions and is comparable across database engines. TPM (Transactions Per Minute) is the database-specific metric that includes all transaction types plus system overhead.

Why Benchmark Your Oracle Database?

Benchmarking serves multiple purposes across the database lifecycle. Before a cloud migration, benchmarks establish a performance baseline on the source environment. Running the same benchmark on the target environment provides a direct, quantifiable comparison that de-risks the migration decision. This is especially valuable when moving from on-premises infrastructure to cloud-based DBaaS platforms, where storage and network characteristics differ significantly.

For capacity planning, benchmarks reveal how performance degrades as concurrency increases. By scaling virtual users and warehouse counts, teams can identify the inflection point where their current configuration becomes insufficient and proactively add resources before end users experience latency.

Benchmarks also support FinOps and cost optimization. Running identical workloads across different cloud providers or instance types produces cost-per-transaction comparisons that inform infrastructure purchasing decisions. This is particularly relevant for organizations evaluating Oracle on AWS, Azure, GCP, and OCI, where instance pricing, storage tiers, and network costs vary significantly.

Additionally, benchmarks validate the impact of configuration changes, patches, operating system upgrades, and Oracle version upgrades. Running a benchmark before and after a change provides objective evidence of performance improvement or regression.

Understanding Oracle Benchmark Metrics

Before running benchmarks, it is important to understand the key metrics and what they measure.

• NOPM (New Orders Per Minute): The primary cross-database comparable metric in HammerDB. Counts completed New Order transactions per minute. Use NOPM when comparing Oracle vs PostgreSQL vs SQL Server performance.

• TPM (Transactions Per Minute): Database-specific metric that includes all five transaction types plus system-level overhead. Always higher than NOPM. Use TPM for Oracle-to-Oracle comparisons only.

• TPS (Transactions Per Second): TPM divided by 60. Often used in reporting for easier readability.

• Latency (Response Time): Time taken to complete a single transaction, typically measured in milliseconds. Lower is better. Critical for user-facing applications.

• IOPS (I/O Operations Per Second): Measures storage layer throughput. Relevant for SLOB and storage-level benchmarks. Tessell NVMe infrastructure supports up to 2M IOPS.

• AWR Reports: Oracle Automatic Workload Repository reports capture database-level performance data, including wait events, SQL statistics, and resource consumption. Take AWR snapshots before and after benchmark runs for comprehensive analysis.

How to Benchmark Oracle with HammerDB: Step-by-Step Guide

This section walks through the complete process for running a TPROC-C benchmark against an Oracle database using HammerDB. The instructions reference Tessell for Oracle on GCP, but the same process applies on AWS and Azure with Tessell.

Prerequisites and Environment Setup

To run an accurate benchmark, the HammerDB load driver must be installed on a separate machine in the same VPC and subnet as the Oracle database instance. This eliminates network latency as a variable. The recommended setup uses a GCE Windows VM in the same VPC as the Tessell for Oracle instance.

Provision a Windows Server VM with sufficient CPU and memory to drive the benchmark load (minimum 8 vCPUs, 32 GB RAM for production-scale tests). Ensure network connectivity between the VM and the Oracle listener port (default 1521). With Tessell, the Oracle database itself is provisioned in minutes through the Tessell console, eliminating the manual configuration required for self-managed Oracle on cloud VMs.

Install HammerDB and Oracle Instant Client

Download and install HammerDB from hammerdb.com. For Windows, use the MSI installer. For Linux, the Docker-based HammerDB CloudTK image provides a pre-configured environment that avoids manual dependency management.

Install the Oracle Instant Client matching your Oracle database version. Configure the PATH and TNS_ADMIN environment variables to point to the Instant Client directory. Verify connectivity using tnsping before proceeding to HammerDB configuration.

Connect HammerDB to Oracle Database

In the HammerDB interface, navigate to the Database section and select Oracle from the dropdown. In the Schema Settings, provide the connection details: hostname (Tessell Oracle endpoint), port (1521), service name, and credentials. HammerDB uses a tpcc schema by default for its test data. Ensure this schema user exists and has the necessary privileges before proceeding.

Troubleshooting tips: If the connection fails, verify the listener is running (lsnrctl status), check firewall rules for port 1521, and confirm the service name matches the database configuration. Use tnsping to validate TNS resolution independently.

Configure and Run the TPROC-C Benchmark

Under the Settings tab, configure the workload parameters. Set the number of warehouses (10 for quick validation tests, 100 or more for production-scale loads). Set the virtual users for schema build to match the CPU core count on the benchmark driver machine.

Build the schema first: click Build under the Schema section. This executes DDL statements and loads test data into the tpcc schema. Wait for the schema build to complete before proceeding.

Configure the benchmark driver: select the Timed Driver Script option for production benchmarks (as opposed to the Test driver, which runs a fixed number of transactions). Set the test duration to a minimum of 15 to 20 minutes per HammerDB documentation. Configure the ramp-up period (typically 2 to 5 minutes) to allow the database to reach steady state before measurements begin.

Start the benchmark and monitor the Transaction Counter for real-time NOPM and TPM values. Allow the full test duration to elapse before reviewing results.

Interpreting Benchmark Results

After the benchmark completes, HammerDB reports NOPM and TPM values. Focus on NOPM for cross-database comparisons and TPM for Oracle-specific analysis. A higher NOPM indicates better transaction throughput.

To evaluate results effectively, run a minimum of three iterations and average the results. Discard the first run if it shows significantly different values (cold cache effects). Compare results across different configurations by changing one variable at a time: instance type, storage tier, warehouse count, or virtual user count.

For deeper analysis, use Oracle AWR reports. Take an AWR snapshot immediately before and after the benchmark run. The AWR diff report highlights top wait events, SQL execution statistics, and I/O patterns that explain the observed throughput numbers. AWR is the gold standard for Oracle performance analysis and should be used alongside HammerDB metrics for comprehensive evaluation.

Oracle Benchmark Best Practices

Following consistent best practices ensures benchmark results are reliable, repeatable, and meaningful.

• Environment isolation: Run benchmarks on a dedicated test environment, not shared infrastructure. Other workloads introduce contention that skews results.

• Network proximity: Place the HammerDB driver in the same VPC and subnet as the Oracle database. Cross-region or cross-VPC tests measure network latency, not database performance.

• Storage warm-up: Run a short pre-test workload before the actual benchmark to warm the buffer cache and storage layer. Cold storage reads produce artificially low results.

• Multiple iterations: Run at least three iterations per configuration and average the results. A single run may not be representative due to cache effects and background processes.

• Ramp-up time: Allow 2 to 5 minutes of ramp-up before measurements begin. This lets connection pools stabilize and the database reach steady state.

• Document everything: Record instance type, storage tier, Oracle version, HammerDB version, warehouse count, virtual user count, and test duration for every run. Reproducibility requires complete configuration records.

• DeWitt clause awareness: Oracle and other commercial database vendors restrict the publication of benchmark results without authorization. Keep detailed benchmark results for internal use. If publishing comparisons, consult Oracle licensing terms and the TPC fair use policy.

Multi-Cloud Oracle Benchmarking with Tessell

One of the most valuable applications of Oracle benchmarking is comparing performance across cloud providers before committing to a migration target. Tessell is the only DBaaS platform that supports Oracle on AWS, Azure, GCP, and OCI with a consistent management layer, making it possible to run identical benchmarks across all four clouds from a single platform.

This eliminates the setup overhead of provisioning Oracle manually on each cloud. With Tessell, teams can provision an Oracle instance on any supported cloud in minutes, run the same HammerDB TPROC-C benchmark with identical parameters, and directly compare NOPM, latency, and cost-per-transaction results. The infrastructure variable (storage type, compute shape, network) becomes the only difference between test runs.

Tessell's NVMe-backed high-performance storage delivers up to 2M IOPS, which is particularly relevant for I/O intensive Oracle workloads where storage is the primary bottleneck. SLOB benchmarks on Tessell NVMe have demonstrated significant throughput advantages over standard cloud block storage across all supported clouds.

For teams evaluating cross-cloud migration or multi-cloud deployment strategies, benchmarking on Tessell provides the objective performance data needed to make informed infrastructure decisions. Tessell offers free trial credits for running your own benchmarks across clouds.

Conclusion

Oracle benchmarking is a critical practice for any team managing Oracle databases in production. Selecting the right tool for your workload type, following established best practices, and interpreting results correctly are the foundations of a reliable benchmarking process.

For OLTP workloads, HammerDB TPROC-C provides the most widely used and cross-database comparable benchmark. For I/O and storage testing, SLOB isolates storage performance from application overhead. For Oracle RAC and multi-schema testing, Swingbench offers purpose-built capabilities.

Before migrating Oracle to the cloud, benchmark your current environment, then run the same benchmark on your target platform. If you are evaluating multiple clouds, Tessell enables consistent Oracle benchmarking across AWS, Azure, GCP, and OCI from a single platform with NVMe-backed performance. Start a free trial or request a demo at tessell.com to benchmark Oracle on your target cloud.