Posts

Showing posts with the label tpc

Using DBGen to Generate TPC-H Test Data

Image
In this post I describe the Data Base Generator (DBGen) utility in terms of what it is, how to install it, and how to use it.   This post assumes a Linux operating system.   There are different build procedures for DBGen on Windows, but the concepts carry over. DBGen is used to create a TPC-H schema (i.e., it provides the CREATE TABLE statements) and to generate the data.   DBGen is used in official TPC-H benchmarking, but it can also be used in informal TPC-H-like benchmarking.   The schema and data is compatible with most 3 rd party benchmarking tools like HammerDB, so even if you plan to run a TPC-H-like test using HammerDB you may still use DBGen to create the schema and data. The  CREATE TABLE   statements are ANSI standard SQL and can be run in any DBMS without editing.   There are no SQL statements for indexes or foreign key constraints provided by DBGen since those types of objects are not required.   The data is created as delimited...

Understanding TPC and TPC-like Database Benchmarks

This post is Part 1 in a series about running benchmarks to measure the performance of relational databases.  This post provides a very brief introduction to the popular industry standard benchmarks TPC-C, E, H, and DS and the software programs you can use to run a variation of each benchmark. The discussion here is generic and can be applied to any relational database like Oracle, SQL Server, MySQL, and PostgreSQL.   The TPC has many benchmarks for non-relational databases not discussed here.   The discussion here is also intended for informal benchmarking without publication.   Why Benchmark? Benchmark tools can answer a variety of questions and help predict success or failure.   Consider the following examples of why organizations perform internal benchmarking of database systems: Predict change impact .   Organizations run benchmarks to see how a system change impacts performance.   Run a benchmark to establish a baseline, make a system or ...

Don't Publish Database Benchmark Results

This post is part of a series about benchmarking the performance of relational databases.  Another post described benchmarking in terms of the pros and cons, equipment and software, time and cost. Benchmarking database performance is often for internal use only.  You cannot publish the results because commercial database licenses include the infamous "DeWitt Clause" which clearly states you may not publish database performance numbers without prior written consent.  This is true for all big databases like IBM, Microsoft, and Oracle.  Even if you downloaded a free trial version of their software, you'll find the DeWitt Clause in the End User License Agreement (the wordy thing you agreed to before downloading the software). Open source licenses generally have no such clause and do not prevent publishing performance numbers.   However, you are still bound by the rules set by the makers of the benchmark and tools.   You cannot use their trademarks without wri...

Ignoring Rules When Benchmarking Databases

This post is part of a series about benchmarking the performance of relational database.  My earlier posts detailed the official TPC benchmarks for relational databases and the popular tools for running informal versions of those benchmarks.  This post describes some of the rules that drive cost and complexity, which leads to the most commonly ignored rules. Each database benchmark has a strict set of rules called a "specification".   There is one specification for TPC-C, another for TPC-E, and so on for every TPC benchmark.   Following all of the rules in a given specification is expensive and time consuming.   Some of the rules aren't practical and can be ignored when testing informally or internally.   You are only required to follow the rules when testing with the intent to publish or if you plan to use the TPC trademark in a publication. To be honest, I have never performed a formal TPC benchmark or followed all of the rules.   All of my tests...

TPC-like Database Benchmarking Tools

Image
  This post describes five popular tools for benchmarking relational databases: HammerDB, Quest Benchmark Factory, SwingBench, pgbench, and Oracle RAT.  Previously, I described TPC and TPC-like benchmarks for relational databases.   Recall a benchmark is "like" a TPC benchmark if it follows some of the rules but not all of them.   The tools described in this post follow some of the TPC's rules so we call them "TPC-like".   Publishing results is generally not allowed by commercial DBMS vendors, and use of the benchmark trademark is also restricted. Ok then, let's look at the most commonly used benchmarking tools for relational databases. HammerDB is my #1 choice for benchmarking relational databases.   HammerDB supports every major DBMS on Linux and Windows including bare metal, VM, and cloud.   This means you can use one tool for all environments.   You can even compare performance across platforms or DBMS, such as comparing Oracle on Linux...