Database Systems Performance Analysis

(Chapter 14)

By
Joseph O. Manalang
September 25, 2010

JORM 1
 Agenda

• Evaluate industrial-grade software products used in many

applications
• Discuss database on-line transaction processing as the overall
application domain
• Main focus is on the assessment of four commercial-grade
database systems:
 Running on a fixed set of testbed hardware and
 Systems software (the operating system).

JORM 2
 Discussion Points

Four Top Database Systems:

 IBM DB2
 Informix UDB
 Microsoft SQL Server
 Oracle 8i

JORM 3
 The Testbed Systems

Testbed Configuration:
CPU: Pentium III @ 500 MHz
Total RAM: 256 MB
Operating System: Windows NT 4.0 Service Pack 5

PC performance assessment benchmark

Test points
1. Integer and floating-point mathematical operations
2. Tests of standard two-dimensional graphical functions
3. Reading, writing, and seeking within disk files
4. Memory allocation and access
5. Tests of the MMX (multimedia extensions) in newer CPUs
6. A test of the DirectX 3D graphics system

JORM 4
 The Testbed Systems:
PC performance Assessment Benchmark

Test suites test for the following:

1. Integer and floating-point mathematical operations
2. Tests of standard two-dimensional graphical functions
3. Reading, writing, and seeking within disk files
4. Memory allocation and access
5. Tests of the MMX (multimedia extensions) in newer CPUs
6. A test of the DirectX 3D graphics system

JORM 5
 Testbed Architecture Performance Results
Oracle Informix SQL DB2
Parameter Tested System System System System
1 Math—Addition 96.6 96.2 94.6 97
2 Math—Subtraction 96.4 97.1 96.2 97.6
3 Math—Multiplication 101.1 101.4 101.4 103.1
4 Math—Division 12.9 12.8 12.9 13
5 Math—Floating-Point Addition 87.7 87.8 87.6 88.7
6 Math—Floating-Point Subtraction 89.4 89.5 88.6 90.1
7 Math—Floating-Point Multiplication 91.7 91.7 90.9 92.3
8 Math—Floating-Point Division 14.8 14.8 14.8 14.9
9 Math—Maximum Mega FLOPS 171.2 172.2 170.7 177.6
10 Graphics 2D—Lines 17.5 17.6 17.5 17.8
11 Graphics 2D—Bitmaps 12.9 12.9 12.8 12.9
12 Graphics 2D—Shapes 4.7 4.7 4.7 4.7
13 Graphics 3D—Many Worlds 22.9 23 22.9 22.9
14 Memory—Allocated Small Blocks 86.6 87.6 87 87.6
15 Memory—Read Cached 67.9 68.4 68 68.5
16 Memory—Read Uncached 48.7 48.8 50 49.1
17 Memory—Write 40.8 41.1 40.9 41.4
18 Disk—Sequential Read 3.2 3.8 3.7 3.1
19 Disk—Sequential Write 2.9 3.4 3.4 2.9
20 Disk—Random Seek 1.2 2.3 3.6 2.1
21 MMX—Addition 97.7 94.5 97.8 99.4
22 MMX—Subtraction 92.3 98.2 93.3 96
23 MMX—Multiplication 97.8 97.5 96.9 99.1
24 Math Mark 75.6 75.8 75.2 76.8
25 2D Mark 46.7 46.9 46.7 47.1
26 Memory Mark 58.7 59.2 59.2 59.4
27 Disk Mark 19.3 25.1 28.4 21.5
28 3D Graphics Mark 15.5 15.7 15.5 15.6
29 MMX Mark 48.8 49.2 48.9 50
JORM 30 Passmark Rating 45.7 47.2 47.8 46.7 6
 180
170
160
150
140
130
120
110
100
90
80
70 Oracle System
60 Informix System
SQL System
50 DB2 System
40
30
20
10
0
on on on on on on on on PS es s es ds ks d d e d te k n n n rk rk rk rk rk rk g
d iti acti cati visi diti acti cati visi FLO Lin map ap orl Bloc che che rit Rea Wri See itio ctio atio Ma Ma Ma Ma Ma Ma atin
i i i i t h a a W l s R
Ad ubtr ltipl —D t Ad ubtr ltipl t D ega D— Bi —S ny W all d C Unc y— ntia tial dom Add btra plic ath 2D ory isk hic MX rk
— S h n S in 2 — D a m a r e n n u lti M D p a
h u t i
at — M a o nt M Po
u M ics 2D 2 M d S Re ad o u ue Ra X— S u
s e m q em Gr
a M sm
s
M ath h— M ng-P Poi int ng- mum aph hics hic D— cate ry— —R Me Se Seq k— MM X— —M M
3 D Pa
t - o ti i r p 3 — is M X
M a
M ati ng -P loa ax G rap Gra ics Allo emo ory sk k— D M M
Flo loati ting —F M G p h — M em Di Dis M
h — F o a th h— r a r y M
at — F a a l t G mo
M ath h— M M e
M a t M
M

JORM 7
 180
170
160
150
140
130
120
110
100
90
80
70
60
50
40 Oracle System
30 Informix System
20 SQL System
10 DB2 System
0
on n
diti ctio tion ion on n n
a s o
Ad btra plic Divi dditi acti atio ision PS es s s
h— Su lti A tr lic iv LO in ap e ds s
at — Mu ath— int Sub ltip t D ga F —L itm hap orl lock hed
M ath — M Po t u n e D B S B c
M ath g- oin t M -Poi M cs 2 D— D— ny W all Ca
n P n g m i 2 2 a m d
M ati ng- Poi tin mu aph ics ics M d S Rea
Flo ati ng- Floa axi Gr ph ph D— ate y—
a 3
h— Flo ati M a
Gr Gr ics Allo mo
c r
at h— Flo ath— th— h e
M at — M a ap y— M
M ath M Gr or
M em
M

8
JORM
 180
170
160
150
140
130
120
110
100
90
80
70
60
50
40 Oracle System
30 Informix System
20 SQL System
10 DB2 System
0

JORM 9
 The Testbed Systems:
Performance
Performance Assessment
Assessment Test
Test Results
Results

The performance assessment test found that the computer

system configured for the DB2 servers appeared to have better
performance than the other systems in most of the tests.

However, the Passmark rating (weighted average of all test

results giving a single overall indication of performance) of the
computer system configured for the SQL Server 2000 was the
highest.

JORM 10
 The Testbed Systems:
Burn-in test

The burn-in test assesses the following items:

 CPU
 Hard drives
 CD-ROMs
 Sound cards
 2D graphics
 3D graphics
 RAM
 Network connections and printers
JORM 11
 The Testbed Systems:
Burn-in Test Assessment Result
System Information: Informix Oracle DB2 SQL Server

Operating System: Win NT4 Win NT4 Win NT4 Win NT4

Number of CPUs: 1 1 1 1

CPU Manufacturer: Intel Intel Intel Intel

CPU Type: Celeron Celeron Celeron Celeron

CPU Features: MMX MMX MMX MMX

CPU Serial #: N/A disabled N/A disabled N/A disabled N/A disabled

CPU1 Speed: 501.3 MHz 501.3 MHz 501.3 MHz 501.3 MHz

CPU Level 2 Cache: 128KB 128KB 128KB 128KB

RAM: 267,821,056 Bytes 267,821,056 267,821,056 267,821,056 Bytes

(256 MB) Bytes (256 MB) Bytes (256 MB) (256 MB)
Color Depth: 24 24 24 24

JORM 12
 The Database System:
Oracle
Database 1—Oracle Architectural Structure

 The components comprising the Oracle database system are executed

using virtual memory structures and basic application processes.

 Processes are jobs or tasks that work in the memory of these computers.

 Oracle has always placed great emphasis on portability: providing uniform

features and facilities across the greatest possible range of operating
environments.

 Oracle implements a common architecture, which includes the above

components.
13
JORM
 The Database System:
Oracle
Oracle’s common architecture components:
 An area of memory available to all Oracle sessions, known as the system global area (SGA). This area of memory includes
recently accessed data blocks (the buffer cache), SQL and PL/SQL objects (the library cache), and transaction information
(the redo log buffer). The SGA may also contain session information.

 Several tasks that perform dedicated database activities, including the database writer (DBWR), redo log writer (LGWR),
system monitor (SMON), process monitor (PMON), and log archiver (ARCH). Other tasks may be configured if required to
support Oracle options, such as parallel query, distributed database, or multithreaded servers. We will refer to these tasks
as background tasks (although they are also often referred to as background processes).

 Oracle data files, which contain the tables, indexes, and other segments that form the Oracle instance.

 Redo logs, which record critical transaction information required for roll-forward in the event of instance failure.

 A separate task created to perform database operations on behalf of each Oracle session, referred to as a dedicated server.
If the multithreaded server option is implemented, many sessions can be supported by a smaller number of shared servers.

 A SQL*Net listener task, which establishes connections from external systems.

JORM 14
 The Database System:
Oracle process and thread structure on NT

ARCH SGA
LGWR
Single
SMON Oracle
PMON Dedicated Dedicated Dedicated Process
Si
DBWR Server Thread Server Thread Server Thread
Thread

Client process such as

Client Client Client Client
Process Process Process Process SQL*Plus application
program
15
JORM
 The Database System:
Oracle
Transactions
Oracle supports many types of transactions, including read-only, read/write, and discrete
transactions.

Query optimization
Oracle provides an internal system feature called the optimizer. The optimizer will determine
one or more execution plans that it can use to execute the SQL statement. Oracle 8i has three
choices: cost, rule, and choose.
The cost-based optimizer will execute the SQL statement using the plan that has the lowest cost

Concurrency control and locking

Oracle uses locking mechanisms to protect data from being destroyed by concurrent
transactions. Oracle provides both automatic and explicit locking capabilities. By default, Oracle
provides locking for database resources for transactions in the database. The system will
automatically set locks on tables and rows; the levels of the locks will depend on the transaction
function (reads, inserts, updates, and deletes). Oracle can set locks in two lock modes: shared or
exclusive.
16
JORM
 The Database System:
Informix
Database 2—Informix Dynamic Server architectural structure

 Informix Dynamic Server is a multithreaded object-relational database

server that manages data stored in rows and columns in a table.

 It employs a single processor or symmetric multiprocessing (SMP)

systems and dynamic scalable architecture to deliver database scalability,
manageability, and performance.

 Dynamic Server can be used for on-line transaction processing (OLTP),

packaging applications, datawarehousing applications, and Web
solutions.

JORM 17
 The Database System:
Informix
Dynamic scalable architecture
The foundation of Informix
Dynamic Server's superior
performance, scalability, and
reliability is its parallel database
architecture, dynamic scalable
architecture (DSA), built to fully
exploit the inherent processing
power of any hardware

Configurable pool
database server.
18
JORM
 The Database System:
Informix
The key advantages of Informix Dynamic Server are as follows:
 Maximum performance and scalability through a superior multithreaded parallel
processing architecture
 Reduced operating system overhead through bypassing operating system limits
 Local table partitioning for superior parallel I/O operations and high-availability
database administration
 Parallel SQL functionality increases performance and lets all database operations
execute in parallel, thereby eliminating potential bottlenecks
 High database availability for supporting a wide range of business-critical applications
on open systems platforms
 Dynamic, distributed on-line system administration for monitoring tasks and
distributing workloads
 Full feature parity on Windows NT and UNIX operating systems
 Full RDBMS functionality across all hardware architectures (uniprocessor, symmetric
multiprocessing, and cluster systems) and database models (relational and object
relational) enables seamless migration of applications, data, and skills
19
JORM
 The Database System:
Informix
Locking, data consistency, isolation, and recovery
 While high availability ensures integrity at the system level, data consistency
ensures consistency at the transaction level.
 Informix Dynamic Server maintains data consistency via transaction logging and
internal consistency checking and by establishing and enforcing locking procedures,
isolation levels, and business rules.

Join Method
 When Informix must join tables, it chooses any of three algorithms
 Nested Loop Join
 Sort Merge Join
 Hash Join

JORM 20
 The Database System:
Informix
Cost-based query optimizer
 Informix Dynamic Server's cost-based optimizer will automatically determine the
fastest way to retrieve data from a database table based on detailed information
about the distribution of those data within the table's columns.
 The optimizer collects and calculates statistics about this data distribution and will
pick the return path that has the least impact on system resources—in some cases
this will be a parallelized return path, but in others it might be a sequential process.
 All that is needed to control the degree of parallelism is the memory grant manager.

Areas that users can control:

 Access methods
 Join methods
 Join order
 Optimization goal
JORM 21
 The Database System:
Informix
Memory handling by Informix
 All memory used by the Informix Dynamic Server is shared among the pool of
virtual processors. In this way, Informix Dynamic Server can be configured to
automatically add more memory to its shared memory pool in order to process
client requests expeditiously.
 Data from the read-only data dictionary (system catalog) and stored procedures are
shared among users rather than copied, resulting in optimized memory utilization
and fast execution of heavily used procedures.
 This feature can provide substantial benefit in many applications, particularly those
accessing many tables with a large number of columns and/or many stored
procedures.

JORM 22
 The Database System:
IBM DB2
Database 3—IBM DB2 architectural structure
 Conceptually, DB2 is a relational database management system.

 Physically, DB2 is an amalgamation of address spaces and intersystem

communication links, which, when adequately tied together, provides the
services of a relational database management system.

 Beginning with DB2 version 3, each DB2 subsystem consists of three or

four tasks started from the operator console 1.

 Each task runs in a portion of the CPU called an address space. Version 4
of DB2 provides an additional address space for stored procedures.

JORM 23
 The Database System:
IBM DB2
The five address spaces contains the logic to effectively handle all DB2 functionality:
1. DBAS - Database Services Address Space, provides the facility for manipulating DB2 data structures. The
default name for this address space is DSNDBM1, but each individual shop may rename any of the DB2
address spaces. The DBAS is responsible for running SQL statements and managing data buffers. It
contains the core logic of the database management system. Three individual components make up the
DBAS: the Relational Data System, the Data Manager, and the Buffer Manager. Each of these components
performs specific tasks.
2. SSAS - System Services Address Space, coordinates the attachment of DB2 to other subsystems (CICS,
IMS/DC, or TSO). SSAS is also responsible for all logging activities (physical logging, log archival, and
BSDS). DSNMSTR is the default name for this address space.
3. IRLM - Intersystem Resource Lock Manager. The third address space required by DB2.. The IRLM is
responsible for managing DB2 locks (including deadlock detection). The default name of this address
space is IRLMPROC.
4. DDF - Distributed Data Facility. The fourth DB2 version 3 address space, is the only optional one. The
DDF is required only if distributed database functionality is needed.
5. SPAS - Stored Procedure Address Space. The newest address space, has been added to DB2 version 4 to
support stored procedures and remote procedure calls (RPCs). The SPAS runs as an allied address space
providing an independent environment for stored procedures to execute. This effectively isolates the
user-written stored procedure code in its own little world so that it cannot interfere with the system code
of DB2 itself.
24
JORM
 The Database System:
IBM DB2
Components of the database services address space

JORM 25
 The Database System:
IBM DB2
DB2 memory management
 The Database Manager Shared Memory is allocated when the database manager
is started using the db2start command, and remains allocated until the database
manager is stopped using the db2stop.

 This memory is used to manage activity across all database connections.

 From the Database Manager Shared Memory, all other memory is attached
and/or allocated.

 The Database Global Memory (also called Database Shared Memory) is allocated
for each database when the database is activated using the ACTIVATE DATABASE
command or when the first application connects to the database.

JORM 26
 IBM DB2:
Database Manager Shared Memory overview

JORM 27
 The Database System:
IBM DB2
The size of this memory is affected by the following configuration parameters:
 Database System Monitor Heap Size (MON_HEAP_SZ)
 Audit Buffer Size (AUDIT_BUF_SZ)
 FCM Buffers (FCM_NUM_BUFFERS)
 FCM Message Anchors (FCM_NUM_ANCHORS)
 FCM Connection Entries (FCM_NUM_CONNECT)
 FCM Request Blocks (FCM_NUM_RQB)

Maximum size of the Database Global Memory segment is determined by the following configuration parameters:
 Buffer pool size explicitly specified when the buffer pools were created or altered (the value of BUFFPAGE
database configuration parameter is taken if 1 is specified)
 Maximum storage for lock list (LOCKLIST)
 Database heap (DBHEAP)
 Utility heap size (UTIL_HEAP_SZ)
 Extended storage memory segment size (ESTORE_SEG_SZ)
 Number of extended storage memory segments (NUM_ESTORE_SEGS)
 Package cache size (PCKCACHESZ)
 Application global memory is determined by the following configuration parameter: application control heap
size (APP_CTL_HEAP_SZ)
28
JORM
 The Database System:
IBM DB2
Query optimization

 Query optimization is the part of the query process in which the database system
compares different query strategies and chooses the one with the least expected
cost.

 The query optimizer carries out this function, is a key part of the relational
database and determines the most efficient way to access data. It makes it
possible for the user to request the data without specifying how these data
should be retrieved.

Two Approaches to Optimization:

1. Cost based
2. Heuristic
29
JORM
 The Database System:
IBM DB2
Concurrency control and locking in DB2
 The granularity of locking within a database management system represents a
definite tradeoff between concurrency and CPU overhead.
 Whenever a finer granularity of locking is desired, an increase in the use of available
CPU resources may be required, because locking in general increases CPU path
length.
 No I/O operations are done, but each lock request requires two-way communication
between DB2 and the internal resource lock manager (IRLM).

DB2 objects that are candidates for transaction locking are as follow:
 Table space
 Partition
 Table
 Page
 Row
30
JORM
 The Database System:
IBM DB2
Join methods
 When multiple tables are requested within a single SQL statement, DB2 must
perform a join.

 When joining tables, the access type (tablespace scan or index scan) defines how
each single table will be accessed; understanding the join method defines how the
result sets from multiple tables will be combined to deliver a unified result set back
to the requester.

 While more than two tables can be joined together in a single SQL statement, DB2
will always perform the join operation in a series of steps.
• Each step joins only two tables together, and a composite table is passed to the
next step in the series.
• The plan tables will describe how these tables are joined together and the order
in which each table is accessed.
JORM 31
 The Database System:
SQL Server
Database 4—Microsoft SQL Server
Architectural Structure
 Microsoft SQL Server 2000
persistently stores data in
database-controlled tables
organized as relations managed in
physical files.

 When using a database, work is

performed primarily with the logical
components, such as tables, views,
procedures, and user space.

 The physical implementation of Logical versus physical view of the database

relations and their realization as
files is largely transparent. 32
JORM
 The Database System:
MS SQL Server
Logical tablespace structures

JORM 33
 The Database System:
SQL Server
Memory Algorithms
 Use of memory by SQL Server objects are major changes in SQL Server 7.0 over SQL
Server 6.5 that improve the performance of the database and also minimize the
work the database administrator must do to configure memory for good
performance
 Microsoft SQL Server 7.0 has dramatically improved the way memory is allocated
and accessed. Unlike SQL Server 6.5, in which memory is managed by the database
administrator with configuration settings, SQL Server 7.0 has a memory manager to
eliminate manual memory
management.

JORM 34
 The Database System:
SQL Server
Locking architecture
 Microsoft SQL Server 2000 uses locks to implement pessimistic concurrency control
among multiple users performing modifications in a database at the same time. By
default, SQL Server manages both transactions and locks on a per connection basis.
 SQL Server locks are applied at various levels of granularity in the database. Locks
can be acquired on rows, pages, keys, ranges of keys, indexes, tables, or databases.
SQL Server dynamically determines the appropriate level at which to place locks for
each Transact-SQL statement. The level at which locks are acquired can vary for
different objects referenced by the same query
 If several connections become blocked waiting for conflicting locks on a single
resource, the locks are granted on a first come, first served basis as the preceding
connections free their locks
 SQL Server can dynamically escalate or de-escalate the granularity or type of locks.

JORM 35
 The Database System:
SQL Server
Structured Query Language
 To work with data in a database, you have to use a set of commands and statements
(language) defined by the DBMS software. Several different languages can be used
with relational databases; the most common is SQL.

 The American National Standards Institute (ANSI) and the International Organization
for Standardization (ISO) define software standards, including standards for the SQL
language. SQL Server 2000 supports the entry level of SQL-92, the SQL standard
published by ANSI and ISO in 1992.

 The dialect of SQL supported by Microsoft SQL Server is called Transact-SQL (T-SQL).
T-SQL is the primary language used by Microsoft SQL Server applications.

JORM 36
 The Database System:
SQL Server

Summary of special features

 Microsoft SQL Server 2000 gives users an excellent streamlined database platform
for large-scale, on-line transactional processing (OLTP), data warehousing, and e-
commerce applications.

 The improvements made to SQL Server version 7.0 provide a fully integrated XML
environment, add a new data mining feature in analysis services, and enhance
repository technology with metadata services.

 SQL Server 2000 enhances the performance, reliability, quality, and ease of use of
SQL Server 7.0.

JORM 37
 Testbed Performance Analysis Testing
 A true comparison of the four databases requires a plain benchmark that does not take
advantage of any of the special features within any of the databases.

 In order to do this the research team researched the latest benchmarks provided by
the Transaction Processing Council (TPC—www.tpc.org).
Three benchmarks were found that would allow them to test OLTP.
1. TPC-C
2. TPC-H
3. TPC-R

JORM 38
 Testbed Performance Analysis Testing:
Workloads
Workloads
 The key concern in the benchmarking of a system is the specification of the
workload.

 The workload of a computer is defined as the set of all inputs the system receives
from its environment.

 The groups used the queries defined in the TPC-H benchmark (Table on next slide)
as the basic workload.

JORM 39

Query 1—Pricing Summary Report
Query 2—Minimum Cost Supplier
Query 3—Shipping Priority
Query 4—Order Priority Checking
Query 5—Local Supplier Volume
Query 6—Forecasting Revenue Change
Query 7—Volume Shipping
Query 8—National Market Share
Query 9—Product Type Profit Measure
Query 10—Returned Item Reporting
Query 11—Important Stock
Identification
Testbed
Testbed Performance
Performance Analysis
Analysis Testing:
Testing:
TPC-H
TPC-H Benchmark
Benchmark
This query will select a pricing summary report for all line items shipped as of a given date (substitution
variable). The date is within 6 to 120 days of the greatest ship date contained in the database. A count
of the number of line items is included in each group.
This query will find, in a given region for each part of a certain type and size, the supplier that can
supply it at the lowest cost. If multiple suppliers in that region offer the same lowest price for the part,
the query will list the parts from the suppliers with the 100 highest account balances.
This query will determine the shipping priority and potential revenue, defined as the sum of the
extended price of the orders having the largest revenue among those that had not been shipped as of a
given date. If more than ten unshipped orders exist, only the ten orders with the largest revenue are
listed.
This query will count the number of orders that were ordered in a given quarter of a given year in
which at least one line item was received later than its committed date.
This query will list, for each country in a region, the revenue volume that resulted from line item
transactions in which the customer ordering parts and the supplier filling them were both in the same
country. The query only considers parts ordered in a certain year.
This query will quantify the amount of revenue increase that would have resulted from eliminating
certain company-wide discounts in a given percentage range in a given year.
This query will determine the value of goods shipped between certain countries to help in the
renegotiation of shipping contracts.
This query will determine how the market share of a given country within a given region has changed
over two years for a given part type.
This query determines how much profit is made on a given line of parts, broken out by supplier country
and year.
This query identifies customers who might be having problems with the parts that are shipped to them.
This query finds the most important subset of suppliers' stock in a given country.
40
JORM
 Testbed Performance Analysis Testing:
TPC-H Benchmark
Query 12—Shipping This query determines whether selecting less expensive modes of shipping is negatively affecting the critical-priority orders by causing
Modes and Order Priority more parts to be received by customers after the committed date.
Query 13—Customer
This query will determine the relationships between customers and the size of their orders.
Distribution
Query 14—Promotion This query will find the percentage of revenue in a year from promotional parts (the time period is a substitution parameter selected
Effect when creating the query with the QGEN application using the Seed variable).

Query 15—Top Supplier This query will find the supplier that contributed the most revenue for all parts shipped during a specific time period (the time period is a
substitution parameter selected when creating the query with the QGEN application using the Seed variable).

Query 16—Parts/Supplier This query will find the count of suppliers that can supply parts that meet particular customer requirements. The brand, type, and product
Relationship sizes are substitution parameters selected when creating the query with the QGEN application using the Seed variable.

Query 17—Small This query will find line item and part for a given brand and type and determine the average quantity of the parts ordered if the quantity is
20 percent less of the average for a seven-year period (the brand and container are substitution parameters selected when creating the
Quantity/Order Revenue query with the QGEN application using the Seed variable).
Query 18—Large-Volume This query will find the top 100 customers who have ever placed a large-quantity order (the quantity is the substitution parameter
Customer selected when creating the query with the QGEN application using the Seed variable).

This query will find the gross discounted revenue for all orders for three different types of parts (the part type, container, quantity, ship
Query 19—Discounted mode, and shipping instructions are substitution parameters selected when creating the query with the QGEN application using the Seed
Revenue variable).
Query 20—Potential Part This query will find the suppliers that have an excess of a given part available for a specific year (the part name and date are the
Promotion substitution parameters selected when creating the query with the QGEN application using the Seed variable).
This query will find the suppliers, for a given country, whose product was part of a multiple supplier order where they failed to meet the
Query 21—Suppliers That committed delivery date (the country is a substitution parameter selected when creating the query with the QGEN application using the
Kept Orders Waiting Seed variable).
This query will find the customers within a specific set of country codes who have not placed orders for seven years but still have a
Query 22—Global Sales positive balance (the country codes are substitution parameters selected when creating the query with the QGEN application using the
Opportunity Seed variable).
JORM 41
 Testbed Performance Analysis Testing:
Preparing for the Testing

 In order to ensure that the testing was standard, one of the performance tests in the
TPC-H benchmark was chosen and modified.

 The planned modifications were the insertion of refreshes, as required by the TPC-H
specifications, and the use of indexing. Thus, two runs would be done: one with no
indexing and refreshes, and one with indexing and refreshes.

 Refreshes are required by the TPC-H specification, but the locations of these refreshes
in the queries are left to the tester.

To ensure that all databases ran the queries in the same order, performance test #1
(Appendix A of TPC-H Benchmark) was used with three predetermined refreshes.

JORM 42
 Testbed Performance Analysis Testing:
Proposed
Proposed Indexes
Indexes for
for Benchmark
Benchmark Tests
Tests
Foreign Keys
CREATE INDEX tpch.c_nk ON tpch.customer(c_nationkey ASC)
CREATE INDEX tpch.s_nk ON tpch.supplier(s_nationkey ASC)
CREATE INDEX tpch.ps_pk ON tpch.partsupp(ps_suppkey ASC)
CREATE INDEX tpch.ps_sk ON tpch.partsupp(ps_suppkey ASC)
CREATE INDEX tpch.1_ok ON tpch.lineitem(1_orderkey ASC)
Primary Keys
CREATE UNIQUE INDEX tpch.c_ck ON tpch.customer(c_custkey ASC)
CREATE UNIQUE INDEX tpch.p_pk ON tpch.part(p_partkey ASC)
CREATE UNIQUE INDEX tpch.s_sk ON tpch.supplier(s_suppkey ASC)
CREATE UNIQUE INDEX tpch.o_ok ON tpch.orderd(o_orderkey ASC)
CREATE UNIQUE INDEX tpch.ps_pk_sk ON tpch.partsupp(ps_partkey ASC, ps_suppkey ASC)
CREATE UNIQUE INDEX tpch.ps_sk_pk ON tpch.partsupp(ps_suppkey ASC, ps_partkey ASC)
Useful Date Fields
CREATE INDEX tpch.o_od ON tpch.orders(o_orderdate ASC)
CREATE INDEX tpch.1_sd ON tpch.lineitem(1_shipdate ASC)

JORM 43
 Testbed Performance Analysis Testing:
Testbed
Testbed procedures
procedures for
for each
each configuration
configuration

Four basic procedures to run the benchmark on each separate configuration:

1. The creation of the database and the database tables for the databases was
needed.

2. The newly created tables were populated with the benchmark test data.

3. Several sample runs on the individual queries were done to ensure that the
systems were running properly and providing each team a way of optimizing the
system prior to the test.

4. Finally, the performance tests were run on each system.

JORM 44
 The
The Results
Results::
Results of the Testbed TPC-H Experiments
Results of the Testbed TPC-H Experiments

JORM 45
 The
The Results:
Results:

Informix versus Oracle versus Informix versus

Reweighted SQL Server Scaled SQL Server Oracle

JORM 46
 Cost/Performance Comparison
The
The Results:
Results:
Cost
Cost versus
versus performance
performance

 Of course, performance is not everything.

 Cost must be taken into account.

 To consider cost we obtained a rough value for

the purchase cost per database system and then
computed a cost per second for performance.

JORM 47
 Summary
Based on the assumptions we made to compare IBM DB2 and Microsoft SQL Server
2000 with Informix UDB and Oracle 8i, it is clear that on:

 A performance and cost level IBM's DB2 is the best choice. Of course, this is subject
to interpretation.

 If you are not concerned with memory use on your system or do not care about
configuring your system, then Microsoft SQL Server can be very appealing, since you
can plug and play and be ready to go with it.

 Using IBM's DB2 requires more administration before the performance shown in
this chapter is achieved.

 Ultimately, it depends on what one plans to do with the database that becomes the
decision factor.
JORM 48