tpcc Feb'10

8/12/2019 tpcc Feb'10

1/132

TPC BENCHMARK C

Standard Specification

Revision 5.11

February 2010

Transaction Processing Performa nce Coun cil (TPC)www.tpc.org [email protected]

2010 Transaction Pr ocessing Performan ce Coun cil
http://www.tpc.org/http://www.tpc.org/http://www.tpc.org/

8/12/2019 tpcc Feb'10

2/132

TPC BenchmarkC - Stand ard Specification , Revision 5.11 - Page 2 of 130

Acknowledgments

The TPC acknowledges the substantial contribution of Franois Raab, consultant to the TPC-C subcommittee andtechnical editor of the TPC-C benchmark standard. The TPC also acknowledges the work and contributions of theTPC-C subcom m ittee mem ber comp anies: Amd ahl, Bull, CDC, DEC, DG, Fujitsu/ ICL, HP, IBM, Inform ix, Mips,Oracle, Sequen t, Sun , Sybase, Tand em, and Unisys.

TPC Membership(as of February 2010)

Full Members

Associate Memb ers
http://www.tta.or.kr/English/new/main/index.htmhttp://www.itom.com/http://www.ideasinternational.com/http://www.xsprada.com/http://www.vmware.com/http://www.vertica.com/http://www.unisys.com/http://www.teradata.com/http://www.syncsort.com/http://www.sybase.com/http://www.paraccel.com/http://www.oracle.com/http://www.netezza.com/http://www.nec.com/http://www.microsoft.com/http://www.microsoft.com/http://www.kickfire.com/http://www.intel.com/http://www.ingres.com/http://www.ibm.com/products/http://global.hitachi.com/http://global.hitachi.com/http://www.hp.com/http://www.greenplum.com/http://www.fusionio.com/http://www.fujitsu.com/http://www.dell.com/http://www.dell.com/http://www.bull.com/http://www.amd.com/

8/12/2019 tpcc Feb'10

3/132

8/12/2019 tpcc Feb'10

4/132


TPC Benchm ark , TPC-C, and tpmC are trademarks of the Transaction Processing Performance Council.

Permission to copy withou t fee all or p art of this material is granted p rovided that th e TPC copyright n otice, the titleof the publication, and its date appear, and notice is given that copying is by permission of the TransactionProcessing Performa nce Council. To copy otherw ise requ ires specific perm ission.

8/12/2019 tpcc Feb'10

5/132


TABLE OF CONTENTS

Ackn ow led gm ents .............................................................................................................................................. 2 TPC Mem bership ................................................................................................................................................. 2

TABLE OF CONTENTS ............................................................................................................................................. 5

Clau se 0: PREAMBLE ................................................................................................................................................ 7 0.1 Int rod uction ........................................................................................................................................ 7 0.2 General Implementation Guidelines ............................................................................................... 8 0.3 Gen era l Measurem ent Gu idelines ................................................................................................... 9

Clau se 1: LOGICAL DATABASE DESIGN ........................................................................................................... 10 1.1 Business and Application Environment ....................................................................................... 10 1.2 Database Entities, Relationship s, and Cha racte ristics ................................................................ 11 1.3 Table Layouts ................................................................................................................................... 11 1.4 Implem entation Rules ..................................................................................................................... 18 1.5 Integr ity Rules .................................................................................................................................. 19 1.6 Data Access Transparency Requirements .................................................................................... 20

Clause 2: TRANSACTION and TERMINAL PROFILES..................................................................................... 21 2.1 Defin ition of Term s ......................................................................................................................... 21 2.2 General Requ irem ents for Term inal I/ O ...................................................................................... 23 2.3 General Requirements for Transaction Profiles .......................................................................... 26 2.4 The New-Order Transaction .......................................................................................................... 28 2.5 The Pay ment Tran saction ............................................................................................................... 33 2.6 The Or der-Stat us Tran sact ion ........................................................................................................ 37 2.7 The Deliv ery Tran saction ............................................................................................................... 40 2.8 The Stock-Level Tran sact ion .......................................................................................................... 44

Clau se 3: TRANSACTION an d SYSTEM PROP ERTIES ..................................................................................... 47 3.1 The ACID Propert ies ....................................................................................................................... 47 3.2 Atom icity Requ irem ents ................................................................................................................. 47 3.3 Con sistency Requ irem ents ............................................................................................................. 48 3.4 Isolat ion Requ irem ents ................................................................................................................... 51 3.5 Du rability Requ irem ents ................................................................................................................ 57

Clau se 4: SCALING an d DATABASE POPULATION ........................................................................................ 61 4.1 Gen era l Scaling Rules...................................................................................................................... 61 4.2 Scaling Requ irem ent s ...................................................................................................................... 61 4.3 Database Pop ulat ion ....................................................................................................................... 64

Clau se 5: PERFORMAN CE METRICS and RESPON SE TIME .......................................................................... 69 5.1 Defin ition of Term s ......................................................................................................................... 69 5.2 Pacing of Transactions by Emulated Users .................................................................................. 69 5.3 Resp onse Time Defin ition .............................................................................................................. 73

5.4 Computation of Throughput Rating ............................................................................................. 73 5.5 Measurem ent Interval Requ irem ents ........................................................................................... 74 5.6 Requ ired Report ing ......................................................................................................................... 76 5.7 Primary Met rics ............................................................................................................................... 78

Clau se 6: SUT, DRIVER, and COMMUN ICATIONS DEFINITION ................................................................. 79 6.1 Mod els o f th e Target System .......................................................................................................... 79 6.2 Test Con figuration ........................................................................................................................... 80 6.3 System Un der Test (SUT) Defin ition ............................................................................................ 80 6.4 Driver Defin ition ............................................................................................................................. 80

8/12/2019 tpcc Feb'10

6/132


6.5 Communications Interface Definitions ......................................................................................... 81 6.6 Furt her Requ irem ent s on the SUT an d Drive r System ............................................................... 81

Clau se 7: PRICIN G ................................................................................................................................................... 85 7.1 Pricing Methodology....................................................................................................................... 85 7.2 Priced System ................................................................................................................................... 85 7.3 Requ ired Report ing ......................................................................................................................... 88

Clau se 8: FULL DISCLOSURE ................................................................................................................................ 89 8.1 Full Disclosure Report Requirements ........................................................................................... 89 8.3 Revisions to the Full Disclosure Report ....................................................................................... 98

Clau se 9: AUDIT ..................................................................................................................................................... 100 9.1 Gen era l Rules ................................................................................................................................. 100 9.2 Au ditor 's check list ........................................................................................................................ 100

Index 105

Ap pendix A: SAMPLE PROG RAMS ................................................................................................................... 108 A.1 The New-Order Transaction ........................................................................................................ 108 A.2 The Pay ment Tran saction ............................................................................................................. 110 A.3 The Or der-Stat us Tran sact ion ...................................................................................................... 112 A.4 The Deliv ery Tran saction ............................................................................................................. 114 A.5 The Stock-Level Tran sact ion ........................................................................................................ 116 A.6 Sam ple Loa d Program .................................................................................................................. 117

Ap pendix B: EXECUTIVE SUMMA RY STATEMENT ...................................................................................... 130

Ap pendix C: N UMERICAL QUANTITIES SUMMA RY ................................................................................... 132

8/12/2019 tpcc Feb'10

7/132


Clause 0: PREAMBLE

0.1 Introduction

TPC BenchmarkC (TPC -C) is an OLTP workload. It is a mixture of read-only and update intensive transactionsthat simulate the activities found in complex OLTP application environments. It does so by exercising a breadth ofsystem comp onents associated with such environmen ts, which are characterized by:

The simultaneous execution of multiple transaction types that span a breadth of comp lexity

On-line and deferred transaction execution modes

Multip le on-line term inal sessions

Moderate system and app lication execution time

Significant disk input/ output

Transaction integrity (ACID prop erties)

Non-un iform distribution of data access through p rimary and secondary keys

Databases consisting of man y tables with a w ide variety of sizes, attributes, and relationships

Contention on data access and upd ate

The performance metric reported by TPC-C is a "business throughput" measuring the number of orders processed per minute. Mu ltiple tr an sact ion s are used to sim ulat e th e bu sin ess act ivity of processing an order, an d eachtransaction is subject to a response time constraint. The performance metric for this benchmark is expressed intransactions-per-minute-C (tpmC). To be compliant with the TPC-C standard, all references to TPC-C results mustinclud e the tp mC rate, the associated p rice-per-tpmC, and the availability date of the priced configuration.

To be compliant with the optional TPC-Energy standard, the additional primary metric, expressed as watts-per-tpm C mu st be reported. The requirements of the TPC-Energy Specification can be found at ww w.tpc.org.

Although these specifications express implementation in terms of a relational data mod el with conventional lockingscheme, the database m ay be imp lemented u sing any com mercially available d atabase managem ent system (DBMS),database server, file system, or other data repository that provides a functionally equivalent implementation. Theterm s "table", "row ", and "colum n" are used in th is docum ent only as examp les of logical da ta structu res.

TPC-C uses terminology and metrics that are similar to other benchmarks, originated by the TPC or others. Suchsimilarity in terminology does not in any way imply that TPC-C results are comparable to other benchmarks. Theonly benchmark results comp arable to TPC-C are other TPC-C results conformant with the sam e revision.

Despite the fact that this benchmark offers a rich en vironment that em ulates many OLTP app lication s, this benchmark does not reflect th e en tir e range of OLTP requ irem ents. In ad d ition , t he exten t to which a custom er canachieve the results reported by a vendor is highly dependent on how closely TPC-C approximates the customerapplication. The relative performance of systems derived from this benchmark does not necessarily hold for otherworkloads or environments. Extrapolations to any other environm ent are not recomm ended .

8/12/2019 tpcc Feb'10

8/132


Benchmark results are highly depend ent up on w orkload, specific application requirements, and systems d esign an dimplementation. Relative system performance will vary as a result of these and other factors. Therefore, TPC-Cshould not be u sed as a su bstitute for a specific custom er app lication benchm arking wh en critical capacity plan ningand / or product evaluation decisions are contemplated.

Benchmark sp onsors are perm itted several possible system designs, insofar as they ad here to th e mod el describedand pictorially illustrated in Clause 6. A Full Disclosure Report of the implementation details, as specified in Clause8, mu st be mad e available along w ith the reported results.

Comment: While separated from the main text for readability, comments are a part of the standard and must beenforced. How ever, the samp le programs, included as Ap pend ix A, the summ ary statements, included as Ap pend ixB, and the numerical quantities summary, included as Appendix C, are provided only as examples and arespecifically not part of this standard.

0.2 General Implementation Guidelines

The pur pose of TPC benchm arks is to provid e relevan t, objective perform ance data to indu stry users. To achievethat p urp ose, TPC benchmark specifications require that benchm ark tests be imp lemented w ith systems, produ cts,technologies and pricing that:

Are generally available to users.

Are relevant to the market segment that th e individual TPC benchmark m odels or represents (e.g. TPC -Amod els and rep resents high-volum e, simp le OLTP environm ents).

A significant nu mber of users in the market segment the benchmark m odels or represents would plausiblyimplement.

The use of new systems, products, technologies (hardware or software) and pricing is encouraged so long as theym eet the requirem ents above. Specifically proh ibited are benchm ark systems, prod ucts, technologies, pricing(hereafter referred to as "imp lementations") wh ose primary pu rpose is performance optim ization of TPC benchmarkresults without any correspond ing app licability to real-world ap plications and environm ents. In other words, all"benchmark sp ecials," implementations th at imp rove benchmark r esults but n ot real-world performance or pr icing,are p rohibited.

The following characteristics should be used as a guide to judge whether a particular implementation is a benchmark sp ecial. It is not requ ired th at each poin t below be met , b ut th at th e cum ulat ive weight of th e evid ence be con sid ered to id en tify an unacceptable im plem entation. Absol u te cer ta in ty or cer ta inty beyond a reasonabledou bt is not required to make a jud gment on this comp lex issue. The question th at mu st be answered is this: basedon th e available evidence, does the clear prep onderan ce (the greater share or w eight) of evide nce indicate that thisimplementation is a benchmark special?

The following characteristics should be u sed to jud ge wh ether a particular implementation is a benchmark special:

Is the imp lementation generally available, docum ented, and sup ported?

Does the imp lemen tation have significant restrictions on its use or app licability tha t limits its use beyond TPC benchmar ks?

Is the implementation or part of the implementation poorly integrated into the larger produ ct?

Does the imp lemen tation take special adv anta ge of the limited natu re of TPC benchm arks (e.g., tran saction profile, tr an saction mix, tr an saction con currency an d/ or con tention, tr an saction isolat ion ) in a man ner th atwou ld not be generally applicable to the en vironment th e benchm ark represents?

8/12/2019 tpcc Feb'10

9/132


Is the use of the implementation discouraged by the vend or? (This includes failing to promote theimplementation in a mann er similar to other prod ucts and technologies.)

Does the implementation require uncommon soph istication on the part of the end -user, program mer, orsystem adm inistrator?

Is the pricing unu sual or non-customary for the vendor or unu sual or non -customary to normal business pra ctices? See the cu rren t r evision of the TPC Pricing Sp ecification for add ition al inform at ion .

Is the implemen tation being used (includ ing beta) or pu rchased by end -users in the market area the benchmar k represen ts? H ow m an y? Mu ltiple sites? If th e im plem en tation is not curren tly being used byend -users, is there any evid ence to ind icate that it will be used by a significant n um ber of users?

0.3 General Measurement Guidelines

TPC benchmark results are expected to be accurate representations of system performance. Therefore, there arecertain guidelines which are expected t o be followed wh en m easuring those results. The app roach or method ology isexplicitly outlined in or d escribed in t he specification.

The approach is an accepted is an accepted engineering practice or standard . The app roach does not enhance the result.

Equipment u sed in measuring results is calibrated according to established quality standard s.

Fidelity and candor is maintained in reporting an y anom alies in the results, even if not specified in the benchmar k requirem ents.

The use of new meth odologies and app roaches is encouraged so long as they meet the requirements above.

8/12/2019 tpcc Feb'10

10/132


Clause 1: LOGICAL DATABASE DESIGN

1.1 Business and Appl ication Environment

TPC BenchmarkC is comprised of a set of basic operations designed to exercise system functionalities in a mannerrepresentative of complex OLTP application environments. These basic operations have been given a life-likecontext, portraying the activity of a wholesale supplier, to help users relate intuitively to the components of the

benchmark. The workload is cen tered on th e act ivity of processing orders an d p rovides a log ical database design ,wh ich can be d istributed without structural changes to transactions.

TPC-C does not represent the activity of any particular business segment, but rather any industry which mustmanage, sell, or distribute a product or service (e.g., car rental, food distribution, parts supplier, etc.). TPC-C doesnot attemp t to be a model of how to build an actual app lication .

The purp ose of a benchmark is to reduce the d iversity of operations found in a prod uction application , while

retaining the application's essential performance characteristics, namely: the level of system utilization and thecomplexity of operations. A large number of functions have to be performed to manage a production order entrysystem. Many of these functions are not of primary interest for performance analysis, since they are proportionallysma ll in term s of system resou rce utilization or in term s of frequency of execution. Althou gh th ese fun ctions are vitalfor a production system, they merely create excessive diversity in the context of a standard benchmark and have

been om itt ed in TPC-C.

The Company portrayed by the benchmark is a wholesale supplier with a number of geographically distributedsales districts and associated warehouses. As the Company's business expands, new warehouses and associatedsales districts are created . Each regional w arehou se covers 10 districts. Each d istrict serves 3,000 custom ers. Allwarehouses maintain stocks for the 100,000 items sold by the Company. The following diagram illustrates thewarehou se, district, and customer hierarchy of TPC-C's business environment.

Customers

Company

Warehouse-1

Dis trict-10

Warehouse-W

Dis trict-1 Dis tric t-2

3k1 2 30k

8/12/2019 tpcc Feb'10

11/132


Customers call the Comp any to p lace a new order or requ est the status of an existing order. Ord ers are comp osed ofan a verage of 10 ord er lines (i.e., line item s). One p ercent of all ord er lines are for items not in -stock at th e regionalwarehou se and m ust be supp lied by another warehouse.

The Company's system is also used to enter payments from customers, process orders for delivery, and examinestock levels to identify potential supply shortages.

1.2 Database Entities , Relationships, and Characteristics

1.2.1 The comp onen ts of the TPC-C da tabase are defined to consist of nine separat e and ind ividu a l tables.The relationships among these tables are defined in the entity-relationship d iagram show n below an d are subject tothe r ules specified in Clau se 1.4.

Wa rehouse Dis trict

His tory

Customer New-Order

Order Order-LineItem

Stock

W W*10

3k

1+

W*30k

W*30k+5-15

0-1

1+W*30k+

W*9k+

W*300k+

3+

100k

W

W*100k

100k

10

Legend :

All num bers shown illustrate the database population requirements (see Clause 4.3).

The num bers in the entity blocks represent the cardinality of the tables (num ber of rows). These num bers arefactored by W, the nu mb er of Warehouses, to illustr ate the d atabase scaling. (see Clau se 4).

The numbers next to the relationship arrows represent the cardinality of the relationships (average num ber ofchildren per p arent).

The plus (+) sym bol is used after the card inality of a relationship or table to illustrat e that this num ber issubject to small variations in the initial database population over the measurement interval (see Clause 5.5) asrows are added or d eleted.

1.3 Table Layouts

1.3.1 The following list defines th e m inimal structu re (list of attribu tes) of each table wh ere:

N unique IDs means that the attribute must be able to hold any one ID within a minimum set of N uniqueIDs, regard less of the p hysical representat ion (e.g., binary, p acked d ecima l, alph abetic, etc.) of the att ribute.

variable text, size N m eans that th e attribute mu st be able to hold any string of characters of a variable lengthwith a maximu m length of N. If the attribute is stored as a fixed length string and the string it h olds is shorterthan N characters, it must be pad ded with spaces.

8/12/2019 tpcc Feb'10

12/132


fixed text, size N m eans that th e attribute mu st be able to hold an y string of characters of a fixed length of N.

date and time represents the data type for a date value th at includes a time compon ent. The date comp onentmu st be able to hold an y date between 1 st Janu ary 1900 and 31 st Decemb er 2100. The time comp onent m ust becapable of representing the range of time values from 00:00:00 to 23:59:59 with a resolution of at least onesecond. Date and Time mu st be imp lemented u sing data types that are defined by the DBMS for that use.

numeric(m [,n]) mean s an un signed nu meric value w ith at least m total decimal digits, of which n digits areto the right (after) the decim al point. The attribute m ust be able to hold all possible values wh ich can beexpressed as nu meric(m,n). Om itting n, as in num eric(m), ind icates the same as nu mer ic(m,0). Nu m ericfields that contain monetary values (W_YTD, D_YTD, C_CREDIT_LIM, C_BALANCE, C_YTD_PAYMENT,H_AMOUNT, OL_AMOUNT, I_PRICE) must use data types that are defined by the DBMS as being an exactnum eric data type or that satisfy the ANSI SQL Stand ard definition of being an exact num eric representation.

signed numeric(m [,n]) is identical to numeric(m [,n]) except that it can represent both positive and negativevalues.

null means out of the range of valid values for a given attribute and always the same value for that attribute.

Comment 1 : For each table, the following list of attributes can be implemented in any order, using any physical

representation available from th e tested system.

Comment 2 : Table and a ttribute nam es are used for illustration pu rposes only; different nam es may be u sed by th eimplementation.

Comment 3 : A signed numeric data type may be used (at the sponsor s discretion) anywhere a numeric data typeis defined.

WAREHOUSE Table Layout

Field Nam e Field Definition Comm ents

W_ID 2*W un iqu e IDs W W arehouses are populated

W_NAME variable text, size 10

W_STREET_1 var iable text, size 20

W_STREET_2 var iable text, size 20

W_CITY var iable text, size 20

W_STATE fixed text, size 2

W_ZIP fixed text, size 9

W_TAX signed nu meric(4,4) Sales tax

W_YTD signed nu meric(12,2) Y ear to date balance

Prima ry Key: W_ID

8/12/2019 tpcc Feb'10

13/132


DISTRICT Table Layout


D_ID 20 un ique IDs 10 are populated per warehouse

D_W_ID 2*W un iqu e IDs

D_NAME variable text, size 10D_STREET_1 var iable text, size 20

D_STREET_2 var iable text, size 20

D_CITY var iable text, size 20

D_STATE fixed text, size 2

D_ZIP fixed text, size 9

D_TAX signed nu meric(4,4) Sales tax

D_YTD signed nu meric(12,2) Y ear to date balance

D_NEXT_O_ID 10,000,000 un ique IDs N ext available Order number

Primary Key: (D_W_ID, D_ID)

D_W_ID Foreign Key, references W_ID

8/12/2019 tpcc Feb'10

14/132


CUSTOMER Table Layout


C_ID 96,000 un iqu e IDs 3,000 are populated per district

C_D_ID 20 un ique IDs

C_W_ID 2*W un iqu e IDsC_FIRST var iable text, size 16

C_MIDDLE fixed text, size 2

C_LAST var iable text, size 16

C_STREET_1 var iable text, size 20

C_STREET_2 var iable text, size 20

C_CITY var iable text, size 20

C_STATE fixed text, size 2

C_ZIP fixed text, size 9

C_PHON E fixed text, size 16C_SINCE date and time

C_CREDIT fixed text, size 2 "GC"=good, "BC"=bad

C_CREDIT_LIM signed nu meric(12, 2)

C_DISCOUN T signed nu mer ic(4, 4)

C_BALAN CE signed nu m eric(12, 2)

C_YTD_PAYMENT signed nu meric(12, 2)

C_PAYMENT_CNT numeric(4)

C_DELIVERY_CNT numeric(4)

C_DATA var iable text, size 500 M iscellaneous in formation

Prim ary Key: (C_W_ID, C_D_ID, C_ID)

(C_W_ID, C_D_ID) Foreign Key, referen ces (D_W_ID, D_ID)

8/12/2019 tpcc Feb'10

15/132


HISTORY Table Layout


H_C_ID 96,000 un iqu e IDs

H_C_D_ID 20 un ique IDs

H_C_W_ID 2*W un ique IDsH_D_ID 20 un ique IDs

H_W_ID 2*W un ique IDs

H_DATE date and time

H_AMO UN T signed nu mer ic(6, 2)

H_DATA variable text, size 24 M iscellaneous in formation

Primary Key: none

(H_C_W_ID, H_C_D_ID, H_C_ID) Foreign Key, references (C_W_ID, C_D_ID, C_ID)

(H_W_ID, H_D_ID) Foreign Key , references (D_W_ID, D_ID)

Comment : Rows in the History table do not have a p rimary key as, within the context of the benchmark, there is no need to uniqu ely iden tify a r ow with in th is tab le.

Note: The TPC-C application does not have to be capable of utilizing the increased range of C_IDvalues beyond 6,000.

NEW-ORDER Table Layout


NO_O _ID 10,000,000 unique IDs

NO_D _ID 20 unique IDs

NO_W _ID 2*W u nique IDs

Prima ry Key: (NO_W_ID, NO_D_ID, N O_O_ID)

(NO_W_ID, NO_D_ID, NO_O_ID) Foreign Key, references (O_W_ID, O_D_ID, O_ID)

8/12/2019 tpcc Feb'10

16/132


ORDER Table Layout


O_ID 10,000,000 un iqu e IDs

O_D_ID 20 un ique IDs

O_W_ID 2*W un iqu e IDsO_C_ID 96,000 un iqu e IDs

O_ENTRY_D da te and time

O_CARRIER_ID 10 un ique IDs, or nu ll

O_OL_CNT numeric(2) Count of Order-Lines

O_ALL_LOCAL numeric(1)

Primary Key: (O_W_ID, O_D_ID, O_ID)

(O_W_ID, O_D_ID, O_C_ID) Foreign Key, referen ces (C_W_ID, C_D_ID, C_ID)

ORDER-LINE Table Layout


OL_O_ID 10,000,000 un iqu e IDs

OL_D_ID 20 un ique IDs

OL_W_ID 2*W un iqu e IDs

OL_NUMBER 15 un ique IDs

OL_I_ID 200,000 un iqu e IDs

OL_SUPPLY_W_ID 2*W un iqu e IDsOL_DELIVERY_D da te and time, or nu ll

OL_QUANTITY numeric(2)

OL_AMOUN T signed nu mer ic(6, 2)

OL_DIST_INFO fixed text, size 24

Prim ary Key: (OL_W_ID, OL_D_ID, OL_O_ID, OL_NUM BER)

(OL_W_ID, OL_D_ID, OL_O_ID) Foreign Key, references (O_W_ID, O_D_ID, O_ID)

(OL_SUPPLY_W_ID, OL_I_ID) Foreign Key, references (S_W_ID, S_I_ID)

8/12/2019 tpcc Feb'10

17/132


ITEM Table Layout


I_ID 200,000 un iqu e IDs 100,000 it ems are populated

I_IM_ID 200,000 un iqu e IDs Image ID associated to Item

I_NA ME variable text, size 24I_PRICE nu meric(5, 2)

I_DATA var iable text, size 50 Brand information

Prima ry Key: I_ID

STOCK Table Layout


S_I_ID 200,000 un iqu e IDs 100,000 populated per warehouse

S_W_ID 2*W un iqu e IDs

S_QUAN TITY signed nu mer ic(4)

S_DIST_01 fixed text , size 24







S_DIST_08 fixed text , size 24S_DIST_09 fixed text , size 24


S_YTD numeric(8)

S_ORDER_CNT numeric(4)

S_REMOTE_CNT numeric(4)

S_DATA var iable text, size 50 M ake information

Prim ary Key: (S_W_ID, S_I_ID)

S_W_ID Foreign Key, referen ces W_ID

S_I_ID Foreign Key, referen ces I_ID

8/12/2019 tpcc Feb'10

18/132


1.4 Implementation Rules

1.4.1 The ph ysical clustering of records with in the da tabase is allowed .

1.4.2 A view wh ich represents the rows to avoid logical read/ writes is excluded .

Comment : The intent of this clause is to insure that the application implements the number of logical operationsdefined in th e transaction p rofiles w ithout combining several operations in on e, via the use of a view.

1.4.3 All tables mu st have the properly scaled nu mber of rows as defined by the database popu lationrequ iremen ts (see Clause 4.3).

1.4.4 Hor izontal par titioning of tables is allowed . Group s of row s from a table m ay be assigned to differentfiles, disks, or areas. If imp lement ed, the d etails of such p artitioning m ust be d isclosed.

1.4.5 Vertical par titioning of tables is allowed . Grou ps of attribu tes (colum ns) of one table ma y be assigned

to files, disks, or areas different from those storing the other attributes of that table. If implemented, the details ofsuch p artitioning m ust be d isclosed (see Clause 1.4.9 for limitations).

Comment : in th e two clauses abov e (1.4.4 and 1.4.5) assignm ent of d ata to d ifferent files, disks, or areas n ot based onknowledge of the logical structure of the d ata (e.g., knowledge of row or attribute boun daries) is not considered

par tit ion ing. For exam ple, d ist rib ution or strip p ing over multiple d isks of a physical file which sto res on e or morelogical tables is not considered partitioning as long as this distribution is done by the hardware or the operatingsystem withou t know ledge of the logical structure stored in the physical file.

1.4.6 Replication is allowed for all tables. All copies of tables wh ich a re replicated mu st m eet allrequ iremen ts for atomicity, consistency, and isolation as defined in Clau se 3. If imp lement ed, the details of suchreplication must be disclosed.

Comment : Only one copy of a replicated table n eeds to meet th e du rability requirements d efined in Clause 3.

1.4.7 Attributes may be add ed and / or du plicated from one table to another as long as these changes do notimprove performance.

1.4.8 Each attribu te, as described in Clause 1.3.1, mu st be logically discrete and ind epend ently accessible bythe data manager. For example, W_STREET_1 and W_STREET_2 cannot be implemented as two sub-parts of adiscrete attribute W_STREET.

1.4.9 Each attribu te, as described in Clause 1.3.1, mu st be accessible by the da ta m anager as a singleattribu te. For examp le, S_DATA cannot be im plem ented as two d iscrete attribu tes S_DATA_1 and S_DATA_2

8/12/2019 tpcc Feb'10

19/132


1.4.10 The primary key of each table mu st not directly represent the physical disk add resses of the row orany offsets thereof. The application may not reference rows using relative addressing since they are simply offsetsfrom the beginning of the storage space. This does not preclude hash ing schemes or other file organizations w hichhave provisions for adding, deleting, and modifying records in the ordinary course of processing. Exception: TheHistory table can u se relative add ressing but all other requ irements app ly.

Comment 1 : It is the intent of this clause tha t the ap plication p rogram (see Clause 2.1.7) executin g the tran saction, orsubmitting the transaction request, not use physical identifiers, but logical identifiers for all accesses, and contain nouser w ritten code wh ich tran slates or aids in the translation of a logical key to th e location within the table of theassociated r ow or r ows. For examp le, it is not legitimat e for the app lication to bu ild a "translation t able" of logical-to-

physical ad dresses and use it to en han ce p erforman ce.

Comment 2: Internal record or row identifiers, for examp le, Tup le IDs or cursors, may be used un der th e followingconditions:

1. For each tran saction executed , initial access to any row m ust be via the key(s) specified in the tran saction profile a nd no oth er at tr ibu tes. Initial access in cludes inser tion, d eletion, re tr ieval, an d update of an y row .

2. Clause 1.4.10 m ay not be violated.

1.4.11 While inserts and deletes are not perform ed on all tables, the system m ust not be configur ed to takespecial advan tage of this fact du ring the test. Although inserts are inherently limited by the storage space availableon the configured system, there m ust be no restriction on inserting in an y of the tables a minimu m n um ber of rowsequal to 5% of the table cardinality and with a key value of at least double the ran ge of key values present in thattable.

Comment: It is required that the space for the additional 5% table cardinality be configured for the test run and p riced (as stat ic sp ace per Clause 4.2.3) accord ingly . For systems where sp ace is con figu red an d dyn am icallyallocated at a later time, this space mu st be considered as allocated and includ ed as static space wh en p riced.

1.4.12 The minimu m decimal precision for any comp utation performed as part of the app lication programmu st be the maximu m d ecimal precision of all the individual items in that calculation.

1.4.13 Any other rules specified elsewhere in this docu m ent app ly to the imp lement ation (e.g., theconsistency rules in Clause 3.3).

1.4.14 The table attribu tes variable text, fixed text, da te and time, and nu mer ic m ust be imp lemen ted usingnative data typ es of the d ata managem ent system (i.e., not the app lication program ) whose documented purp ose isto store data of the type defined for the attribute. For example, date and time mu st be imp lemented w ith a nativedata typ e designed to store date and time information.

1.5 Integrity Rules

1.5.1 In any committed state, the primary key values mu st be un ique within each table. For example, in thecase of a horizontally partitioned table, primary key values of rows across all partitions m ust be u nique.

1.5.2 In any comm itted state, no ill-formed rows m ay exist in the da tabase. An ill-formed row occur s wh enthe value of any attributes cannot be determ ined. For examp le, in the case of a vertically partitioned table, a rowmu st exist in all the p artitions.

8/12/2019 tpcc Feb'10

20/132


1.6 Data Access Transparency Requirements

Data Access Transparency is the property of the system which removes from the application program anyknowledge of the location and access mechanisms of partitioned data. An implementation which uses verticaland / or horizontal partitioning must m eet the requirements for transparent d ata access described here.

No finite ser ies of test can prove th at th e system su pports com plete data access tr an sp ar ency. The requ irem ents below descr ibe th e m in im um cap ab ilit ies need ed to estab lish th at th e sy stem provid es t ransp aren t d ata a ccess.

Comment : The intent of this clause is to require that access to ph ysically and/ or logically partitioned data be p rovided d irectly and tr an sp aren tly by ser vices im plem en ted by com mercially a va ilable lay ers below th e application p rogram su ch as th e d ata/ file m an ager (DBMS), th e op erat ing system , th e h ardware, or a ny combin at ion of these .

1.6.1 Each of the nine tables described in Clause 1.3 m ust be ident ifiable by na mes wh ich have norelationship to the partitioning of tables. All data manipulation operations in the application program (see Clause2.1.7) mu st use only th ese nam es.

1.6.2 The system mu st prevent any data man ipulation operation performed using the nam es described in

Clause 1.6.1 which would result in a violation of the integrity rules (see Clause 1.5). For example: the system must p revent a non -TPC-C ap plication from com m itt ing th e inser tion of a row in a vert ically par titioned table unless all par tit ion s of th at row hav e been inser ted .

1.6.3 Using the nam es wh ich satisfy Clause 1.6.1, any arbitrary non -TPC-C app lication mu st be able toman ipulate any set of rows or column s:

Identifiable by any arbitrary condition supp orted by the und erlying DBMS

Using the names described in Clause 1.6.1 and using the same data m anipulation sem antics and syntax for alltables.

For example, the semantics and syntax used to up date an arbitrary set of rows in any one table mu st also be usable

wh en up dating anoth er arbitrary set of rows in any other table.

Comment : The intent is that the TPC-C application program uses general purpose mechanisms to manipulate datain the d atabase.

8/12/2019 tpcc Feb'10

21/132


Clause 2: TRANSACTION and TERMIN AL PROFILES

2.1 Definition of Terms

2.1.1 The term select as used in this specification refers to the action of identifying (e.g., referencing, poin tin g to) a row (or rows) in th e d atabase w ith ou t r equiring retrieva l of t he actu al con tent of th e id en tified row(s).

2.1.2 The term retrieve as u sed in th is specification refers to the a ction of accessing (i.e., fetching) th e valueof an attribute from th e database and p assing this value to the application program .

Note : Fields that corresp ond to dat abase attribu tes are in U PPERCASE. Other fields, such as fields used by t he SUT,or the RTE, for computations, or communication with the terminal, but not stored in the database, are in lowercaseitalics.

2.1.3 The term database transaction as used is this specification refers to a unit of work on the database

with full ACID properties as described in Clause 3. A business transaction is comprised of one or more databasetransactions. When u sed alone, the term transaction refers to a bu siness transaction.

2.1.4 The term [x .. y ] represents a closed range of values starting with x and ending with y .

2.1.5 The term randomly selected within [ x .. y ] means independently selected at random and uniformlydistributed between x and y , inclusively, with a mean of ( x+ y)/ 2, and with the same n um ber of digits of precision asshow n. For exam ple, [0.01 .. 100.00] has 10,000 un ique values, w hereas [1 ..100] has on ly 100 un ique values.

2.1.6 The term non-uniform random , used only for generating customer numbers, customer last names,and item numbers, means an independently selected and non-uniformly distributed random number over thespecified range of values [ x .. y]. This number must be generated by using the function NURand which produces

posit ion s with in th e range [ x .. y]. The results of NURand might have to be converted to produce a name or anu mber valid for the imp lementation.

NURa nd (A, x, y) = (((random (0, A) | random (x, y)) + C) % (y - x + 1)) + x

where:

exp-1 | exp-2 stands for the bitwise logical OR operation betw een exp-1 and exp-2

exp-1 % exp-2 stand s for exp -1 mod ulo exp-2

rand om(x, y) stand s for rand omly selected w ithin [ x .. y]

A is a constant chosen according to th e size of the ra nge [x .. y]for C_LAST, the ran ge is [0 .. 999] and A = 255for C_ID, the r an ge is [1 .. 3000] and A = 1023for OL_I_ID, the ra nge is [1 .. 100000] and A = 8191

C is a run -time constant ran dom ly chosen w ithin [0 .. A] that can be varied w ithout altering performance.The sam e C value, per field (C_LAST, C_ID, and OL_I_ID), must be u sed by a ll emu lated ter min als.

2.1.6.1 In ord er that the value of C used for C_LAST does not alter perform ance the following mu st be tru e:

Let C-Load be th e value of C used to generate C_LAST when p opulating the d atabase. C-Load is a valuein th e ran ge of [0..255] including 0 and 255.

8/12/2019 tpcc Feb'10

22/132


Let C-Run be th e value of C used to gen erate C_LAST for the measu remen t run .

Let C-Delta be the absolute valu e of the d ifference between C -Load an d C-Run. C-Delta m ust be a value inthe ra nge of [65..119] includ ing th e values of 65 and 119 and exclud ing th e value of 96 and 112.

2.1.7 The term appli cation program refers to code that is not p art of the com mer cially available compon entsof the system, but produced specifically to implement the transaction profiles (see Clauses 2.4.2, 2.5.2, 2.6.2, 2.7.4,

and 2.8.2) of this benchmark. For example, stored procedures, triggers, and referential integrity constraints areconsidered p art of the app lication program wh en used to imp lement any portion of the transaction profiles, but arenot considered part of the application program when solely used to enforce integrity rules (see Clause 1.5) ortransparency requirements (see Clause 1.6) independently of any transaction profile.

2.1.8 The term terminal as used in this specification refers to the interface device capable of entering anddisplaying characters from an d to a u ser with a m inimum display of 24x80. A terminal is defined as th e comp onentsthat facilitate end -user inpu t and the display of the outpu t as defined in Clause 2. The terminal may not contain anyknowledge of the app lication except field format, typ e, and position.

8/12/2019 tpcc Feb'10

23/132


2.2 General Requirements for Terminal I/O

2.2.1 Input/Output Screen De finitions

2.2.1.1 The layout (position on the screen and size of titles and fields) of the inpu t/ outp ut screens, as definedin Clau ses 2.4.3.1, 2.5.3.1, 2.6.3.1, 2.7.3.1, and 2.8.3.1, must be rep rod uced by the te st sponsor as closely as possiblegiven the features and limitations of the implemented system. Any d eviation from the in pu t/ outpu t screens must beexplained.

2.2.1.2 Input/ outpu t screens may be altered to circumvent limitations of the implementation providing thatno p erforman ce advan tage is gained. H owever, the following ru les apply:

1. Titles can be tran slated into any langu age.

2. The seman tic content cannot be altered.

3. The nu m ber of individ ual fields cann ot be altered.

4. The num ber of characters within th e fields (i.e., field widt h) cann ot be decreased.

5. Reordering or repositionin g of fields is allowed .

6. A copy of the new screen specifications and layou t mu st be includ ed in the Full Disclosur e Report .

2.2.1.3 The am oun t and price fields defined in Clause 2 are formatted for U.S. currency. These formats can bemodified to satisfy different currency representation (e.g., use another currency sign, move the decimal pointretaining a t least one digit on its right).

2.2.1.4 For input / outp ut screens with unu sed fields (or group s of fields), it is not required to enter or displaythese fields. For example, when an order has less than 15 items, the groups of fields corresponding to the remainingitems on the inpu t/ outp ut screen are un used an d n eed not be entered or displayed after being cleared. Similarly,when selecting a customer using its last name, the customer number field is unused and need not be entered ordisplayed after being cleared.

2.2.1.5 All input and output fields that may change mu st be cleared at the beginning of each transaction evenwhen the same transaction type is consecutively selected by a given terminal. Fields should be cleared by displayingthem as spaces or zeros.

Comment: In Clauses 2.2.1.4 and 2.2.1.5, if the test sponsor does n ot pr omot e using space or zero as a clear characterfor its implementation, other clear characters can be used as long as a given field always uses the same clearcharacter.

2.2.1.6 A menu is used to select the next transaction type. The menu, consisting of one or more lines, must bedisplayed at the very top or at the very bottom of the inpu t/ outp ut screen. If an inpu t field is needed to enter them enu selection, it mu st be located on the line(s) reserved for the m enu .

Comment : The men u is in add ition to th e screen formats d efined in the term inal I/ O Clause for each transactiontype.

2.2.1.7 The men u mu st disp lay explicit text (i.e., it m ust contain the full nam e of each tran saction and theaction to be taken by the user to select each transaction). A minimum of 60 characters (excluding spaces) must bedisplayed on the menu.

8/12/2019 tpcc Feb'10

24/132


2.2.1.8 Any input and outpu t field(s), other than the man datory fields specified in the inpu t/ outp ut screensas defined in Clauses 2.4.3.1, 2.5.3.1, 2.6.3.1, 2.7.3.1, and 2.8.3.1, must be disclosed, and the purpose of such field(s)explained.

2.2.2 Entering and Disp layin g Fiel ds

2.2.2.1 A field is said to be entered once all the significant characters that comp ose the inp u t da ta for that fieldhave been commu nicated to th e SUT by the em ulated term inal.

2.2.2.2 A field is said to be disp layed once all significant characters that comp ose the d ata for that field hav e been com m unicat ed by th e SUT to th e em ulat ed term inal for d isp lay .

2.2.2.3 Comm un icating input and outpu t data does not require transferring any specific num ber of bytes.Methods for optimizing this comm unication, such as m essage compression an d data caching , are allowed.

2.2.2.4 The following features m ust be pr ovided to the emu lated user:

1. The inp ut characters appear on the inpu t/ outp ut screen (i.e., are echoed) as they are keyed in. Thisrequirement can be satisfied by visual inspection at full load where there are no perceivable delays.Oth erwise, it is requ ired that th e character echoing be verified by actual measu rem ents. For examp le, that can

be done usin g a protocol an aly zer, RTE m easuremen t, etc. t o sh ow th at th e echo resp on se tim e is less th an 1second . If local echo or block mod e devices are used th en verification is not requ ired.

Comment : A w eb browser imp lementation, or a terminal or PC emulating a terminal in either local echo or blockmod e, will meet the echo response time requ irement of one second, so th ere is no need for an echo test.

2. Inpu t is allowed on ly in the positions of an inp ut field (i.e., outpu t -only fields, labels, and blanks spaces onthe input/ output screen are p rotected from input).

3. Input-capable fields are designated by some method of clearly identifying them (e.g., highlighted areas,un der scores, reverse video, colum n d ividers, etc.).

4. It must be p ossible to key in only significant characters into fields. For alph anu meric fields, non -keyed positions must be tr an sla ted to bla nks or nulls. For numeric field s, keyed input of less th an th e m aximumallowable digits must be p resented right justified on th e outpu t screen.

5. All fields for w hich a value is necessary to allow the app lication to complete are required to contain inp ut prio r to th e sta rt of th e measu remen t of th e tr an saction RT, or th e ap plication must con ta in a set of err or -hand ling routines to inform the u ser that required fields have not been entered.

6. Fields can be keyed an d re-keyed in an y order. Specifically:

The emu lated user must be able to move the inpu t cursor forward and backward d irectly to the inputcapable fields.

The application cannot rely on fields being entered in any particular order.

The user can return to a field th at has been keyed in an d change its value prior to the start of themeasurem ent of the tran saction RT.

7. Nu meric fields m ust be protected from non -numeric inpu t. If one or more non-num eric characters is enteredin a nu meric field, a d ata entry error mu st be signaled to the u ser.

Comment : Inpu t validation m ay either be performed by th e terminal, by th e app lication, or a combination of both . Input va lid at ion requ ired by Item 5 an d Item 7 m ust occu r prio r to star tin g a database tr an saction .Specifically, invalid d ata entry m ay not result in a rolled back tran saction.

8/12/2019 tpcc Feb'10

25/132


2.2.2.5 All outp ut fields that display values that are up dated in the database by the current businesstran saction mu st display th e "new " (i.e., comm itted ) values for those fields.

8/12/2019 tpcc Feb'10

26/132


2.3 General Requirements for Transaction Profi les

Each transaction m ust be im plemented according to the sp ecified transaction profiles. In ad dition:

2.3.1 The order of the data manipu lations within the transaction bound s is imm aterial (unless otherw isespecified, see Clause 2.4.2.3), and is left to the latitude of the test sponsor, as long as the implemented transactionsare functionally equivalen t to those specified in the tra nsaction pr ofiles.

2.3.2 The tran saction pr ofiles specify m inima l da ta retrieval and up da te requ iremen ts for the tran sactions.Additional navigational steps or data manipulation operations implemented within the database transactions must

be d isclosed , an d th e p urp ose of su ch ad d ition (s) m ust be exp lained .

2.3.3 Each attribu te mu st be obtained from the designa ted table in the tran saction profiles.

Comment : The intent of this clause is to prevent reducing the number of logical database operations required toimplement each transaction.

2.3.4 No data man ipulation operation from the transaction profile can be performed before all input datahave been commu nicated to the SUT, or after any outp ut d ata have been comm un icated by the SUT to the emu latedterminal.

Comment : The intent of this clause is to ensu re that, for a given bu siness transaction , no data ma nipu lationoperation from the tran saction profile is performed prior to the tim estamp taken at the beginning of the TransactionRT or after the tim estamp taken a t the end of the Transaction RT (see Clause 5.3). For examp le, in th e New -Ordertransaction th e SUT is not allowed to fetch th e matching row from the CUSTOMER table until all input data have

been com m unicat ed to th e SUT, even if th is row is fet ched again later d urin g the execution of that same t ransact ion .

2.3.5 If tran sactions are rout ed or organ ized with in the SUT, a comm ercially available transaction

p rocessing m on itor or equivalent com m ercially av ailable software (herein after referred to as TM ) is requ ired withthe following features/ functionality:

Operation - The TM mu st allow for:

request/ service prioritization

mu ltiplexing/ de mu ltiplexing of requests/ services

autom atic load balancing

reception, queuing, and execution of mu ltiple requests/ services concurrently

Security - The TM must a llow for:

the ability to validate and a uth orize execution of each service at the time the service is requested.

the restriction of adm inistrative functions to authorized u sers.

Administration/Maintenance - The TM must have the predefined capability to perform centralized, non program mat ic (i.e., must be im plem en ted in th e sta ndard product an d not requ ire program ming) anddynamic configuration management of TM resources including hardware, network, services (single orgroup), queue m anagement prioritization ru les, etc.

Recovery - The TM mu st have th e capability to:

8/12/2019 tpcc Feb'10

27/132


post error codes to an application

detect and term inate long-run ning transactions based on predefined time-out intervals

Application Transparency - The message context(s) that exist between the client and server application program s m ust be man aged solely by th e TM . The clien t a nd server a pplication program s m ust not ha ve an yknowledge of the m essage context or the un derlying comm unication m echanisms that su pp ort that context.

Comment 1: The following are examples of imp lementations that are non -comp liant w ith the ApplicationTransparency requirement.

1. Client and server application programs use the same identifier (e.g., handle or pointer) to maintain themessage context for multiple transactions.

2. Change and/ or recomp ilation of the client and/ or server application programs is required wh en thenu mber of queues or equivalent d ata structures used by the TM to m aintain the message context betweenthe client and server application program s is changed by TM adm inistra tion.

Comment 2: The intent of this clau se is to encoura ge the use of general pu rp ose, comm ercially available tran sactionmon itors, and to exclude special pu rpose software d eveloped for benchm arking or other limited use. It isrecognized that implementations of features and functionality described above vary across vendors' architectures.

Such differences do not preclude compliance with the requirements of this clause.

Comment 3: Functionality of TM or equiva lent softw are is not requ ired if the DBMS m aintains an ind ividu al contextfor each em ulated u ser.

2.3.6 Any error that wou ld result in an invalid TPC-C transaction mu st be detected and reported. Aninvalid TPC-C transaction includes transactions that, if committed, would violate the level of databaseconsistency defined in Clause 3.3. These tran sactions m ust be rolled back. The detection of theseinvalid transactions must be reported to the user as part of the output screen or, in the case of thedeferred portion of the delivery transaction, the delivery log.

Comme nt 1: Some examp les of the types of errors which could result in an invalid transaction are:

Select or up da te of a non -existent record

Failure on insert of a n ew record

Failur e to delete an existing record

Failur e on select or up da te of an existing record

Comme nt 2: The exact information reported when an error occurs is implementation specific and not defined beyond th e requiremen t tha t a n error be rep orted .

8/12/2019 tpcc Feb'10

28/132


2.4 The New -Order Transaction

The New -Order business transaction consists of entering a complete order th rough a single database transaction . Itrepresents a mid-weight, read-write transaction with a high frequency of execution and stringent response timerequirements to satisfy on-line users. This transaction is the backbone of the workload. It is designed to place a

variable load on th e system to reflect on -line database activity as typ ically found in p rodu ction env ironments.

2.4.1 Input Data Generation

2.4.1.1 For any given terminal, the home warehou se num ber (W_ID) is constant over the wh ole measurem en tinterval (see Clause 5.5).

2.4.1.2 The district nu mb er (D_ID) is rand om ly selected w ithin [1 .. 10] from the hom e wa rehou se (D_W_ID =W_ID). The non -uniform r and om custom er nu m ber (C_ID) is selected using t he N URand (1023,1,3000) function fromthe selected d istrict nu mb er (C_D_ID = D_ID) and th e home w arehou se num ber (C_W_ID = W_ID).

2.4.1.3 The nu mb er of items in the ord er ( ol_cnt ) is rand om ly selected with in [5 .. 15] (an av erage of 10). Thisfield is not entered. It is generated by the terminal emulator to determine the size of the order. O_OL_CNT is laterdisplayed after being comp uted by the SUT.

2.4.1.4 A fixed 1% of the New -Order transactions are chosen at rand om to simulate user data entry errors andexercise the performance of rolling back upd ate transactions. This mu st be implemented by generating a rand omnumber rbk w ith in [1 .. 100].

Comment : All New -Order transactions mu st have independ ently generated inpu t data. The inpu t data from a rolled back t ransaction can not be used for a subsequen t t ra nsaction.

2.4.1.5 For each of the ol_cnt items on the ord er:

1. A non -uniform r and om item nu m ber (OL_I_ID) is selected u sing the N URand (8191,1,100000) fun ction. If thisis the last item on the order and rbk = 1 (see Clause 2.4.1.4), then the item nu m ber is set to an u nu sed valu e.

Comment : An unused value for an item number is a value not found in the database such that its use will produce a "not-found" cond ition w ithin the ap plication p rogram. This condition shou ld result in rolling backthe current database transaction.

2. A sup plying w arehou se num ber (OL_SUPPLY_W_ID) is selected as the hom e wareh ouse 99% of the tim e andas a remote wareh ouse 1% of the time. This can be implemented by generating a rand om num ber x within [1.. 100];

- If x > 1, the item is sup plied from the h ome w arehou se (OL_SUPPLY_W_ID = W_ID).

- If x = 1, the item is sup plied from a remote warehou se (OL_SUPPLY_W_ID is rand om ly selected with in therang e of active wareh ouses (see Clause 4.2.2) other th an W _ID).

Comment 1 : With an average of 10 items p er ord er, app roximately 90% of all ord ers can be sup plied in fu ll bystocks from the hom e warehou se.

Comment 2 : If the system is configured for a single warehouse, then all items are supplied from that singlehome warehouse.

3. A qu antity (OL_QUAN TITY) is rand om ly selected w ithin [1 .. 10].

8/12/2019 tpcc Feb'10

29/132


2.4.1.6 The ord er entry da te (O_ENTRY_D) is gener ated with in the SUT by using the curren t system da te andtime.

2.4.1.7 An ord er-line is said to be home if it is supplied by the home warehouse (i.e., whenOL_SUPPLY_W_ID equ als O_W_ID).

2.4.1.8 An ord er-line is said to be remote when it is supplied by a remote warehouse (i.e., whenOL_SUPPLY_W_ID does not equal O_W_ID).

2.4.2 Transaction Profi le

2.4.2.1 Entering a new ord er is don e in a single da tabase transaction with the following steps:

1. Create an order header, comp rised of:

2 row selections with data retrieval,

1 row selection with d ata retrieval and u pd ate,

2 row insertions.

2. Ord er a variable nu mb er of items (average ol_cnt = 10), comp rised of:

(1 * ol_cnt ) row selections with da ta retrieval,

(1 * ol_cnt ) row selections with data retrieval and u pd ate,

(1 * ol_cnt ) row insertions.

Note : The above summary is provided for information only. The actual requirement is defined by the detailedtransaction profile below.

2.4.2.2 For a given wa rehou se nu mb er (W_ID), district nu mb er (D_W_ID , D_ID), custom er nu mb er (C_W_ID, C_D_ID , C_ ID), count of items ( ol_cnt , not communicated to the SUT), and for a given set of items (OL_I_ID),

sup plying wa rehou ses (OL_SUPPLY_W_ID), and qu antities (OL_QUAN TITY):

The inp ut d ata (see Clause 2.4.3.2) are comm un icated to the SUT.

A database transaction is started.

The row in the WAREHO USE table with m atching W_ID is selected an d W_TAX, the wa rehou se tax r ate, isretrieved.

The row in th e DISTRICT table with m atching D_W_ID and D_ ID is selected, D_TAX, the district tax rate, isretrieved, and D_NEXT_O_ID, the next available order number for the district, is retrieved and incremented

by on e.

The row in the CUSTOMER table with m atching C_W_ID, C_D_ID, and C_ID is selected an d C_DISCOUN T,

the customer's discount rate, C_LAST, the customer's last name, and C_CREDIT, the customer's credit status,are retrieved.

A new row is inserted into both th e NEW-ORDER table and th e ORDER table to reflect the creation of thenew order . O_CARRIER_ID is set to a nu ll value. If the order includ es only hom e order -lines, thenO_ALL_LOCAL is set to 1, otherwise O_ALL_LOCAL is set to 0.

The nu m ber of items, O_OL_CNT, is comp uted to match ol_cnt.

8/12/2019 tpcc Feb'10

30/132


For each O_OL_CN T item on the order:

- The row in th e ITEM table with m atching I_ID (equ als OL_I_ID) is selected an d I_PRICE, the p ri ce of theitem, I_NAME, the name of the item, and I_DATA are retrieved. If I_ID has an unused value (see Clause2.4.1.5), a "not-found" condition is signaled, resulting in a rollback of the d atabase tran saction (see Clause2.4.2.3).

- The row in th e STOCK table w ith m atching S_I_ID (equals OL_I_ID) and S_W_ID (equ alsOL_SUPPLY_W_ID) is selected. S_QUANTITY, the quantity in stock, S_DIST_xx, where xx represents thedistrict number, and S_DATA are retrieved. If the retrieved value for S_QUANTITY exceedsOL_QUANTITY by 10 or more, then S_QUANTITY is decreased by OL_QUANTITY; otherwiseS_QUANTITY is updated to (S_QUANTITY - OL_QUANTITY)+91. S_YTD is increased byOL_QUANTITY and S_ORDER_CNT is incremented by 1. If the order-line is remote, thenS_REMOTE_CNT is incremen ted by 1.

- The amou nt for the item in the order (OL_AMOUNT) is comp uted as:

OL_QUANTITY * I_PRICE

- The strings in I_DATA and S_DATA are examined . If they both include the string "ORIGINAL", the brand- generic field for that item is set to "B", otherw ise, the brand-generic field is set to "G".

- A new row is inserted int o the ORDER-LINE table to reflect the item on th e order. OL_DELIVERY_D is setto a nu ll value, OL_NU MBER is set to a un ique v alue w ithin all the ORDER-LINE row s that ha ve the sam eOL_O_ID value, and OL_DIST_INFO is set to the content of S_DIST_xx, where xx represents the districtnu mb er (OL_D_ID)

The total-amount for the complete order is compu ted as:

sum (OL_AMOUNT) * (1 - C_DISCOU NT) * (1 + W_TAX + D_TAX)

The database transaction is comm itted, un less it has been rolled back as a result of an unused value for the lastitem nu m ber (see Clause 2.4.1.5).

The outp ut dat a (see Clause 2.4.3.3) are comm un icated to the termin al.

2.4.2.3 For tran sactions that rollback as a result of an un used item nu mb er, the comp lete tran saction profilemu st be executed with th e exception that th e following steps need not be d one:

Selecting and retrieving the row in the STOCK table with S_I_ID matching the un used item nu mber.

Examining the strings I_DATA and S_DATA for the unu sed item.

Inserting a new row into the ORDER-LINE table for the unu sed item.

Adding the amount for the unu sed item to th e sum of all OL_AMOUN T.

The transaction is not comm itted . Instead, the transaction is rolled back.

Comment 1 : The intent of this clause is to ensure th at w ithin the N ew -Order transaction all valid items are processed p rio r to processing th e u nused item . Kn ow led ge th at an item is u nused , resu lting in rollin g back th e t ra nsaction, canonly be used to skip execution of the above steps. No other op timization can resu lt from th is knowled ge (e.g.,skipp ing other step s, chan ging the execution of other steps, using a different typ e of tran saction, etc.).

Comment 2 : This clau se is an exception t o Clause 2.3.1. The ord er of data m anipu lation s prior to signa ling a "notfound" condition is im material.

8/12/2019 tpcc Feb'10

31/132


2.4.3 Termin al I/O

2.4.3.1 For each transaction the originating terminal mu st display the following inpu t/ outpu t screen with allinpu t and outpu t fields cleared (with either spaces or zeros) except for the Warehouse field w hich has not changedand mu st display the fixed W_ID value associated with that terminal.

New Order Warehouse: 9999 District: 99

Customer: 9999 Name: XXXXXXXXXXXXXXXX COrder Number: 99999999 Number of Lines: 99

Supp_W Item_Id Item Name9999 999999 XXXXXXXXXXXXXXXXXXXXXXXX9999 999999 XXXXXXXXXXXXXXXXXXXXXXXX9999 999999 XXXXXXXXXXXXXXXXXXXXXXXX9999 999999 XXXXXXXXXXXXXXXXXXXXXXXX9999 999999 XXXXXXXXXXXXXXXXXXXXXXXX9999 999999 XXXXXXXXXXXXXXXXXXXXXXXX9999 999999 XXXXXXXXXXXXXXXXXXXXXXXX9999 999999 XXXXXXXXXXXXXXXXXXXXXXXX9999 999999 XXXXXXXXXXXXXXXXXXXXXXXX9999 999999 XXXXXXXXXXXXXXXXXXXXXXXX9999 999999 XXXXXXXXXXXXXXXXXXXXXXXX9999 999999 XXXXXXXXXXXXXXXXXXXXXXXX9999 999999 XXXXXXXXXXXXXXXXXXXXXXXX9999 999999 XXXXXXXXXXXXXXXXXXXXXXXX9999 999999 XXXXXXXXXXXXXXXXXXXXXXXX

Execution Status: XXXXXXXXXXXXXXXXXXXXXXXX

1234567890123456789012345678901234567890123456789 1

23456789

101112131415161718192021222324

2.4.3.2 The emulated user mu st enter, in the app ropriate fields of the input/ outpu t screen, th e required inputdata w hich is divided in two group s and organized as follows:

Two fields: D_ID and C_ID.

Comment : The value for ol_cnt cannot be entered, but must be determined by the application upon processing o f th e in put d ata.

One r epeating group of fields: OL_I_ID, OL_SUPPLY_W_ID and OL_QUAN TITY. The grou p is rep eatedol_cnt times (once per item in the or der ). The values of these fields ar e chosen as per Clause 2.4.1.5.

Comment : In order to maintain a reasonable amount of keyed input, the supply warehouse fields must befilled in for each item, even wh en the sup ply wa rehouse is the home w arehouse.

2.4.3.3 The emulated terminal mu st display, in the app ropriate fields of the inpu t/ outpu t screen, all inpu tdata and the output data resulting from the execution of the transaction. The display fields are divided in twogroups as follows:

One non-repeating group of fields: W_ID, D_ID, C_ID, O_ID, O_OL_CNT, C_LAST, C_CREDIT,C_DISCOUNT, W_TAX, D_TAX, O_ENTRY_D, total_amount , and an optional execution status m essage otherthan "Item num ber is not valid".

8/12/2019 tpcc Feb'10

32/132


On e repea ting grou p of fields: OL_SUPPLY_W_ID, OL_I_ID, I_NA ME, OL_QUA NTITY, S_QUA NTITY,brand_generic, I_PRICE, and OL_AMOUNT. The group is repeated O_OL_CNT times (once per item in theorder), equal to the comp uted value of ol_cnt.

2.4.3.4 For tran sactions that are rolled back as a result of an un used item nu m ber (1% of all New -Ordertransactions), the emu lated terminal m ust d isplay in th e approp riate fields of the inpu t/ outpu t screen the fields:W_ID, D_ID, C_ID, C_LAST, C_CREDIT, O_ID, and the execution statu s m essage "Item nu m ber is not valid". Notethat no execution status message is required for successfully committed transactions. How ever, this field may notdisp lay "Item nu m ber is not valid" if the tra nsaction is successful.

Comment : The nu mber of the rolled back order, O_ID, mu st be displayed to verify that par t of th e transaction w as p rocessed .

2.4.3.5 The following table sum marizes the terminal I/ O requirements for the New -Order transaction:

Enter Display Display Coord inatesAfter rollback Row/ Column

Non -repeatin g W_ID W_ID 2/ 12Group D_ID D_ID D_ID 2/ 29C_ID C_ID C_ID 3/ 12

C_LAST C_LAST 3/ 25C_CREDIT C_CREDIT 3/ 52C_DISCOUNT 3/ 64W_TAX 4/ 51D_TAX 4/ 67O_OL_CNT 4/ 42O_ID O_ID 4/ 15O_ENTRY_D 2/ 61total-amount 22/ 71

"Item num ber 22/ 19is not valid "

Repea ting Grou p OL_SUPPLY_W_ID OL_SUPPLY_W_ID 7-22/ 3OL_I_ID OL_I_ID 7-22/ 10

I_NA ME 7-22/ 20OL_QUA NTITY OL_QUANTITY 7-22/ 45

S_QUA NTITY 7-22/ 51brand-generic 7-22/ 58I_PRICE 7-22/ 63OL_AMOUN T 7-22/ 72

2.4.3.6 For general term inal I/ O requirem ents, see Clause 2.2.

8/12/2019 tpcc Feb'10

33/132


2.5 The Payment Transaction

The Payment business transaction updates the customer's balance and reflects the payment on the district andwarehouse sales statistics. It represents a light-weight, read-write transaction with a high frequency of execution andstringent response time requirements to satisfy on-line users. In add ition, th is transaction includ es non-primary keyaccess to the CUSTOMER table.


2.5.1.1 For any given terminal, the home warehou se num ber (W_ID) is constant over the wh ole measurem entinterval.

2.5.1.2 The district nu mb er (D_ID) is rand om ly selected with in [1 ..10] from the hom e wa rehou se (D_W_ID) =W_ID). The customer is randomly selected 60% of the time by last name (C_W_ID , C_D_ID, C_LAST) and 40% ofthe time by number (C_W_ID , C_D_ID , C_ID). Independent of the mode of selection, the customer residentwarehou se is the home warehouse 85% of the time and is a rand omly selected rem ote warehou se 15% of the time.

This can be imp lemented by generating two ran dom num bers x an d y w ithin [1 .. 100];

If x 85 a customer is selected from a random district number (C_D_ID is randomly selected within [1 .. 10]),and a random remote warehouse number (C_W_ID is randomly selected within the range of activewarehouses (see Clause 4.2.2), and C_W_ID W_ID). The customer is paying through a warehouse and adistrict other than h is/ her own.

If y 60 a non -uniform r and om custom er nu mb er (C_ID) is selected usin g the N URand (1023,1,3000) function.The customer is using his/ her customer num ber.

Comment : If the system is configured for a single warehouse, then all customers are selected from that single homewarehouse.

2.5.1.3 The pay men t am oun t (H_AMOUN T) is ran dom ly selected w ithin [1.00 .. 5,000.00].

2.5.1.4 The paym ent date (H_DATE) in generated within the SUT by using the current system date and time.

2.5.1.5 A Paym ent tran saction is said to be home if the customer belongs to the warehouse from which the paym ent is en tered (when C_W_ID = W_ID).

2.5.1.6 A Paym ent tran saction is said to be remote if the warehouse from wh ich the p ayment is entered is notthe one to w hich the custom er belongs (when C_W_ID does no t equal W_ID).

8/12/2019 tpcc Feb'10

34/132



2.5.2.1 The Payment transaction enters a customer's paym ent with a single database transaction and iscomprised of:

Case 1 , the customer is selected based on customer nu mber:

3 row selections with d ata retrieval and up date,

1 row insertion.

Case 2 , the custom er is selected ba sed on custom er last nam e:

2 row selections (on average) with d ata retrieval,

3 row selections with d ata retrieval and u pd ate,

1 row insertion.

Note : The above summary is provided for information only. The actual requirement is defined by the detailedtransaction profile below.

2.5.2.2 For a given wa rehou se nu mb er (W_ID), district nu mb er (D_W_ID , D_ID), custom er nu m be r (C_W_ID, C_D_ID , C_ ID) or custom er last nam e (C_W_ID , C_D_ID , C_LAST), and p aym ent am oun t (H_AMOU NT):



The row in the WAREHOUSE table with matching W_ID is selected. W_NAME, W_STREET_1,W_STREET_2, W_CITY, W_STATE, and W_ZIP are retr ieved and W_YTD, the wareh ouse's year -to-dat e

balance, is increased by H_ AMO UN T.

The row in th e DISTRICT table w ith m atching D_W_ID and D_ID is selected . D_NAME, D_STREET_1,D_STREET_2, D_CITY, D_STATE, an d D_ZIP are retrieved and D_YTD, the d istrict's year -to-da te balan ce, isincreased by H_AMOUNT.

Case 1 , the customer is selected based on customer nu mber: the row in the CUSTOMER table w ith m atchingC_W_ID, C_D_ID and C_ID is selected. C_FIRST, C_MIDDLE, C_LAST, C_STREET_1, C_STREET_2, C_CITY,C_STATE, C_ZIP, C_PHON E, C_SINCE, C_CREDIT, C_CREDIT_LIM, C_DISCOU NT, and C_BALAN CE areretrieved. C_BALANCE is decreased by H_AMOUNT. C_YTD_PAYMENT is increased by H_AMOUNT.C_PAYMENT_CNT is increment ed by 1.

Case 2 , the customer is selected based on customer last name: all rows in the CUSTOMER table withmatching C_W_ID, C_D_ID and C_LAST are selected sorted by C_FIRST in ascending order. Let n be thenumber of rows selected. C_ID, C_FIRST, C_MIDDLE, C_STREET_1, C_STREET_2, C_CITY, C_STATE,C_ZIP, C_PHONE, C_SINCE, C_CREDIT, C_CREDIT_LIM, C_DISCOU NT, and C_BALAN CE are retrievedfrom the row at position ( n / 2 rounded up to the next integer) in the sorted set of selected row s from th eCUSTOMER table. C_BALANCE is decreased by H_AMOUNT. C_YTD_PAYMENT is increased byH_AMO UN T. C_PAYMENT_CNT is increm ented by 1.

If the valu e of C_CREDIT is equal to "BC", then C_DATA is also retrieved from the selected custom er and thefollowing history information: C_ID, C_D_ID, C_W_ID, D_ID, W_ID, and H_AMOUNT, are inserted at theleft of the C_DATA field by shifting the existing content of C_DATA to the right by an equ al nu m ber of bytesand by discarding the bytes that are shifted out of the right side of the C_DATA field. The content of theC_DATA field never exceeds 500 characters. The selected custom er is up da ted with the n ew C_DATA field. IfC_DATA is implemented as two fields (see Clause 1.4.9), they must be treated and operated on as one singlefield.

8/12/2019 tpcc Feb'10

35/132


Comment : The format u sed to store the history information mu st be such that its display on the input/ outp utscreen is in a readable format. (e.g. the W_ID portion of C_DATA must use the same display format as theoutp ut field W_ID).

H_DATA is built by concatenating W_NAME and D_NA ME separa ted by 4 spaces.

A new row is inserted into th e HISTORY table with H_C_ID = C_ID, H_C_D_ID = C_D_ID, H_C_W_ID =C_W_ID, H_D_ID = D_ID, and H_W_ID = W_ID.

The database transaction is comm itted.


2.5.3 Termin al I/O

2.5.3.1 For each transaction the originating terminal mu st display the following inpu t/ outpu t screen with allinpu t and outpu t fields cleared (with either spaces or zeros) except for the Warehouse field w hich has not changedand must display the fixed W_ID value associated with that terminal. In addition, all address fields (i.e.,W_STREET_1, W_STREET_2, W_CITY, W_STATE, and W_ZIP) of the warehouse may display the fixed values forthese fields if these values were already retrieved in a previous transaction.

PaymentDate: DD-MM-YYYY hh:mm:ss

Warehouse: 9999 DisXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXX XX XXXXX-XXXX XX Customer: 9999 Cust-Warehouse: 9999 Cust-D

Name: XXXXXXXXXXXXXXXX XX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XX XXXXX-XXXX

Amount Paid: $9999.99 New CustCredit Limit: $9999999999.99Cust-Data: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

1234567890123456789012345678901234567890123456789 1

23456789

101112131415161718192021222324

2.5.3.2 The emulated user mu st enter, in the app ropriate fields of the input/ outpu t screen, the requi red inpu tda ta w hich is organ ized a s the d istinct fields: D_ID, C_ID or C_LAST, C_D_ID, C_W_ID, and H_AMO UN T.

Comment : In ord er to maintain a reasonable amou nt of keyed inpu t, the customer w arehouse field m ust be filled ineven wh en it is the same as the hom e warehouse.

8/12/2019 tpcc Feb'10

36/132


2.5.3.3 The emulated terminal mu st display, in the app ropriate fields of the inpu t/ outpu t screen, all inpu tdata and the outp ut data resulting from the execution of the transaction. The following fields are d i splayed: W_ID,D_ID, C_ID, C_D_ID, C_W_ID, W_STREET_1, W_STREET_2, W_CITY, W_STATE, W_ZIP, D_STREET_1,D_STREET_2, D_CITY, D_STATE, D_ZIP, C_FIRST, C_MIDDLE, C_LAST, C_STREET_1, C_STREET_2, C_CITY,C_STATE, C_ZIP, C_PHONE, C_SINCE, C_CREDIT, C_CREDIT_LIM, C_DISCOUNT, C_BALANCE, the first 200characters of C_DATA (only if C_CREDIT = "BC"), H_AMOUNT, and H_DATE.

2.5.3.4 The following table sum marizes the terminal I/ O requirements for the Payment transaction:

Enter Display CoordinatesRow/ Column

Non -repeatin g Group W_ID 4/ 12D_ID D_ID 4/ 52C_ID 1 C_ID 9/ 11C_D_ID C_D_ID 9/ 54C_W_ID C_W_ID 9/ 33H_AMOUN T H_AMOUN T 15/ 24

H_DATE 2/ 7W_STREET_1 5/ 1W_STREET_2 6/ 1W_CITY 7/ 1W_STATE 7/ 22W_ZIP 7/ 25D_STREET_1 5/ 42D_STREET_2 6/ 42D_CITY 7/ 42D_STATE 7/ 63D_ZIP 7/ 66C_FIRST 10/ 9C_MIDDLE 10/ 26

C_LAST 2 C_LAST 10/ 29C_STREET_1 11/ 9C_STREET_2 12/ 9C_CITY 13/ 9C_STATE 13/ 30C_ZIP 13/ 33C_PHONE 13/ 58C_SINCE 10/ 58C_CREDIT 11/ 58C_CREDIT_LIM 16/ 18C_DISCOUN T 12/ 58C_BALAN CE 15/ 56

C_DATA 3 18-21/ 12

1 Enter only for paym ent by customer nu mber 2 Enter only for paym ent by customer last nam e 3 Disp lay th e first 200 chara cters on ly if C_CREDIT = "BC"

2.5.3.5 For general term inal I/ O requirem ents, see Clause 2.2.

8/12/2019 tpcc Feb'10

37/132


2.6 The Order-Status Transaction

The Order-Status bu siness transaction queries the status of a customer's last ord er. It represents a m id -weight read-only database transaction with a low frequency of execution a nd response time requirement to satisfy on-line u sers.In add ition, this table includes non -prim ary key access to the CUSTOMER table.


2.6.1.1 For any given terminal, the home warehou se num ber (W_ID) is constant over the wh ole measurem entinterval.

2.6.1.2 The district nu m ber (D_ID) is rand om ly selected with in [1 ..10] from the hom e wa rehou se. Thecustomer is randomly selected 60% of the time by last name (C_W_ID, C_D_ID, C_LAST) and 40% of the time bynumber (C_W_ID, C_D_ID, C_ID) from the selected district (C_D_ID = D_ID) and the home warehouse number(C_W_ID = W_ID). This can be im plem ented by generating a rand om num ber y within [1 .. 100];

If y 60 a non -uniform r and om custom er nu mb er (C_ID) is selected usin g the N URand (1023,1,3000) function.The customer is using his/ her customer nu mber.


2.6.2.1 Qu erying for the status of an ord er is don e in a single da tabase tran saction with the following steps:

1. Find the customer and his/ her last order, comprised of:Case 1 , the customer is selected based on customer nu mber:

2 row selections with data retrieval.

Case 2 , the custom er is selected ba sed on custom er last nam e:

4 row selections (on average) with d ata retrieval.

2. Check status (delivery date) of each item on the ord er (average items -per-order = 10), comp rised of:

(1 * items-per-ord er) row selections w ith d ata retr ieval.

Note : The above summary is provided for information only. The actual requirement is defined by the detailed

transaction profile below.

2.6.2.2 For a given custom er nu mber (C_W_ID , C_D_ID , C_ ID):



Case 1 , the customer is selected based on customer nu mber: the row in the CUSTOMER table w ith m atchingC_W_ID, C_D_ID, and C_ID is selected and C_BALANCE, C_FIRST, C_MIDDLE, and C_LAST are retrieved.

8/12/2019 tpcc Feb'10

38/132


Case 2 , the customer is selected based on customer last name: all rows in the CUSTOMER table withmatching C_W_ID, C_D_ID and C_LAST are selected sorted by C_FIRST in ascending order. Let n be thenumber of rows selected. C_BALANCE, C_FIRST, C_MIDDLE, and C_LAST are retrieved from the row at

position n / 2 round ed u p in th e sorted set of selected row s from the CUSTOMER table.

The row in the ORDER table with ma tching O_W_ID (equa ls C_W_ID), O_D_ID (equa ls C_D_ID), O_C_ID(equals C_ID), and with the largest existing O_ID, is selected. This is the most recent order placed by that

customer . O_ID, O_ENTRY_D, and O_CARRIER_ID a re retr ieved.

All rows in t he O RDER-LINE table with m atching O L_W_ID (equals O_W_ID), OL_D_ID (equals O_D_ID),and OL_O_ID (equals O_ID) are selected and the corresponding sets of OL_I_ID, OL_SUPPLY_W_ID,OL_QUANTITY, OL_AMOUNT, and OL_DELIVERY_D are retrieved.

The database transaction is comm itted.

Comment : a comm it is not required as long as all ACID prop erties are satisfied (see Clause 3).


2.6.3 Termin al I/O

2.6.3.1 For each transaction the originating terminal mu st display the following inpu t/ outpu t screen with allinpu t and outpu t fields cleared (with either spaces or zeros) except for the Warehouse field w hich has not changedand mu st display the fixed W_ID value associated with that terminal.

Order-Status Warehouse: 9999 District: 99

Customer: 9999 Name: XXXXXXXXXXXXXXXX XXCust-Balance: $-99999.99Order-Number: 99999999 Entry-Date: DD-MM-Supply-W Item-Id Qty Amount9999 999999 99 $99999.99

9999 999999 99 $99999.999999 999999 99 $99999.999999 999999 99 $99999.999999 999999 99 $99999.999999 999999 99 $99999.999999 999999 99 $99999.999999 999999 99 $99999.999999 999999 99 $99999.999999 999999 99 $99999.999999 999999 99 $99999.999999 999999 99 $99999.99

9999 999999 99 $99999.999999 999999 99 $99999.999999 999999 99 $99999.99

123456789012345678901234567890123456789012345678 1

23456789

101112131415161718192021222324

2.6.3.2 The emu lated user mu st enter, in the app ropriate field of the inpu t/ outpu t screen, the required inpu tda ta w hich is organized as the d istinct fields:

Date post:	03-Jun-2018
Category:	Documents
Upload:	arnab-mallick
View:	217 times
Download:	0 times

tpcc Feb'10

Documents