TPC BENCHMARK E. Standard Specification. Version Mail Ballot Draft. December Transaction Processing Performance Council (TPC)

(1)

TPC Benchmark™ E - Standard Specification, Revision 1.0.0 - Page 1 of 264

TPC BENCHMARK

™

E

Standard Specification

Version 1.0.0 – Mail Ballot Draft

December 2006

Transaction Processing Performance Council (TPC)

www.tpc.org

[email protected]

(2)

Legal Notice

The TPC reserves all right, title, and interest to this document and associated source code as provided under U.S. and international laws, including without limitation all patent and trademark rights therein. Permission to copy without fee all or part of this document is granted provided that the TPC copyright notice, the title of the publication, and its date appear, and notice is given that copying is by permission of the Transaction Processing Performance Council. To copy otherwise requires specific permission.

No Warranty

TOTHEMAXIMUMEXTENTPERMITTEDBYAPPLICABLELAW,THEINFORMATIONCONTAINEDHEREIN

ISPROVIDED “ASIS”AND WITHALLFAULTS,ANDTHEAUTHORSANDDEVELOPERSOFTHEWORK

HEREBY DISCLAIM ALL OTHER WARRANTIES AND CONDITIONS, EITHER EXPRESS, IMPLIED OR

STATUTORY, INCLUDING, BUT NOT LIMITED TO, ANY (IF ANY) IMPLIED WARRANTIES, DUTIES OR

CONDITIONS OF MERCHANTABILITY, OF FITNESS FOR APARTICULAR PURPOSE, OF ACCURACY OR

COMPLETENESSOFRESPONSES,OFRESULTS,OFWORKMANLIKEEFFORT,OFLACKOFVIRUSES,ANDOF

LACKOFNEGLIGENCE. ALSO,THEREISNOWARRANTYORCONDITIONOFTITLE,QUIETENJOYMENT,

QUIETPOSSESSION,CORRESPONDENCETODESCRIPTIONORNON-INFRINGEMENTWITHREGARDTO

THEWORK.

INNOEVENTWILLANYAUTHORORDEVELOPEROFTHEWORKBELIABLETOANYOTHERPARTYFOR

ANYDAMAGES,INCLUDINGBUTNOTLIMITEDTOTHECOSTOFPROCURINGSUBSTITUTEGOODSOR

SERVICES,LOSTPROFITS,LOSSOFUSE,LOSSOFDATA,ORANYINCIDENTAL,CONSEQUENTIAL,DIRECT,

INDIRECT,ORSPECIALDAMAGESWHETHERUNDERCONTRACT,TORT,WARRANTY,OROTHERWISE,

ARISINGINANYWAYOUTOFTHISORANYOTHERAGREEMENTRELATINGTOTHEWORK,WHETHER

OR NOT SUCH AUTHOR OR DEVELOPER HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH

DAMAGES.

Trademarks

(3)

Acknowledgments

The TPC acknowledges the work and contributions of the TPC-E subcommittee member companies: AMD, Dell, Fujitsu-Siemens, HP, IBM, Ingres, Intel, Microsoft, NEC, Oracle, Sun, Sybase, and Unisys. In addition, the TPC acknowledges the work of Trish Hogan as specification editor and the work and contributions of InfoSizing.

TPC Membership

(as of December 2006)

Full Members

Associate Members

Document Revision History

Date Version Description

(4)

Typographic Conventions

The following typographic conventions are used in this specification: Convention Description

Bold Bold type is used to highlight terms that are defined in this document

Italics Italics type is used to highlight a variable that indicates some quantity whose value can be _{assigned in one place and referenced in many other places.}

UPPERCASE Uppercase letters indicate database schema object names such as table and column names. _{In addition, most acronyms are in uppercase.}

Diagram Color-Coding Conventions

Concept

Customer Light Green

Broker Pale Blue

Market Rose

Implementation

TPC Provided Code Light Turquoise

Sponsor Provided Code Lavender

Commercially Available Product Light Yellow

1.3 Transaction Summary ... 35 1.3.1 Broker-Volume ... 35 1.3.2 Customer-Position... 35 1.3.3 Market-Feed ... 35 1.3.4 Market-Watch ... 36 1.3.5 Security-Detail ... 36 1.3.6 Trade-Lookup ... 36 1.3.7 Trade-Order ... 36 1.3.8 Trade-Result ... 36 1.3.9 Trade-Status ... 36 1.3.10 Trade-Update ... 36 1.3.11 Data-Maintenance ... 37 1.3.12 Trade-Cleanup ... 37

(5)

1.4 Model Description ... 37

1.4.1 Entity Relationships ... 37

1.4.2 Differences between Customer Tiers ... 37

1.4.3 Customer Partitioning ... 38

1.4.4 Trade Types ... 38

1.4.5 Effects of Trading on Holdings ... 38

Clause 2 -- Database Design, Scaling & Population ... 40

2.1.1 Definitions ... 40

2.2 Database Schema and Table Definitions ... 40

2.2.1 Data Type Definitions ... 40

2.2.2 Meta-type Definitions ... 41

2.2.3 General Schema Items ... 42

2.2.4 Customer Tables ... 43 2.2.5 Broker Tables ... 47 2.2.6 Market Tables ... 51 2.2.7 Dimension Tables ... 55 2.3 Implementation Rules ... 57 2.3.3 Table Partitioning... 57 2.4 Integrity Rules ... 58

2.5 Data Access Transparency Requirements ... 59

2.6 Database Size and Table Cardinality ... 60

2.6.1 Initial Database Size Requirements ... 60

2.6.2 Test Run Database Size Requirements ... 63

Clause 3 -- Transactions ... 64

3.1.1 Definitions ... 64

3.1.2 Database Footprint Definition ... 64

3.2 Transaction Implementation Rules ... 66

3.2.1 Frame Implementation ... 66

3.2.2 Customer Partitioning and Generating Transaction Inputs ... 68

3.3 The Transactions ... 68

3.3.1 The Broker-Volume Transaction ... 69

3.3.2 The Customer-Position Transaction ... 72

3.3.3 The Market-Feed Transaction ... 79

3.3.4 The Market-Watch Transaction ... 84

3.3.5 The Security-Detail Transaction ... 89

3.3.6 The Trade-Lookup Transaction ... 97

3.3.7 The Trade-Order Transaction ... 109

3.3.8 The Trade-Result Transaction ... 127

3.3.9 The Trade-Status Transaction ... 146

3.3.10 The Trade-Update Transaction ... 149

3.3.11 The Data-Maintenance Transaction ... 162

3.3.12 The Trade-Cleanup Transaction ... 175

Clause 4 -- Description of SUT, Driver, and Network ... 180

4.1 Overview ... 180

4.1.1 Description of the Real-World OLTP Environment ... 180

4.1.2 Functional Component Abstraction of the Real-World OLTP Environment ... 180

4.1.3 Distillation of Functional Components into the TPC-E Environment ... 181

(6)

4.3 Example Test Configuration Implementations ... 186

4.4 Further Requirements for SUT and Driver Implementations ... 188

4.4.1 Restrictions on the Driver ... 188

4.4.2 Disclosure of Network Configuration ... 189

4.4.3 SUT Implementation Limits on Operator Intervention ... 189

4.4.4 Synchronization of Time ... 189

Clause 5 -- EGen ... 190

5.1 Overview ... 190

5.2 EGen Terms ... 190

5.3 Compliant EGen Versions ... 191

5.3.5 Using EGen within a Compliant Driver ... 191

5.3.6 Addressing Errors in EGen ... 191

5.3.7 Process for Reporting Issues with EGen ... 192

5.3.8 Submitting EGen Enhancement Suggestions ... 192

5.4 EGenProjectFiles ... 193 5.5 EGenInputFiles ... 193 5.6 EGenSourceFiles ... 193 5.7 EGenLoader... 193 5.8 EGenDriver ... 193 5.8.5 EGenDriverCE ... 194 5.8.6 EGenDriverMEE... 194 5.8.7 EGenDriverDM ... 194 5.9 EGenTxnHarness ... 194 5.10 EGenValidate ... 194

Clause 6 -- Execution Rules & Metrics ... 195

6.1.1 Definition of Terms... 195

6.2 Driver Implementation Architectures ... 195

6.2.1 The Simple CE ... 195

6.2.2 The Replicated CE ... 196

6.2.3 The Asynchronous CEs ... 197

6.2.4 Combinations ... 199

6.3 Transaction Mix ... 199

6.3.1 Mix Requirements ... 199

6.3.2 Required Precision for Mix Percentage Reporting... 200

6.3.3 Data-Maintenance ... 200

6.3.4 Trade-Cleanup ... 200

6.4 Input Parameters ... 201

6.4.1 Input Value Mix Requirements ... 201

6.4.2 Transaction Input Value Boundaries ... 202

6.4.3 EGenDriverCE Partitioning ... 203

6.5 Response Time and Pacing Delays ... 204

6.5.1 Response Time ... 204

6.5.2 Dispatch Time and Pacing Delay ... 207

6.6 Test Run ... 207

6.6.2 Database Content ... 207

(7)

6.6.4 Steady State ... 208

6.6.5 Measurement Interval ... 209

6.6.6 Database Growth ... 209

6.6.7 Performance & Database Size ... 210

6.7 Required Reporting ... 210

6.7.1 Reported Throughput ... 210

6.7.2 Test Run Graph ... 211

6.7.3 Primary Metrics ... 211

6.7.4 EGenValidate Results ... 212

Clause 7 -- Transaction and System Properties (ACID) ... 213

7.1 ACID Properties ... 213

7.2 Atomicity Requirements ... 213

7.2.1 Atomicity Property Definition ... 213

7.2.2 Atomicity Tests ... 214

7.3 Consistency Requirements ... 214

7.3.1 Consistency Property Definition ... 214

7.3.2 Consistency Conditions ... 214

7.3.3 Consistency Tests... 214

7.4 Isolation Requirements ... 215

7.4.1 Isolation Property Definition ... 215

7.4.2 Isolation Tests ... 216

7.5 Durability Requirements ... 219

7.5.2 Single Points of Failure ... 219

7.5.3 Durability Throughput Requirements ... 220

7.5.4 Multiple Instance of the Operating System ... 220

7.5.5 Non-catastrophic Failures ... 221

7.5.6 Catastrophic Failures ... 222

7.5.7 Required Reporting for Durability ... 224

Clause 8 -- Pricing ... 226

8.1 Priced Configuration ... 226

8.2 On-line Storage Requirement ... 226

8.2.1 Continuous Operation Requirement ... 226

8.2.2 60-Day Data Space ... 226

8.2.3 Archive Operation Requirement ... 227

8.2.4 Back-up Storage Requirements ... 227

8.3 TPC-E Specific Pricing Requirements ... 227

8.3.1 Additional Operational Components... 227

8.3.2 Additional Software ... 227

8.4 Component Substitution ... 227

8.5 Required Reporting ... 228

Clause 9 -- Full Disclosure Report ... 230

9.1 Full Disclosure Report Requirements ... 230

9.1.1 General Items ... 230

9.2 Executive Summary Statement ... 230

9.2.1 First Page of the Executive Summary Statement ... 230

9.2.2 Additional Pages of Executive Summary Statement ... 231

9.2.3 ES.xml Requirements ... 232

(8)

9.3.1 Report Introduction ... 232

9.3.2 Clause 2 Database Design, Scaling & Population Related Items ... 234

9.3.3 Clause 3 Transaction Related Items ... 236

9.3.4 Clause 4 SUT, Driver, and Network Related Items ... 236

9.3.5 Clause 5 EGen Related Items ... 236

9.3.6 Clause 6 Performance Metrics and Response Time Related Items ... 236

9.3.7 Clause 7 Transaction and System Properties Related Items ... 237

9.3.8 Clause 8 Pricing Related Items ... 237

9.3.9 Supporting Files Index Table ... 237

9.4 Supporting Files ... 238 9.4.1 SupportingFiles/Introduction Directory ... 238 9.4.2 SupportingFiles/Clause2 Directory ... 239 9.4.3 SupportingFiles/Clause3 Directory ... 239 9.4.4 SupportingFiles/Clause4 Directory ... 239 9.4.5 SupportingFiles/Clause5 Directory ... 239 9.4.6 SupportingFiles/Clause6 Directory ... 239 9.4.7 SupportingFiles/Clause7 Directory ... 239 9.4.8 SupportingFiles/Clause8 Directory ... 239

Clause 10 -- Independent Audit ... 240

10.1 General Rules ... 240

10.1.1 Audit Requirements ... 240

10.2 Audit Check List ... 241

10.2.1 Auditing EGen ... 241

10.2.2 Auditing the Database ... 242

10.2.3 Auditing the Transactions ... 243

10.2.4 Auditing the SUT, Driver and Networks ... 243

10.2.5 Auditing the Execution Rules and Metrics ... 245

10.2.6 Auditing the ACID Tests... 246

10.2.7 Auditing the Pricing ... 247

10.2.8 Auditing the FDR ... 247

Appendix A. EGen User’s Guide ... 248

A.1 Overview ... 248

A.2 EGen Directory ... 248

A.3 EGenProjectFiles ... 248 A.4 EGenInputFiles ... 249 A.5 EGenSourceFiles ... 249 A.6 EGenLoader... 249 A.7 EGenDriver ... 250 A.8 EGenLogger... 251

A.9 Implementing a CE using EGenDriverCE ... 251

A.10 Implementing a MEE using EGenDriverMEE ... 251

A.11 Implementing a Data-Maintenance Generator using EGenDriverDM ... 252

A.12 EGenTxnHarness ... 252

A.13 Functional Implementation ... 253

A.14 TPC Defined Interfaces ... 255

(9)

B.1 Sample Layouts ... 257

B.2 Sample Executive Summary Statement ... 258

Appendix C. TPC-E XML Schema Guide ... 262

C.1 Overview ... 262

C.2 Schema Structure ... 262

Table of Figures

Figure 1.a - Business Model Transaction Flow ... 34

Figure 1.b - Application Components ... 35

Figure 3.a - Frames Interfacing with the Harness and the Database ... 64

Figure 4.a - Diagram of the Real-World OLTP Environment ... 180

Figure 4.b - Abstraction of the Functional Components in an OLTP Environment ... 181

Figure 4.c - Functional Components of the Test Configuration ... 182

Figure 4.d - Defined Components of the Test Configuration ... 185

Figure 4.e - Sample Component of Physical Test Configuration ... 186

Figure 4.f - Separate Driver with Combined Tier A and Tier B ... 187

Figure 4.g - Driver and Tier A Combined, Separate Tier B ... 187

Figure 4.h - Combined Driver, Tier A and Tier B ... 188

Figure 6.a - The Simple CE ... 196

Figure 6.b - The Replicated CE ... 197

Figure 6.c – Asynchronous Transaction Generator ... 198

Figure 6.d – Non-Blocking Driver Threads of Execution ... 199

Figure 6.e - Measuring Response Time ... 206

Figure 6.f - Example of the Measured Throughput versus Elapsed Time Graph ... 211

Figure 9.a - Example of Measured Benchmark Configuration ... 233

Figure A.a - Hierarchy of EGen Directory ... 248

(10)

CLAUSE 0 -- PREAMBLE

0.1

Introduction

TPC Benchmark™ E (TPC-E) is an On-Line Transaction Processing (OLTP) workload. It is a mixture of read-only and update intensive transactions that simulate the activities found in complex OLTP application environments. The database schema, data population, transactions, and implementation rules have been designed to be broadly representative of modern OLTP systems. The benchmark exercises a breadth of system components associated with such environments, which are characterized by:

The simultaneous execution of multiple transaction types that span a breadth of complexity; Moderate system and application execution time;

A balanced mixture of disk input/output and processor usage; Transaction integrity (ACID properties);

A mixture of uniform and non-uniform data access through primary and secondary keys;

Databases consisting of many tables with a wide variety of sizes, attributes, and relationships with realistic content;

Contention on data access and update. The TPC-E operations are modeled as follows:

The database is continuously available 24 hours a day, 7 days a week, for data processing from multiple

Sessions and data modifications against all tables, except possibly during infrequent (e.g., once a month) maintenance Sessions.

Due to the worldwide nature of the application modeled by the TPC-E benchmark, any of the transactions may be executed against the database at anytime, especially in relation to each other. 0.1.1 Goal of the TPC-E Benchmark

The TPC-E benchmark simulates the OLTP workload of a brokerage firm. The focus of the benchmark is the central database that executes transactions related to the firm‟s customer accounts. In keeping with the goal of measuring the performance characteristics of the database system, the benchmark does not attempt to measure the complex flow of data between multiple application systems that would exist in a real environment.

The mixture and variety of transactions being executed on the benchmark system is designed to capture the characteristic components of a complex system. Different transaction types are defined to simulate the interactions of the firm with its customers as well as its business partners. Different transaction types have varying run-time requirements.

The benchmark defines:

Two types of transactions to simulate Consumer-to-Business as well as Business-to-Business activities Several transactions for each transaction type

Different execution profiles for each transaction type A specific run-time mix for all defined transactions

For example, the database will simultaneously execute transactions generated by systems that interact with customers along with transactions that are generated by systems that interact with financial markets as well as administrative systems.

The benchmark system will interact with a set of Driver systems that simulate the various sources of

(11)

The Performance Metric reported by TPC-E is a "business throughput” measure of the number of

completed Trade-Result transactions processed per second (see Clause 6.7.1). Multiple Transactions

are used to simulate the business activity of processing a trade, and each Transaction is subject to a Response Time constraint. The Performance Metric for the benchmark is expressed in transactions-per-second-E (tpsE). To be compliant with the TPC-E standard, all references to tpsE Results must

include the tpsE rate, the associated price-per-tpsE, and the Availability Date of the Priced Configuration (See Clause 6.7.3 for more detail).

Although this specification defines the implementation in terms of a relational data model, the database may be implemented using any commercially available Database Management System (DBMS), Database Server, file system, or other data repository that provides a functionally equivalent

implementation. The terms "table", "row", and "column" are used in this document only as examples of logical data structures.

TPC-E uses terminology and metrics that are similar to other benchmarks, originated by the TPC and others. Such similarity in terminology does not imply that TPC-E Results are comparable to other benchmarks. The only benchmark Results comparable to TPC-E are other TPC-E Results that conform

to a comparable version of the TPC-E specification. 0.1.2 Restrictions and Limitations

Despite the fact that this benchmark offers a rich environment that represents many OLTP applications, this benchmark does not reflect the entire range of OLTP requirements. In addition, the extent to which a customer can achieve the Resultsreported by a vendor is highly dependent on how closely TPC-E

approximates the customer application. The relative performance of systems derived from this benchmark does not necessarily hold for other workloads or environments. Extrapolations to any other environment are not recommended.

Benchmark Results are highly dependent upon workload, specific application requirements, and

systems design and implementation. Relative system performance will vary because of these and other factors. Therefore, TPC-E should not be used as a substitute for specific customer application benchmarking when critical capacity planning and/or product evaluation decisions are contemplated. Benchmark Sponsors are permitted various possible implementation designs, insofar as they adhere to

the model described and pictorially illustrated in this specification. A Full Disclosure Report(FDR) of

the implementation details, as specified in Clause 9.1, must be made available along with the reported Results.

Comment: While separated from the main text for readability, comments are a part of the standard and must be enforced.

0.2

General Implementation Guidelines

The purpose of TPC benchmarks is to provide relevant, objective performance data to industry users. To achieve that purpose, TPC benchmark specifications require that benchmark tests be implemented with systems, products, technologies and pricing that:

Are generally available to users.

Are relevant to the market segment that the individual TPC benchmark models or represents (e.g., TPC-E models and represents high-volume, complex OLTP database environments).

A significant number of users in the market segment the benchmark models or represents would plausibly implement.

(12)

The use of new systems, products, technologies (hardware or software) and pricing is encouraged so long as they meet the requirements above. Specifically prohibited are benchmark systems, products, technologies, pricing (hereafter referred to as "implementations") whose primary purpose is performance optimization of TPC benchmark Results without any corresponding applicability to

real-world applications and environments. In other words all "benchmark specials” implementations that improve benchmark Results but not real-world performance or pricing, are prohibited.

The following characteristics should be used as a guide to judge whether a particular implementation is a benchmark special. It is not required that each point below be met, but that the cumulative weight of the evidence be considered to identify an unacceptable implementation. Absolute certainty or certainty beyond a reasonable doubt is not required to make a judgment on this complex issue. The question that must be answered is this: based on the available evidence, does the clear preponderance (the greater share or weight) of evidence indicate that this implementation is a benchmark special?

The following characteristics should be used to judge whether a particular implementation is a benchmark special:

Is the implementation generally available, documented, and supported?

Does the implementation have significant restrictions on its use or applicability that limits its use beyond TPC benchmarks?

Is the implementation or part of the implementation poorly integrated into the larger product?

Does the implementation take special advantage of the limited nature of TPC benchmarks (e.g., transaction profile, Transaction Mix, transaction concurrency and/or contention, transaction isolation)

in a manner that would not be generally applicable to the environment the benchmark represents? Is the use of the implementation discouraged by the vendor? (This includes failing to promote the

implementation in a manner similar to other products and technologies.)

Does the implementation require uncommon sophistication on the part of the end-user, programmer, or system administrator?

Is the pricing unusual or non-customary for the vendor, or unusual or non-customary to normal business practices? See the current revision of version 1 of the TPC Pricing Specification for additional information.

Is the implementation being used (including beta) or purchased by end-users in the market area the benchmark represents? How many? Multiple sites? If the implementation is not currently being used by end-users, is there any evidence to indicate that it will be used by a significant number of users?

0.3

General Measurement Guidelines

TPC benchmark Results are expected to be accurate representations of system performance. Therefore,

there are certain guidelines, which are expected to be followed when measuring those Results. The approach or methodology is explicitly outlined in or described in the specification.

The approach is an accepted engineering practice or standard. The approach does not enhance the Result.

Equipment used in measuring Results is calibrated according to established quality standards.

Fidelity and candor is maintained in reporting any anomalies in the Results, even if not specified in the

benchmark requirements.

The use of new methodologies and approaches is encouraged so long as they meet the requirements above.

(13)

CLAUSE 1 -- BENCHMARK OVERVIEW

1.1

Definitions

NUMBERS _____________________

60-Day Period

Storage must be priced for sufficient space to store and maintain the data and indices generated during a period of 60 Business Days at the Reported Throughput called the 60-Day Period.

60-Day Space

The 60-Day Space must be computed as:

60-Day Space = Initial Database Size + (60 * Data Growth)

A ___________________________

Accessibility

Accessibility: The ability to maintain database operations with full data access after the permanent

irrecoverable failure of any single Durable Medium containing database tables, recovery log data, or

database metadata. See Clause 7.5.2.1.

ACID

ACID – the transactional properties of Atomicity, Consistency, Isolation and Durability.

Add

The word “Add” indicates that a number of rows are added to the table specified by the Database Footprint. Table row(s) can only be added in a Frame where the word “Add” is specified.

Application

The term Application or Application Program refers to code that is not part of the commercially

available components of the SUT, but produced specifically by the Sponsor to implement the Transaction profiles (see Clause 3.3) of this benchmark. For example, stored procedures, triggers, and

referential integrity constraints are considered part of the Application Program when used to

implement any portion of the Transaction profiles, but are not considered part of the Application Program when solely used to enforce integrity rules (see Clause 2.4) or transparency requirements (see Clause 2.5) independently of any Transaction profile.

Arbitrary Transaction

An Arbitrary Transaction is a Database Transaction that executes arbitrary operations against the

database at a minimum isolation level of L0 (see Clause 7.4.1.3).

(14)

Attestation Letter: The Auditor‟s opinion regarding the compliance of a Result must be consigned in

an AttestationLetter delivered directly to the Sponsor.

Auditor

See TPC-Certified Auditor.

Availability Date

The date when all products necessary to achieve the stated performance will be available (stated as a single date on the Executive Summary Statement). This is known as the Availability Date.

B ___________________________

BALANCE_T

BALANCE_T is defined as SENUM(12,2) and is used for holding aggregate account and transaction

related values such as account balances, total commissions, etc.

BOOLEAN

BOOLEAN is a data type capable of holding the value zero that reflects FALSE or the value one that

denotes TRUE.

Brokerage Initiated

Brokerage Initiated: These Transactions simulate broker interactions with the system and are initiated

by the Customer Emulator component of the benchmark Driver.

Broker Tables

Broker Tables: This set includes 9 tables that contain information about the brokerage firm and the

broker related data.

Business Day

Business Day: a period of eight hours of transaction processing activity.

Business Recovery

Business Recovery: the process of recovering from a Catastrophic system failure and reaching a point

where the business meets certain operational criteria.

Business Recovery Time

Business Recovery Time: the elapsed period of time between start of Business Recovery and end of Business Recovery.

(15)

TPC Benchmark™ E - Standard Specification, Revision 1.0.0 - Page 15 of 264 C ___________________________

Catastrophic

Catastrophic: a type of failure where processing is interrupted without any foreknowledge given to the SUT. Subsequent to this interruption, all contexts for all active applications are lost and all memory in the

SUT is cleared.

CE

See Customer Emulator.

CHAR(n)

CHAR(n) means a character string that can hold up to n single-byte characters. Strings may be padded with spaces to the maximum length. CHAR(n) must be implemented using a Native Data Type.

Commit

Commit: a control operation by the Database Management System that makes the tentative changes

by a transaction to the data permanent.

Committed

Committed: a Transaction is Committed once its actions (Add, Remove, Modify) are Durable and visible to other Transactions.

Configured Customers

Configured Customers means the number of customers (with corresponding rows in the associated

tables) configured at database generation.

Customer Emulator

One key piece of a compliant TPC-E Driver is the Customer Emulator (CE). The CE is responsible for

emulating customers, requesting a service of the brokerage house, providing the necessary input for the requested service, etc. Therefore, the CE is responsible for the following.

Deciding which Customer Initiated or Brokerage Initiated Transaction to perform next

(Broker-Volume, Customer-Position, Market-Watch, Security-Detail, Lookup, Order, Trade-Update and Trade-Status).

Generating compliant data to be used as inputs for the selected Transaction. Sending the Transaction request and associated input data to the SUT.

Receiving the Transaction response and associated output data from the SUT.

Measuring the Transaction‟s Response Time.

Comment: The CE may optionally perform additional operations as well, such as statistical accounting,

(16)

Customer Initiated

Customer Initiated: These Transactions simulate customer interactions with the system and are

initiated by the Customer Emulator component of the benchmark Driver.

Customer Tables

Customer Tables: This set includes 9 tables that contain information about the customers of the

brokerage firm.

D ___________________________

Data-Maintenance Generator

Another key piece of a compliant TPC-E Driver is the single instance of the Data-Maintenance Generator (DM). The DM is responsible for:

Generating compliant data to be used as inputs for the Data-Maintenance Transaction

Sending the Transaction request and associated input data to the SUT

Receiving the Transaction‟s response and associated output data from the SUT and measuring the Transaction‟s Response Time.

Comment: The DM may optionally perform additional operations as well, such as statistical accounting,

data logging, etc. The DM may optionally be used to initiate a single Trade-Cleanup Transaction

before the start of a Test Run.

Database Footprint

The Frame Implementation must perform each database interaction specified in the Transaction’s Database Footprint, using the specified access method. The Database Footprint of a Transaction is the

set of required database interactions to be executed by that Transaction.

Database Interface

Database Interface – Commercially available product used by the Frame Implementation to

communicate with the Database Server. It is possible that the Database Interface may communicate

with the Database Server over a Network, but this is not a requirement.

Data Growth

Data Growth: the space needed in the DBMS data files to accommodate the increase in the Growing Tables resulting from executing the Transaction Mix at the Reported Throughput during the period of

required Sustainable performance.

Data Growth = Data-Space-per-Trade-Result * tpsE * Business Day duration in seconds

Database Logic

Database Logic – Sponsor written Frame implementation logic (e.g. stored SQL procedure)

(17)

A Database Management System (DBMS) is a collection of programs that enable you to store, modify,

and extract information from a database. There are many different types of DBMSs, ranging from small

systems that run on personal computers to huge systems that run on mainframes. From a technical standpoint, DBMSs can differ widely. The terms relational, network, flat, and hierarchical all refer to

the way a DBMS organizes information internally. The internal organization can affect how quickly

and flexibly you can extract information. Requests for information from a database are made in the form of a query, which is a stylized question. The set of rules for constructing queries is known as a query language. The information from a database can be presented in a variety of formats. Most

DBMSs include a report writer program that enables you to output data in the form of a report.

Database Server

Database Server – Commercially available product(s). Sponsor provided logic may run in the context

of the Database Server (e.g. a stored SQL procedure). An example of a Database Server is:

commercially available DBMS running on a

commercially available Operating System running on a

commercially available hardware system utilizing commercially available storage

Database Session

To work with a database instance, to make queries or to manage the database instance, you have to open a Database Session. This can happen as follows: The user logs on to the database with a user

name and password, thus opening a Database Session. Later, the Database Session is terminated explicitly by the user or closed implicitly when the timeout value is exceeded. A database tool implicitly opens a Database Session and then closes it again.

Database Transaction

A Database Transaction is an ACID unit of work.

DATE

DATE represents the data type of date with a granularity of a day and must be able to support the

range of January 1, 1800 to December 31, 2199, inclusive. DATE must be implemented using a Native Data Type.

Comment: A time component is not required but may be implemented.

DATETIME

DATETIME represents the data type for a date value that includes a time component. The date

component must meet all requirements of the DATE data type. The time component must be capable of

representing the range of time values from 00:00:00 to 23:59:59. Fractional seconds may be implemented, but are not required. DATETIME must be implemented using a Native Data Type.

DBMS

(18)

Digit

Digit means decimal digit.

Dimension Tables

Dimension Tables: This set includes 4 dimension tables that contain common information such as

addresses and zip codes.

Dispatch Time

The Dispatch Time of CE Transaction n is defined as follows: for the Non-Blocking Driver Thread architecture (see 6.2.3.2)

DTn = (sTn+1 – sTn).

for all other architectures in Clause 6.2

DTn = ((sTn+1 – sTn) – RTn).

sTn and RTn are defined in Clause 6.5.1.1

sTn+1 is measured in the same location and on the same thread of execution as sTn

DM

See Data-Maintenance Generator.

Driver

To measure the performance of the OLTP system, a simple Driver generates Transactions and their

inputs, submits them to the System Under Test, and measures the rate of completed Transactions

being returned. To simplify the benchmark and focus on the core transactional performance, all application functions related to User-Interface and Display-Functions have been excluded from the benchmark. The System Under Test is focused on portraying the components found on the sever side

of a transaction monitor or application server.

Durability

See Durable.

Durability Throughput Requirements

Durability Throughput Requirements: conditions the SUT must satisfy for all Durability tests (see

Clause 7.5.3).

Durable

Durable: state that survives failures (as described in Clause 7.5.2) and that has transactional update

(19)

Durable Medium

Durable Medium: a data storage medium that is inherently non-volatile such as a magnetic disk or

tape. Durable Media is the plural of Durable Medium.

E ___________________________

EGen

EGen is a TPC provided software environment that must be used in a Test Sponsor's implementation

of the TPC-E benchmark. The software environment is logically divided into three packages:

EGenProjectFiles, EGenInputFiles, and EGenSourceFiles. The software packages provide

functionality to use: EGenLoader to generate the data used to populate the database, EGenDriver to

generate transactional data and EGenTxnHarness to control frame invocation.

EGenDriver

EGenDriver comprises the following parts:

EGenDriverCE

provides the core functionality necessary to implement a

Customer Emulator

.

EGenDriverMEE

provides the core functionality necessary to implement a

Market Exchange Emulator

.

EGenDriverDM

provides the core functionality necessary to implement the

Data-Maintenance Generator

.

EGenDriver provides core transactional functionality (e.g. Transaction Mix and input generation)

necessary to implement a Driver.

EGenDriverCE

EGenDriverCE – any and/or all instantiations of the CCE class (see EGenSourceFiles CE.h and

CE.cpp).

EGenDriverDM

EGenDriverDM – the single instantiation of the CDM class (see EGenSourceFiles DM.h and DM.cpp).

EGenDriverMEE

EGenDriverMEE – any and/or all instantiations of the CMEE class (see EGenSourceFiles MEE.h and

MEE.cpp).

EGenInputFiles

EGenInputFiles is a set of TPC provided text files containing rows of tab-separated data, which are

used by various EGen packages as “raw” material for data generation.

(20)

EGenLoader is a binary executable, generated by using the methods described in EGenProjectFiles

with source code from EGenSourceFiles, including any extensions by a Test Sponsor (see Clause

5.7.3). When executed, EGenLoader uses EGenInputFiles to produce a set of data that represents the

initial state of the TPC-E database.

EGenLogger

EGenLogger logs the initial configuration and any re-configuration of EGenDriver and EGenLoader,

and compares current configuration with the TPC-E prescribed defaults.

EGenProjectFiles

EGenProjectFiles is a set of TPC provided files used to facilitate building the EGen packages in a Test Sponsor's environments.

EGenSourceFiles

EGenSourceFiles is the collection of TPC provided C++ source and header files.

EGenTables

EGenSourceFiles contain class definitions that provide abstractions of the TPC-E tables. These table

classes are known collectively as EGenTables and they encapsulate the functionality needed to generate the data for each of the TPC-E tables.

EGenValidate

EGenValidate is a binary executable, generated by using methods described in EGenProjectFiles with

source code from EGenSourceFiles. When executed, EGenValidate uses Sponsor provided input to

validate that the Sponsor's Measurement Interval had compliant Trade-Results per Load Unit.

EGenTxnHarness

EGenTxnHarness defines a set of interfaces that are used to control the execution of, and

communication of inputs and outputs, of Transactions and Frames.

ENUM

ENUM(m[,n]) or SENUM(m[,n]) means an exact numeric value (unsigned or signed, respectively). ENUM and SENUM are identical to NUM and SNUM, respectively, except that they must be implemented using a Native Data Type which provides exact representation of at least n Digits of

precision after the decimal place.

Executive Summary Statement

The term Executive Summary Statement refers to the Adobe Acrobat PDF file in the ExecutiveSummaryStatement folder in the FDR. The contents of the Executive Summary Statement are

(21)

TPC Benchmark™ E - Standard Specification, Revision 1.0.0 - Page 21 of 264 F ___________________________

FDR

The FDR is a zip file of a directory structure containing the following: A Report in Adobe Acrobat PDF format,

An Executive Summary Statement in Adobe Acrobat PDF format,

An XML document (“ES.xml”) with approximately the same information as in the Executive Summary Statement,

The Supporting Files consisting of various source files, scripts, and listing files. Requirements for the FDR file directory structure are described below.

Comment: The purpose of the FDR is to document how a benchmark Result was implemented and

executed in sufficient detail so that the Result can be reproduced given the appropriate hardware and

software products.

FIN_AGG_T

FIN_AGG_T is defined as SENUM(15,2) and is used for holding aggregated financial data such as

revenue figures, valuations, and asset values.

Fixed Space

Fixed Space: any other space used to store static information and indices. It includes all database

storage space allocated to the test database which does not qualify as either Free Space or Growing Space.

Fixed Tables

Fixed Tables:These tables always have the same number of rows regardless of the database size and

transaction throughput. For example, TRADE_TYPE has five rows.

Foreign Key

A Foreign Key (FK) is a column or combination of columns used to establish and enforce a link

between the data in two tables. A link is created between two tables by adding the column or columns that hold one table's Primary Key values to the other table. This column becomes a Foreign Key in the

second table.

Frame

A Frame is the Sponsor implemented Transaction logic, which is invoked as a unit of execution by the EGenTxnHarness. The database interactions of a Transaction are all initiated from within its Frames.

(22)

Frame Implementation – Sponsor provided functionality that accepts inputs from, and provides

outputs to, EGenTxnHarness through a TPC Defined Interface. The Frame Implementation and all

down-stream functional components are responsible for providing the appropriate functionality outlined in the Transaction profiles (Clause 3.3).

Free Space

Free Space: any space allocated to the test database and available for future use. It includes all

database storage space not already used to store a database entity (e.g., a row, an index, metadata) or not already used as formatting overhead by the DBMS.

Full Disclosure Report (FDR)

See FDR.

G ___________________________

Growing Space

Growing Space: any space used to store existing rows from the Growing Tables (i.e., the CASH_TRANSACTION, HOLDING, HOLDING_HISTORY, SETTLEMENT, TRADE, and TRADE_HISTORY tables) and their associated indices and storage overhead. It includes all database storage space that is added to the test database as a result of inserting a new row in the Growing Tables, such as row data, index data and other overheads such as index overhead, page overhead,

block overhead, and table overhead.

Growing Tables

Growing Tables: These tables each have an initial cardinality that has a constant relationship to the

cardinality of the CUSTOMER table. However, the cardinality increases with new growth during the benchmark run at a rate that is proportional to transaction throughput rates.

H ___________________________

I ___________________________

IDENT_T

IDENT_T is defined as NUM(11) and is used to hold identifier fields.

Initial Database Size

Initial Database Size is measured after the database is initially loaded with the data generated by

EGenLoader. Initial Database Size is any space allocated to the test database which is used to store a

database entity (e.g. a row, an index, metadata), or used as formatting overhead by the data manager.

(23)

The Initial Trade Days (ITD) is the number of Business Days used to populate the database. This

population is made of trade data that would be generated by the SUT when running at the Nominal Throughput for the specified number of Business Days. The number of Initial Trade Days is 300.

ITD

ITD see Initial Trade Days.

J ___________________________

K __________________________

L __________________________

Load Unit

The size of the CUSTOMER table can be increased in increments of 1000 customers. A set of 1000 customers is known as a Load Unit.

LOB(n)

LOB(n) is a data type capable of holding a variable length binary object of n bytes.

Log Growth

Log Growth: the space needed in the DBMS log files to accommodate the Undo/Redo Log resulting

from executing the Transaction Mix at the Reported Throughput during the period of required Sustainable performance.

Log Growth = Log-Space-per-Trade-Result * tpsE * Business Day duration in seconds

M ___________________________

Market Exchange Emulator

Another key piece of a compliant TPC-E Driver is the Market Exchange Emulator (MEE). The MEE is

responsible for emulating the stock exchanges: providing services to the brokerage house, performing requested trades, providing market activity updates, etc. Therefore, the MEE is responsible for the

following:

Receiving trade requests and their associated data from the SUT.

Initiating Trade-Result Transactions, sending the associated data to the SUT and measuring the Transaction‟s Response Time.

Initiating Market-Feed Transactions, sending the associated data to the SUT and measuring the Transaction‟s Response Time.

Comment: The MEE may optionally perform additional operations as well; such as statistical accounting,

(24)

Market Tables

Market Tables: This set includes 11 tables that contain information about companies, markets,

exchanges, and industry sectors.

Market Triggered

Market Triggered: These Transactions simulate the behavior of the market and are triggered by the Market Exchange Emulator component of the benchmark Driver.

May

The word “may” in the specification means that an item is truly optional.

Measured Throughput

The Measured Throughput is computed as the total number of Valid Trade-Result Transactions

within the Measurement Interval divided by the duration of the Measurement Interval in seconds.

Measurement Interval

Measurement Interval: the period of time during Steady State chosen by the Test Sponsor to compute

the ReportedThroughput.

MEE

See Market Exchange Emulator

Modify

The word “Modify” indicates that the content of a table column is modified within the Frame. The

content of the table column can only be changed in a Frame where the word “Modify” is specified.

When the original content of the table column must also be referenced or returned before it is modified, a “Reference” or a “Return” access method is also specified.

Must

The word “must” or the terms “required”, “requires”, “requirement” or “shall” in the specification, means that compliance is mandatory.

Must not

The phrase “must not” or the term “shall not” in the specification, means that this is an absolute

prohibition of the specification.

N ___________________________

(25)

A Native Data Type is a built-in data type of the DBMS whose documented purpose is to store data of

the type described in the specification for that attribute. For example, DATETIME must be

implemented with a built-in data type of the DBMS designed to store date-time information.

Network

Network – Sponsor provided functionality that must support communication through an industry

standard communications protocol using a physical means. One outstanding feature of the Connector –

Network – Connector communication is that it follows the relevant standards and must imply more

than just an application package. It must be possible to have concurrent use of the means by other applications. Physical transport of the data is required and the underlying means of this transport must be capable of operating over arbitrary globally geographic distances. TPC/IP over a local area network is an example of an acceptable Network implementation.

Nominal Throughput

The Nominal Throughput of the TPC-E benchmark is defined to be 2.00 Transactions-Per-Second-E

(tpsE) for every 1000 customer rows in the Configured Customers.

Non-catastrophic

The term Non-catastrophic as applied to a single failure is one where processing is not interrupted, but

throughput may be degraded and the SUT may no longer be in a durable state until the SUT has

recovered from the failure.

NUM(m[,n])

NUM(m[,n]) means an unsigned numeric value with at least m total Digits, of which n Digits are to the

right (after) the decimal point. The attribute must be able to hold all possible values which can be expressed as NUM(m[,n]). Omitting n, as in NUM(m), indicates the same as NUM(m,0). NUM must be

implemented using a Native Data Type.

O ___________________________

Operating System/OS

The term Operating System refers to the program that, after being initially loaded into the computer by

a boot program, manages all the other programs in a computer. The Operating System provides a

software platform on top of which all other programs run. Without the Operating System and the core

services that it provides no other programs can run and the computer would be non-functional. Other programs make use of the Operating System by making requests for services through a defined

application program interface (API). All major computer platforms require an Operating System. The functions and services supplied by an Operating System include but are not limited to the following:

Manages a dedicated set of processor and memory resources. Maintains and manages a file system.

Loads applications into memory.

Ensures that the resources allocated to one application are not used by another application in an unauthorized manner.

Determines which applications should run in what order, and how much time should be allowed to run the application before giving another application a turn to use the systems resources.

(26)

TPC Benchmark™ E - Standard Specification, Revision 1.0.0 - Page 26 of 264 Manages the sharing of internal memory among multiple applications.

Handles input and output to and from attached hardware devices such as hard disks, network interface cards etc.

Some examples of Operating Systems are listed below:

Windows

Unices (Solaris, AIX) Linux MS-DOS Mac OS VMS Netware P ___________________________ Pacing Delay

Pacing Delay is defined as the total time injected into the Dispatch Time (DTn) that is intended to decrease the rate at which Transactions are submitted to the SUT.

Part Number

See the definition of Part Number in the TPC Pricing Specification.

Performance Metric

The TPC-E Reported Throughput as expressed in tpsE. This is known as the Performance Metric.

Priced Configuration

Priced Configuration: The components to be priced defined in the benchmark specification, including

all hardware, software and maintenance.

Price/Performance Metric

The TPC-E total 3-year pricing divided by the Reported Throughput is price/tpsE. This is also known as the Price/Performance Metric.

Primary Key

A Primary Key is a single field or combination of fields that uniquely defines a record. None of the

fields that are part of the Primary Key can contain a null value. A table can have only one Primary Key.

Pseudo-code

Pseudo-code is a description of an algorithm that uses the structural conventions of programming

(27)

TPC Benchmark™ E - Standard Specification, Revision 1.0.0 - Page 27 of 264 Q ___________________________

R ___________________________

Ramp-down

Ramp-down: the period of time from the end of Steady State to the end of the Test Run.

Ramp-up

Ramp-up: the period of time from the start of the Test Run to the start of Steady State.

Redundancy Level One

Redundancy Level One: Guarantees access to the data on Durable Media when a single Durable Media failure occurs.

Redundancy Level Three

Redundancy Level Three: Includes Redundancy Level Two and guarantees access to the data on Durable Media when a single failure of a storage controller/interface card in the central processing complex occurs.

Redundancy Level Two

Redundancy Level Two: Includes Redundancy Level One and guarantees access to the data on Durable Media when a single failure in the processor/cache/controller of the Durable Media

enclosure occurs.

Reference

The word “Reference” indicates that the table column is identified in the database and the content is

accessed within the Frame without passing the content of the table column to the EGenTxnHarness.

Referential Integrity

Referential Integrity preserves the relationship of data between tables, by restricting actions performed

on primary and Foreign Keys in a table. Referential Integrity prevents removing rows containing Primary Keys that are referenced by Foreign Keys in other tables in the database. Referential Integrity

also prevents adding rows containing Foreign Keys that refer to Primary Keys whose rows are not

already present in the database. Referential Integrity does not allow modifications to Primary Key

columns of rows that are referenced by Foreign Keys in other tables in the database.

(28)

The word “Remove” indicates that a number of rows are removed from the table specified by the Database Footprint. Table row(s) can only be removed in a Frame where the word “Remove” is

specified. The number of rows that are removed is specified in the second column of the Database Footprint with either “# row” for a fixed number of rows or “row(s)” for an unspecified number of rows.

Report

The term Report refers to the Adobe Acrobat PDF file in the Report folder in the FDR. The contents of

the Report are defined in Clause 9.

Reported

The term Reported refers to an item that is part of the FDR.

Response Time

The Response Time (RT) is defined by: RTn = eTn - sTn

where:

sTn and eT n are measured at the Driver;

sTn = time measured before the first byte of input data of the Transaction is sent by the Driver to the SUT; and

eTn = time measured after the last byte of output data from the Transaction is received by the

Driver from the SUT.

Comment: The resolution of the time stamps used for measuring Response Time must be at least 0.01

seconds.

Results

TPC-E Results are the Performance Metric, Price/Performance Metric.

Return

The word “Return” indicates that the table column is referenced and that its content is retrieved from

the database and passed to the EGenTxnHarness. The table column must be referenced in the same Frame where the word “Return” is specified. The content of the table column can only be passed to

subsequent Frames via the input and output parameters specified in the Frame parameters.

Rollback

The word “Rollback” indicates that the specified Frame contains a control operation that rolls back the Database Transaction. The explicit rolling back of a Database Transaction can only occur in a Frame

where the word “Rollback” is specified.

(29)

RT see Response Time.

S ___________________________

S_COUNT_T

S_COUNT_T is defined as NUM(12) and is used for holding the aggregate count of shares used in

many tables.

S_PRICE_T

S_PRICE_T is defined as ENUM(8,2) and is used for holding the value of a share price.

S_QTY_T

S_QTY_T is defined as SNUM(6) and is used for holding the quantity of shares per individual trade.

Scale Factor

The Scale Factor is the number of customer rows per single Transaction-Per-Second-E (tpsE). The Scale Factor for Nominal Throughput is 500.

Scaling Tables

Scaling Tables: These tables each have a cardinality that has a constant relationship to the cardinality of the CUSTOMER table. Transactions may update rows from these tables, but the table sizes remain

constant. The Scaling Tables – CUSTOMER_TAXRATE, WATCH_ITEM and WATCH_LIST are an

exception. During a Test Run, the Data-Maintenance Transaction adds one row to

CUSTOMER_TAXRATE and WATCH_LIST, and three rows to WATCH_ITEM.

SENUM

ENUM(m[,n]) or SENUM(m[,n]) means an exact numeric value (unsigned or signed, respectively). ENUM and SENUM are identical to NUM and SNUM, respectively, except that they must be

implemented using a Native Data Type which provides exact representation of at least n Digits of

precision after the decimal place.

Session

See Database Session.

SF

SF see Scale Factor.

(30)

The word “should” or the adjective “recommended”, mean that there might exist valid reasons in

particular circumstances to ignore a particular item, but the full implication must be understood and weighed before choosing a different course.

Should not

The phrase “should not”, or the phrase “not recommended”, means that there might exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

SNUM

SNUM(m[,n]) is identical to NUM(m[,n]) except that it can represent both positive and negative values. SNUM must be implemented using a Native Data Type.

Comment: A SNUM data type may be used (at the Sponsor’s discretion) anywhere a NUM data type is

specified.

Sponsor

See Test Sponsor.

Start

The word “Start” indicates that the specified Frame contains a control operation that starts a Database Transaction. The start of a Database Transaction can only occur in a Frame where the word “Start” is

specified.

Steady State

Steady State: the period of time from the end of the Ramp-up to the start of the Ramp-down.

Substitution

Substitution is defined as a deliberate act to replace components of the Priced Configuration by the Test Sponsor as a result of failing the availability requirements of the TPC Pricing Specification or

when the Part Number for a component changes.

Supporting Files

Supporting Files refers to the contents of the SupportingFiles folder in the FDR. The contents of this

folder, consisting of various source files, scripts, and listing files, are defined in Clause 9.

Sustainable

Sustainable: the performance over a given period of time (computed as the average throughput over that time) shows no significant variations.

(31)

SUT

SUT see System Under Test.

System Under Test

System Under Test (SUT) – is defined to be the sum of Tier A and Tier B.

T ___________________________

Test Sponsor

The Test Sponsor is the company officially submitting the Result with the FDR and will be charged the

filing fee. Although multiple companies may sponsor a Result together, for the purposes of the TPC‟s

processes the Test Sponsor must be a single company. A Test Sponsor need not be a TPC member. The

Test Sponsor is responsible for maintaining the FDR with any necessary updates or corrections. The Test Sponsor is also the name used to identify the Result.

Test Run

Test Run: the entire period of time during which Drivers submit and the SUT completes Transactions

other than Trade-Cleanup.

Test Run Graph

A graph of the Measured Throughput versus elapsed wall clock time measured in minutes must be reported for the entire Test Run. The x-axis represents the elapsed time from the Test Run start. The

y-axis represents the throughput in tpsE. A plot interval size of 1 minute must be used. The Ramp-up,

the Measurement Interval and Steady State must be identified on the graph.

Reported Throughput

The Performance Metricreported by TPC-E is the Reported Throughput. The name of the metric used

for the Reported Throughput of the SUT is tpsE. The value of this metric is based on the Measured Throughput and is bound by the Nominal Throughput limits of the SUT as described in Clause 6.6.7.2.

Tier A

Tier A – is defined to be all hardware and software needed to implement the down-stream Connector, EGenTxnHarness, Frame Implementation and Database Interface functional components.

Tier B

Tier B – is defined to be all hardware and software needed to implement the Database Server

functional component. This includes data storage media sufficient to satisfy the initial database population requirements of clause 2.6.1 and the Business Day growth requirements of clause 6.6.6.3 and clause 6.6.6.4.

(32)

The term TPC-Certified Auditor is used to indicate that the TPC has reviewed the qualification of the Auditor and has certified his/her ability to verify that benchmark Results are in compliance with this

specification. (Additional details regarding the Auditor certification process and the audit process can

be found in Section 9 of the TPC Policy document.)

TPC Defined Interface

A TPC Defined Interface is a C++ class member which is designed to exchange data (and transfer

execution control) between the Sponsor-provided Driver/SUT code and the TPC-provided Driver/SUT

code.

TRADE_T

TRADE_T is defined as NUM(15) and is used to hold trade identifier fields.

Transaction(s)

The TPC-E Transactions are at the heart of the workload. The core of each Transaction runs on the Database Server, but the logic of the Transaction interacts with several components of the benchmark environment.

A Transaction is composed of Harness-code and of the invocation of one or more Frames. The

Trade-Cleanup Transaction is an exception. Sponsors may but do not have to run the Trade-Cleanup

Transaction from EGenTxnHarness.

Transaction Mix

The Transaction Mix is composed of all Customer Initiated, Brokerage Initiated and Market Triggered Transactions.

Tunable Parameters

Tunable Parameters are parameters, switches or flags that can be changed to modify the behavior of

the product. Tunable Parameters apply to both hardware and software and are not limited to those

parameters intended for use by customers.

U ___________________________

U*x

U*x is used in this specification to refer to various UNIX and Linux flavors (e.g. UNIX, Linux, AIX,

Solaris).

Undo/Redo Log

Undo/Redo Log: records all changes made in data files. The Undo/Redo Log makes it possible to replay all the actions executed by the Database Management System. If something happens to one of the data

TPC BENCHMARK E. Standard Specification. Version Mail Ballot Draft. December Transaction Processing Performance Council (TPC)

TPC BENCHMARK

No Warranty

TOTHEMAXIMUMEXTENTPERMITTEDBYAPPLICABLELAW,THEINFORMATIONCONTAINEDHEREIN

COMPLETENESSOFRESPONSES,OFRESULTS,OFWORKMANLIKEEFFORT,OFLACKOFVIRUSES,ANDOF

DAMAGES.

Trademarks

Full Members

Document Revision History

Diagram Color-Coding Conventions

Implementation

Table of Contents

Clause 0 -- Preamble ... 10

Clause 2 -- Database Design, Scaling & Population ... 40

Clause 3 -- Transactions ... 64

Clause 4 -- Description of SUT, Driver, and Network ... 180

Clause 5 -- EGen ... 190

Clause 6 -- Execution Rules & Metrics ... 195

Clause 7 -- Transaction and System Properties (ACID) ... 213

Clause 8 -- Pricing ... 226

Clause 10 -- Independent Audit ... 240

Appendix A. EGen User’s Guide ... 248

Appendix C. TPC-E XML Schema Guide ... 262

Table of Figures

CLAUSE 0 -- PREAMBLE

General Implementation Guidelines

General Measurement Guidelines

CLAUSE 1 -- BENCHMARK OVERVIEW

NUMBERS _____________________

Accessibility

Application

Arbitrary Transaction

Auditor

BALANCE_T

Brokerage Initiated

Business Day

Catastrophic

Commit

Customer Emulator

Customer Initiated

Data-Maintenance Generator

Database Footprint

Data Growth

Database Server

Database Session

DATETIME

Digit

Driver

Durability

Durable Medium

EGenDriver

provides the core functionality necessary to implement a

EGenDriverMEE

provides the core functionality necessary to implement a

EGenDriverDM

provides the core functionality necessary to implement the

EGenDriverCE

EGenInputFiles

EGenLogger

EGenSourceFiles

EGenValidate

Executive Summary Statement

FIN_AGG_T

Fixed Space

Foreign Key

Free Space

Growing Space

IDENT_T

Initial Database Size

Load Unit

Market Exchange Emulator

Market Tables

Measured Throughput

Modify

Must not

Network

Nominal Throughput

NUM(m[,n])

Operating System/OS

Part Number