TPC BEN CHMARK™C
Standard Specification
Revision 5.11
February 2010
Transaction Processing Perform ance Cou ncil (TPC)
w w w .tp c.org
info@tp c.org
©2010 Transaction Processing Perform ance Cou ncil
Acknow ledgments
The TPC acknow led ges the su bstantial contribu tion of François Raab, consu ltant to the TPC -C su bcom m ittee and
technical ed itor of the TPC-C benchm ark stand ard . The TPC also acknow led ges the w ork and contribu tions of the
TPC-C su bcom m ittee m em ber com p anies: Am d ahl, Bu ll, CDC, DEC, DG, Fu jitsu / ICL, H P, IBM, Inform ix, Mip s,
Oracle, Sequ ent, Su n, Sybase, Tand em , and Unisys.
TPC Membership
(as of Febru ary 2010)
Full Members
Associate Members
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 2 of 130
D ocument History
Date
22 Ju ne 1992
13 Au gu st 1992
1 Ju ne 1993
20 October 1993
15 Febru ary 1995
4 Ju ne 1996
27 Au gu st 1996
12 Sep tem ber 1996
15 Janu ary 1997
6 Febru ary 1997
8 Ap ril 1997
9 Ap ril 1997
25 Ju ne 1997
16 Ap ril 1998
24 Au gu st 1998
25 Au gu st 1999
18 October 2000
6 Decem ber 2000
26 Febru ary 2001
11 Decem ber 2002
Version
Draft 6.6
Revision 1.0
Revision 1.1
Revision 2.0
Revision 3.0
Revision 3.1
Revision 3.2
Revision 3.2.1
Revision 3.2.2
Revision 3.2.3
Revision 3.3
Revision 3.3.1
Revision 3.3.2
Revision 3.3.3
Revision 3.4
Revision 3.5
Revision 5.0
Revision 5.0
Revision 5.0
Revision 5.1
11 Decem ber 2003
Revision 5.2
22 Ap ril 2004
Revision 5.3
21 Ap ril 2005
Revision 5.4
20 October 2005
Revision 5.5
8 Decem ber 2005
21 Ap ril 2006
14 Decem ber 2006
Revision 5.6
Revision 5.7
Revision 5.8
14 Ju ne 2007
Revision 5.9
17 Ap ril 2008
Revision 5.10
5 Febru ary 2009
11 Febru ary 2010
Revision 5.10.1
Revision 5.11
Descrip tion
Mail ballot version (p rop osed stand ard )
Stand ard sp ecification released to the p u blic
First m inor revision
First m ajor revision
Second m ajor revision
Minor changes to rev 3.1.
Changed m ix back to 3.0 valu es.
Fixed Mem ber list and ad d ed ind ex
Ad d ed w ord ing for TAB Id s #197, 221 & 224
Ad d ed w ord ing for TAB Id s #205, 222 & 226
N ew Clau ses 2.3.6 & 9.2.2.3 (TAB Id #225)
Word ing ad d ed for availability d ate in Clau se 8.1.8.3
Ed itorial changes in Clau ses 8.1.6.7 and 9.1.4
Ed itorial changes in Clau ses 2.5.2.2 and 4.2.2
N ew Clau se 5.7 and changed w ord ing in Clau se 8.3
Mod ify w ord ing in Clau se 7.1.3
Change p ricing, 2 H ou r Measu rem ent, 60 Day Sp ace
7x24 Maintenance, Mail Ballot Draft
Official Version 5.0 Sp ecification
Clau se 3.5.4, PDO Lim itations, Clu ster Du rability,
Checkp oint Interval, Typ ograp hical Errors
Mod ified Clau se 7.1.3, Clause 8.3, Clau se 7.1.6,
and Clau se 8.1.8.8. Rep laced Clau se 8.1.1.2,
and Clau se 8.1.8.2. Mod ified Clau se 5.4.4 (truncated
reported MQTh)
Clau se 8.3 (9), Execu tive Su m m ary, Mod ify 7.1.3 (5),
N ew Com m ent 4 and 5 to 7.1.3
Mod ified Clau se 3.3.3.2, Mod ified Clau se 5.3.3, Integrated
TPC Pricing Sp ecification
Mod ified Clau ses 8.1.1.7 and 8.1.9.1, Ad d ed Com m ent to
Clau se 8.1.1.2 and ad d ed Clau se 9.2.9.
Mod ified Clau ses 5.5.1.2, 8.1.1.2. Rep laced 6.6.6
Mod ified Clau ses 1.3.1 and 1.4.9. Ad d ed Clau se 1.4.14
Mod ified Clau ses 0.2, 1.3.1, 5.2.5.4, 8.1.8.1, 9.2.8.1, 7.1.3,
8.3, and 9.2.1. Ad d ed Clause 7.2.6
Mod ified Clau se 7.2.6.1, 7.2.6.2, 8.3.1, 8.3.2 to ad d ress
su bstitu tion ru les
Mod ified Clau ses 1.3.1, 3.1.5, 3.3.2, 3.5, 3.5.1, 3.5.3, 3.5.3.4,
4.3.2.2, 5.2.3, 5.2.5.6, 8.1.1.2, Ad d ed Clau se 9.2.9.2.
Ed itorial changes in Clau ses 3.4.2.9,3.5,5.6.4,7.2.6.1,8.1.1.3
Up d ated TPC Mem bership , Ed itorial change in Clau se
1.3.1, Mod ified Clau se 6.6.3.7, Mod ified Clau se 7.2.3.1,
Mod ified / Ad d ed Clau ses 0.1, 5.7.1, 8.1.1.2, and 9.2.9 to
su p p ort TPC-Energy requ irem ents.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 3 of 130
TPC Benchm ark ™, TPC-C, and tp m C are trad em arks of the Transaction Processin g Perform ance Cou ncil.
Perm ission to cop y w ithou t fee all or p art of this m aterial is granted p rovid ed that the TPC cop yright notice, the title
of the p u blication, and its d ate ap p ear, and notice is given that cop ying is by p erm ission of the Transaction
Processing Perform ance Cou ncil. To cop y otherw ise requ ires sp ecific p erm ission.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 4 of 130
TABLE OF CON TEN TS
Acknow led gm ents .............................................................................................................................................. 2
TPC Mem bership ................................................................................................................................................. 2
TABLE OF CON TEN TS ............................................................................................................................................. 5
Clau se 0: PREAMBLE ................................................................................................................................................ 7
0.1
Introd u ction ........................................................................................................................................ 7
0.2
General Im p lem entation Gu id elines ............................................................................................... 8
0.3
General Measu rem ent Gu id elines ................................................................................................... 9
Clau se 1: LOGICAL DATABASE DESIGN ........................................................................................................... 10
1.1
Bu siness and Ap p lication Environm ent ....................................................................................... 10
1.2
Database Entities, Relationship s, and Characteristics ................................................................ 11
1.3
Table Layou ts ................................................................................................................................... 11
1.4
Im p lem entation Ru les ..................................................................................................................... 18
1.5
Integrity Ru les .................................................................................................................................. 19
1.6
Data Access Transp arency Requ irem ents .................................................................................... 20
Clau se 2: TRAN SACTION and TERMIN AL PROFILES..................................................................................... 21
2.1
Definition of Term s ......................................................................................................................... 21
2.2
General Requ irem ents for Term inal I/ O ...................................................................................... 23
2.3
General Requ irem ents for Transaction Profiles .......................................................................... 26
2.4
The N ew -Ord er Transaction .......................................................................................................... 28
2.5
The Paym ent Transaction ............................................................................................................... 33
2.6
The Ord er-Statu s Transaction ........................................................................................................ 37
2.7
The Delivery Transaction ............................................................................................................... 40
2.8
The Stock-Level Transaction .......................................................................................................... 44
Clau se 3: TRAN SACTION and SYSTEM PROPERTIES ..................................................................................... 47
3.1
The ACID Prop erties ....................................................................................................................... 47
3.2
Atom icity Requ irem ents ................................................................................................................. 47
3.3
Consistency Requ irem ents ............................................................................................................. 48
3.4
Isolation Requ irem ents ................................................................................................................... 51
3.5
Du rability Requ irem ents ................................................................................................................ 57
Clau se 4: SCALIN G and DATABASE POPULATION ........................................................................................ 61
4.1
General Scaling Ru les...................................................................................................................... 61
4.2
Scaling Requ irem ents ...................................................................................................................... 61
4.3
Database Pop u lation ....................................................................................................................... 64
Clau se 5: PERFORMAN CE METRICS and RESPON SE TIME .......................................................................... 69
5.1
Definition of Term s ......................................................................................................................... 69
5.2
Pacing of Transactions by Em u lated Users .................................................................................. 69
5.3
Resp onse Tim e Definition .............................................................................................................. 73
5.4
Com p u tation of Throu ghp u t Rating ............................................................................................. 73
5.5
Measu rem ent Interval Requ irem ents ........................................................................................... 74
5.6
Requ ired Rep orting ......................................................................................................................... 76
5.7
Prim ary Metrics ............................................................................................................................... 78
Clau se 6: SUT, DRIVER, and COMMUN ICATION S DEFIN ITION ................................................................. 79
6.1
Mod els of the Target System .......................................................................................................... 79
6.2
Test Configu ration ........................................................................................................................... 80
6.3
System Und er Test (SUT) Definition ............................................................................................ 80
6.4
Driver Definition ............................................................................................................................. 80
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 5 of 130
6.5
6.6
Com m u nications Interface Definitions ......................................................................................... 81
Fu rther Requ irem ents on the SUT and Driver System ............................................................... 81
Clau se 7: PRICIN G ................................................................................................................................................... 85
7.1
Pricing Method ology....................................................................................................................... 85
7.2
Priced System ................................................................................................................................... 85
7.3
Requ ired Rep orting ......................................................................................................................... 88
Clau se 8: FULL DISCLOSURE ................................................................................................................................ 89
8.1
Fu ll Disclosu re Rep ort Requ irem ents ........................................................................................... 89
8.3
Revisions to the Fu ll Disclosu re Rep ort ....................................................................................... 98
Clau se 9: AUDIT ..................................................................................................................................................... 100
9.1
General Ru les ................................................................................................................................. 100
9.2
Au d itor's check list ........................................................................................................................ 100
Ind ex
105
Ap p end ix A: SAMPLE PROGRAMS ................................................................................................................... 108
A.1
The N ew -Ord er Transaction ........................................................................................................ 108
A.2
The Paym ent Transaction ............................................................................................................. 110
A.3
The Ord er-Statu s Transaction ...................................................................................................... 112
A.4
The Delivery Transaction ............................................................................................................. 114
A.5
The Stock-Level Transaction ........................................................................................................ 116
A.6
Sam p le Load Program .................................................................................................................. 117
Ap p end ix B: EXECUTIVE SUMMARY STATEMEN T ...................................................................................... 130
Ap p end ix C: N UMERICAL QUAN TITIES SUMMARY ................................................................................... 132
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 6 of 130
Clause 0: PREAMBLE
0.1
Introduction
TPC Benchm ark™C (TPC-C) is an OLTP w orkload . It is a m ixtu re of read -only and u p d ate intensive transactions
that sim u late the activities fou nd in com p lex OLTP ap p lication environm ents. It d oes so by exercising a bread th of
system com p onents associated w ith su ch environm ents, w hich are characterized by:
• The sim u ltaneou s execu tion of m u ltip le transaction typ es that sp an a bread th of com p lexity
• On-line and d eferred transaction execu tion m od es
• Mu ltip le on -line term inal sessions
• Mod erate system and ap p lication execu tion tim e
• Significant d isk inp u t/ ou tp u t
• Transaction integrity (ACID p rop erties)
• N on-u niform d istribu tion of d ata access throu gh p rim ary and second ary keys
• Databases consisting of m any tables w ith a w id e variety of sizes, attribu tes, and relat ionship s
• Contention on d ata access and u p d ate
The p erform ance m etric rep orted by TPC-C is a "bu siness throu ghp u t" m easu ring the nu m ber of ord ers p rocessed
p er m inu te. Mu ltip le transactions are u sed to sim u late the bu siness activity of p rocessing an ord er, and each
transaction is su bject to a resp onse tim e constraint. The p erform ance m etric for this benchm ark is exp ressed in
transactions-p er-m inu te-C (tp m C). To be com p liant w ith the TPC-C stand ard , all references to TPC-C resu lts m u st
inclu d e the tp m C rate, the associated p rice-p er-tp m C, and the availability d ate of the p riced configu ration.
To be com p liant w ith the op tional TPC-Energy stand ard , the ad d itional p rim ary m etric, exp ressed as w atts-p ertp m C m u st be rep orted . The requ irem ents of the TPC-Energy Sp ecification can be fou nd at w w w .tp c.org.
Althou gh these sp ecifications exp ress im p lem entation in term s of a relational d ata m od el w ith conventional locking
schem e, the d atabase m ay be im p lem ented u sing any com m ercially available d atabase m anagem ent system (DBMS),
d atabase server, file system , or other d ata rep ository that p rovid es a fu nction ally equ ivalent im p lem entation. The
term s "table", "row ", and "colu m n" are u sed in this d ocu m ent only as exam p les of logical d ata stru ctu res.
TPC-C u ses term inology and m etrics that are sim ilar to other benchm arks, originated by the TPC or others. Su ch
sim ilarity in term inology d oes not in any w ay im p ly that TPC -C resu lts are com p arable to oth er benchm arks. The
only benchm ark resu lts com p arable to TPC-C are other TPC-C resu lts conform ant w ith the sam e revision.
Desp ite the fact that this benchm ark offers a rich environm ent that em u lates m any OLTP ap p lication s, this
benchm ark d oes not reflect the entire range of OLTP requ irem ents. In ad d ition, the extent to w hich a cu stom er can
achieve the resu lts rep orted by a vend or is highly d ep end ent on how closely TPC -C ap p roxim ates the cu stom er
ap p lication. The relative p erform ance of sy stem s d erived from this benchm ark d oes not necessarily hold for other
w orkload s or environm ents. Extrap olations to any other environm ent are not recom m end ed .
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 7 of 130
Benchm ark resu lts are highly d ep end ent u p on w orkload , sp ecific ap p lication requ irem ents, and system s d esign and
im p lem entation. Relative system p erform ance w ill vary as a resu lt of these and other factors. Therefore, TPC -C
shou ld not be u sed as a su bstitu te for a sp ecific cu stom er ap p lication benchm arking w hen critical cap acity p lan ning
and / or p rod u ct evalu ation d ecisions are contem p lated .
Benchm ark sp onsors are p erm itted several p ossible system d esigns, insofar as they ad here to the m od el d escribed
and p ictorially illu strated in Clau se 6. A Fu ll Disclosu re Rep ort of the im p lem entation d etails, as sp ecified in Clau se
8, m u st be m ad e available along w ith the rep orted resu lts.
Comment: While sep arated from the m ain text for read ability, com m ents are a p art of the stand ard and m u st be
enforced . H ow ever, the sam p le p rogram s, inclu d ed as Ap p end ix A, the su m m ary statem ents, inclu d ed as Ap p end ix
B, and the nu m erical qu antities su m m ary, inclu d ed as Ap p end ix C, are p rovid ed only as exam p les and are
sp ecifically not p art of this stand ard .
0.2
General Implementation Guidelines
The p u rp ose of TPC benchm arks is to p rovid e relevant, objective p erform ance d ata to ind u stry u sers. To achieve
that p u rp ose, TPC benchm ark sp ecifications requ ire that benchm ark tests be im p lem ented w ith system s, p rod u cts,
technologies and p ricing that:
• Are generally available to u sers.
• Are relevant to the m arket segm ent that the ind ivid u al TPC benchm ark m od els or rep resents (e.g. TPC -A
m od els and rep resents high -volu m e, sim p le OLTP environm ents).
• A significant nu m ber of u sers in the m arket segm ent the benchm ark m od els or rep resents w ou ld p lau sibly
im p lem ent.
The u se of new system s, p rod u cts, technologies (hard w are or softw are) and p ricing is encou raged so long as they
m eet the requ irem ents above. Sp ecifically p rohibited are benchm ark system s, p rod u cts, technologies, p ricing
(hereafter referred to as "im p lem entations") w hose p rim ary p u rp ose is p erform ance op tim ization of TPC benchm ark
resu lts w ithou t any corresp ond ing ap p licability to real-w orld ap p lication s and environm ents. In other w ord s, all
"benchm ark sp ecials," im p lem entations that im p rove benchm ark resu lts bu t not real-w orld p erform ance or p ricing,
are p rohibited .
The follow ing characteristics shou ld be u sed as a gu id e to ju d ge w hether a p articu lar im p lem entation is a
benchm ark sp ecial. It is not requ ired that each p oint below be m et, bu t that the cu m u lative w eight of the evid ence
be consid ered to id entify an u naccep table im p lem entation. Absolu te certainty or certainty beyond a reasonable
d ou bt is not requ ired to m ake a ju d gm ent on this com p lex issu e. The qu estion that m u st be answ ered is this: based
on the available evid ence, d oes the clear p rep ond erance (the greater share or w eight) of evid e nce ind icate that this
im p lem entation is a benchm ark sp ecial?
The follow ing characteristics shou ld be u sed to ju d ge w hether a p articu lar im p lem entation is a benchm ark sp ecial:
• Is the im p lem entation generally available, d ocu m ented , and su p p orted ?
• Does the im p lem entation have significant restrictions on its u se or ap p licability that lim its its u se beyond TPC
benchm arks?
• Is the im p lem entation or p art of the im p lem entation p oorly integrated into the larger p rod u ct?
• Does the im p lem entation take sp ecial a d vantage of the lim ited natu re of TPC benchm arks (e.g., transaction
p rofile, transaction m ix, transaction concu rrency and / or contention, transaction isolation) in a m anner that
w ou ld not be generally ap p licable to the en vironm ent the benchm ark rep resents?
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 8 of 130
• Is the u se of the im p lem entation d iscou raged by the vend or? (This inclu d es failing to p rom ote the
im p lem entation in a m anner sim ilar to other p rod u cts and technologies.)
• Does the im p lem entation requ ire u ncom m on sop h istication on the p art of the end -u ser, p rogram m er, or
system ad m inistrator?
•
Is the p ricing u nu su al or non -cu stom ary for the vend or or u nu su al or non -cu stom ary to norm al bu siness
p ractices? See the cu rrent revision of the TPC Pricing Sp ecification for a d d itional inform ation.
• Is the im p lem entation being u sed (inclu d ing beta) or p u rchased by end -u sers in the m arket area the
benchm ark rep resents? H ow m any? Mu ltip le sites? If the im p lem entation is not cu rrently being u sed by
end -u sers, is there any evid ence to ind icate that it w ill be u sed by a significant nu m ber of u sers?
0.3 General Measurement Guidelines
TPC benchm ark resu lts are exp ected to be accu rate rep resentations of system p erform ance. Therefore, there are
certain gu id elines w hich are exp ected to be follow ed w hen m easu ring those resu lts. The ap p roach or m ethod ology is
exp licitly ou tlined in or d escribed in the sp ecification.
• The ap p roach is an accep ted is an accep ted engineering p ractice or stand ard .
• The ap p roach d oes not enhance the resu lt.
• Equ ip m ent u sed in m easu ring resu lts is calibrated accord ing to established qu ality stand ard s.
• Fid elity and cand or is m aintained in rep orting any anom alies in the resu lts, even if not sp ecified in the
benchm ark requ irem ents.
The u se of new m ethod ologies and ap p roaches is encou raged so long as they m eet the requ irem ents above.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 9 of 130
Clause 1: LOGICAL D ATABASE D ESIGN
1.1
Business and Application Environment
TPC Benchm ark™C is com p rised of a set of basic op erations d esigned to exercise system fu nctionalities in a m anner
rep resentative of com p lex OLTP ap p lication environm ents. These basic op erations have been given a life -like
context, p ortraying the activity of a w holesale su p p lier, to help u sers relate intu itively to the com p onents of the
benchm ark. The w orkload is centered on the activity of p rocessing ord ers and p rovid es a logical d atabase d esign,
w hich can be d istribu ted w ithou t stru ctu ral changes to transactions.
TPC-C d oes not rep resent the activity of any p articu lar bu siness segm ent, bu t rather any ind u stry w hich m u st
m anage, sell, or d istribu te a p rod u ct or service (e.g., car rental, food d istribu tion, p arts su p p lie r, etc.). TPC-C d oes
not attem p t to be a m od el of how to bu ild an actu al ap p lication .
The p u rp ose of a benchm ark is to red u ce the d iversity of op erations fou nd in a p rod u ction ap p lication , w hile
retaining the ap p lication's essential p erform ance characteristics, nam ely: the level of system u tilization and the
com p lexity of op erations. A large nu m ber of fu nctions have to be p erform ed to m anage a p rod u ction ord er entry
system . Many of these fu nctions are not of p rim ary interest for p erform ance analysis, since they are p rop ortionally
sm all in term s of system resou rce u tilization or in term s of frequ ency of execu tion. Althou gh these fu nctions are vital
for a p rod u ction system , they m erely create excessive d iversity in the context of a stand ard benchm ark and have
been om itted in TPC-C.
The Com p any p ortrayed by the benchm ark is a w holesale su p p lier w ith a num ber of geograp hically d istribu ted
sales d istricts and associated w arehou ses. As the Com p any's bu siness e xp and s, new w arehou ses and associated
sales d istricts are created . Each regional w arehou se covers 10 d istricts. Each d istrict serves 3,000 cu stom ers. All
w arehou ses m aintain stocks for the 100,000 item s sold by the Com p any. The follow ing d iagram illu strat es the
w arehou se, d istrict, and cu stom er hierarchy of TPC-C's bu siness environm ent.
Compa ny
Wa re hou se-1
Dis tri ct-1
1
2
Wa re hou se-W
Dis tri ct-2
3k
Dis tri ct-1 0
30 k
Custome rs
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 10 of 130
Cu stom ers call the Com p any to p lace a new ord er or requ est the statu s of an existing ord er. Ord ers are com p osed of
an average of 10 ord er lines (i.e., line item s). One p ercent of all ord er lines are for item s not in -stock at the regional
w arehou se and m u st be su p p lied by another w arehou se.
The Com p any's system is also u sed to enter p aym ents from cu stom ers, p rocess ord ers for d elivery, and exam ine
stock levels to id entify p otential su p p ly shortages.
1.2
D atabase Entities, Relationships, and Characteristics
1.2.1
The com p onents of the TPC-C d atabase are d efined to consist of nine sep arate and ind ivid u a l tables.
The relationship s am ong these tables are d efined in the entity -relationship d iagram show n below and are su bject to
the ru les sp ecified in Clau se 1.4.
10
Wa re hou se
W
His to ry
W*3 0k+
10 0k
S to ck
W*1 00k
W
Ite m
10 0k
3+
New-Order
W*9 k+
Ord er-L in e
W*3 00k+
Dis tri ct
W*1 0
3k
1+
Custome r
W*3 0k
0-1
5-15
1+
Ord er
W*3 0k+
Legend:
• All nu m bers show n illu strate the d atabase p op u lation requ irem ents (see Clau se 4.3).
• The nu m bers in the entity blocks rep resent the card inality of the tables (nu m ber of row s). These nu m bers are
factored by W, the nu m ber of Warehou ses, to illu strate the d atabase scaling. (see Clau se 4).
• The nu m bers next to the relationship arrow s rep resent the card inality of the relationship s (average nu m ber of
child ren p er p arent).
• The p lu s (+) sym bol is u sed after the card inality of a relationship or table to illu strate that this nu m ber is
su bject to sm all variations in the initial d atabase p op u lation over the m easu rem ent interval (see Clau se 5.5) as
row s are ad d ed or d eleted .
1.3
Table Layouts
1.3.1
The follow ing list d efines the m inim al stru ctu re (list of attribu tes) of each table w here:
• N unique ID s m eans that the attribu te m u st be able to hold any one ID w ithin a m inim u m set of N u niqu e
IDs, regard less of the p hysical rep resentation (e.g., binary, p acked d ecim al, alphabetic, etc.) of the attribu te.
• variable text, size N m eans that the attribu te m u st be able to hold any string of ch aracters of a variable length
w ith a m axim u m length of N . If the attribu te is stored as a fixed length string and the string it h old s is shorter
than N characters, it m u st be p ad d ed w ith sp aces.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 11 of 130
• fixed text, size N m eans that the attribu te m u st be able to hold any string of characters of a fixed length of N.
• date and time rep resents the d ata typ e for a d ate value th at inclu d es a tim e com ponent. The d ate com p onent
m u st be able to hold any d ate betw een 1 st Janu ary 1900 and 31st Decem ber 2100. The tim e com p onent m u st be
cap able of rep resenting the range of tim e valu es from 00:00:00 to 23:59:59 w ith a resolu tion of at least one
second . Date and Tim e m ust be im p lem ented u sing d ata typ es that are d efined by the DBMS for that u se.
• numeric(m [,n]) m eans an u nsigned nu m eric valu e w ith at least m total d ecim al d igits, of w hich n d igits are
to the right (after) the d ecim al p oint. The attribu te m u st be able to hold all p ossible valu es w hich can be
exp ressed as nu m eric(m ,n). Om itting n, as in nu m eric(m ), ind icates the sam e as nu m eric(m ,0). N u m eric
field s that contain m onetary valu es (W_YTD, D_YTD, C_CREDIT_LIM, C_BALA N CE, C_YTD_PAYMENT,
H _AMOUN T, OL_AMOUN T, I_PRICE) m u st u se d ata typ es that are d efined by the DBMS as being an exact
nu m eric d ata typ e or that satisfy the AN SI SQL Stand ard d efinition of being an exact nu m eric rep resentation.
• signed numeric(m [,n]) is id entical to nu m eric(m [,n]) excep t that it can rep resent both p ositive and negative
valu es.
• null m eans ou t of the range of valid valu es for a given attribu te and alw ays the sam e valu e for that attribu te.
Comment 1: For each table, the follow ing list of attribu tes can be im p lem ented in any ord er, u sing any p hysical
rep resentation available from the tested system .
Comment 2: Table and attribu te nam es are u sed for illu stration p u rp oses only; d ifferent nam es m ay be u sed by th e
im p lem entation.
Comment 3: A signed numeric d ata typ e m ay be u sed (at the sp onsor‟ s d iscretion) anyw here a numeric d ata typ e
is d efined .
WAREHOUSE Table Layout
Field N am e
Field Definition
Com m ents
W_ID
2*W u niqu e IDs
W W arehouses are populated
W_N AME
variable text, size 10
W_STREET_1
variable text, size 20
W_STREET_2
variable text, size 20
W_CITY
variable text, size 20
W_STATE
fixed text, size 2
W_ZIP
fixed text, size 9
W_TAX
signed nu m eric(4,4)
Sales tax
W_YTD
signed nu m eric(12,2)
Y ear to date balance
Prim ary Key: W_ID
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 12 of 130
D ISTRICT Table Layout
Field N am e
Field Definition
Com m ents
D_ID
20 u niqu e IDs
10 are populated per warehouse
D_W_ID
2*W u niqu e IDs
D_N AME
variable text, size 10
D_STREET_1
variable text, size 20
D_STREET_2
variable text, size 20
D_CITY
variable text, size 20
D_STATE
fixed text, size 2
D_ZIP
fixed text, size 9
D_TAX
signed nu m eric(4,4)
Sales tax
D_YTD
signed nu m eric(12,2)
Y ear to date balance
D_N EXT_O_ID
10,000,000 u niqu e IDs
N ext available Order number
Prim ary Key: (D_W_ID, D_ID)
D_W_ID Foreign Key, references W_ID
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 13 of 130
CUSTOMER Table Layout
Field N am e
Field Definition
Com m ents
C_ID
96,000 u niqu e IDs
3,000 are populated per district
C_D_ID
20 u niqu e IDs
C_W_ID
2*W u niqu e IDs
C_FIRST
variable text, size 16
C_MIDDLE
fixed text, size 2
C_LAST
variable text, size 16
C_STREET_1
variable text, size 20
C_STREET_2
variable text, size 20
C_CITY
variable text, size 20
C_STATE
fixed text, size 2
C_ZIP
fixed text, size 9
C_PH ON E
fixed text, size 16
C_SIN CE
d ate and tim e
C_CREDIT
fixed text, size 2
C_CREDIT_LIM
signed nu m eric(12, 2)
C_DISCOUN T
signed nu m eric(4, 4)
C_BALAN CE
signed nu m eric(12, 2)
C_YTD_PAYMEN T
signed nu m eric(12, 2)
C_PAYMEN T_CN T
nu m eric(4)
C_DELIVERY_CN T
nu m eric(4)
C_DATA
variable text, size 500
"GC"=good, "BC"=bad
M iscellaneous information
Prim ary Key: (C_W_ID, C_D_ID, C_ID)
(C_W_ID, C_D_ID) Foreign Key, references (D_W_ID, D_ID)
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 14 of 130
HISTORY Table Layout
Field N am e
Field Definition
H _C_ID
96,000 u niqu e IDs
H _C_D_ID
20 u niqu e IDs
H _C_W_ID
2*W u niqu e IDs
H _D_ID
20 u niqu e IDs
H _W_ID
2*W u niqu e IDs
H _DATE
d ate and tim e
H _AMOUN T
signed nu m eric(6, 2)
H _DATA
variable text, size 24
Com m ents
M iscellaneous information
Prim ary 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: Row s in the H istory table d o not have a p rim ary key as, w ithin the context of the
benchm ark, there is no need to u niqu ely id entify a row w ithin this table.
N ote: The TPC-C ap p lication d oes not have to be cap able of u tilizing the increased range of C_ID
valu es beyond 6,000.
N EW-ORD ER Table Layout
Field N am e
Field Definition
N O_O_ID
10,000,000 u niqu e IDs
N O_D_ID
20 u niqu e IDs
N O_W_ID
2*W u niqu e IDs
Com m ents
Prim ary Key: (N O_W_ID, N O_D_ID, N O_O_ID)
(N O_W_ID, N O_D_ID, N O_O_ID) Foreign Key, references (O_W_ID, O_D_ID, O_ID)
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 15 of 130
ORD ER Table Layout
Field N am e
Field Definition
O_ID
10,000,000 u niqu e IDs
O_D_ID
20 u niqu e IDs
O_W_ID
2*W u niqu e IDs
O_C_ID
96,000 u niqu e IDs
O_EN TRY_D
d ate and tim e
O_CARRIER_ID
10 u niqu e IDs, or nu ll
O_OL_CN T
nu m eric(2)
O_ALL_LOCAL
nu m eric(1)
Com m ents
Count of Order-Lines
Prim ary Key: (O_W_ID, O_D_ID, O_ID)
(O_W_ID, O_D_ID, O_C_ID) Foreign Key, references (C_W_ID, C_D_ID, C_ID)
ORD ER-LIN E Table Layout
Field N am e
Field Definition
OL_O_ID
10,000,000 u niqu e IDs
OL_D_ID
20 u niqu e IDs
OL_W_ID
2*W u niqu e IDs
OL_N UMBER
15 u niqu e IDs
OL_I_ID
200,000 u niqu e IDs
OL_SUPPLY_W_ID
2*W u niqu e IDs
OL_DELIVERY_D
d ate and tim e, or nu ll
OL_QUAN TITY
nu m eric(2)
OL_AMOUN T
signed nu m eric(6, 2)
OL_DIST_IN FO
fixed text, size 24
Com m ents
Prim ary Key: (OL_W_ID, OL_D_ID, OL_O_ID, OL_NUMBER)
(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)
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 16 of 130
ITEM Table Layout
Field N am e
Field Definition
Com m ents
I_ID
200,000 u niqu e IDs
100,000 items are populated
I_IM_ID
200,000 u niqu e IDs
Image ID associated to Item
I_N AME
variable text, size 24
I_PRICE
nu m eric(5, 2)
I_DATA
variable text, size 50
Brand information
Field N am e
Field Definition
Com m ents
S_I_ID
200,000 u niqu e IDs
100,000 populated per warehouse
S_W_ID
2*W u niqu e IDs
S_QUAN TITY
signed nu m eric(4)
S_DIST_01
fixed text, size 24
S_DIST_02
fixed text, size 24
S_DIST_03
fixed text, size 24
S_DIST_04
fixed text, size 24
S_DIST_05
fixed text, size 24
S_DIST_06
fixed text, size 24
S_DIST_07
fixed text, size 24
S_DIST_08
fixed text, size 24
S_DIST_09
fixed text, size 24
S_DIST_10
fixed text, size 24
S_YTD
nu m eric(8)
S_ORDER_CN T
nu m eric(4)
S_REMOTE_CN T
nu m eric(4)
S_DATA
variable text, size 50
Prim ary Key: I_ID
STOCK Table Layout
M ake information
Prim ary Key: (S_W_ID, S_I_ID)
S_W_ID Foreign Key, references W_ID
S_I_ID Foreign Key, references I_ID
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 17 of 130
1.4
Implementation Rules
1.4.1
The p hysical clu sterin g of record s w ithin the d atabase is allow ed .
1.4.2
A view w hich rep resents the row s to avoid logical read / w rites is exclu d ed .
Comment: The intent of this clau se is to insu re that the ap p lication im p lem ents the nu m ber of logical op erations
d efined in the transaction profiles w ithou t com bining several op erations in one, via the u se of a view .
1.4.3
All tables m u st have the p rop erly scaled nu m ber of row s as d efined by the d atabase p op u lation
requ irem ents (see Clau se 4.3).
1.4.4
H orizontal p artitioning of tables is allow ed . Grou p s of row s from a table m ay be assigned to d ifferent
files, d isks, or areas. If im p lem ented , the d etails of su ch p artitioning m u st be d isclosed .
1.4.5
Vertical p artitioning of tables is allow ed . Grou p s of attribu tes (colu m ns) of one table m ay be assigned
to files, d isks, or areas d ifferent from those storing the other attribu tes of that table. If im p lem ented , the d etails of
su ch p artitioning m u st be d isclosed (see Clau se 1.4.9 for lim itations).
Comment: in the tw o clau ses above (1.4.4 and 1.4.5) assignm ent of d ata to d ifferent files, d isks, or areas not based on
know led ge of the logical stru ctu re of the d ata (e.g., know led ge of row or attribu te bou nd aries) is not consid ered
p artitioning. For exam p le, d istribu tion or strip p ing over m u ltip le d isks of a p hysical file w hich stores one or m ore
logical tables is not consid ered p artitioning as long as this d istribu tion is d one by the hard w are or the op erating
system w ithou t know led ge of the logical stru ctu re stored in the physical file.
1.4.6
Rep lication is allow ed for all tables. All cop ies of tables w hich a re rep licated m u st m eet all
requ irem ents for atom icity, consistency, and isolation as d efined in Clau se 3. If im p lem ented , the d etails of su ch
rep lication m u st be d isclosed .
Comment: Only one cop y of a rep licated table need s to m eet the d u rability requ irem ents d efined in Clau se 3.
1.4.7
Attribu tes m ay be ad d ed and / or d u p licated from one table to another as long as these changes d o not
im p rove p erform ance.
1.4.8
Each attribu te, as d escribed in Clau se 1.3.1, m u st b e logically d iscrete and ind ep end ently accessible by
the d ata m anager. For exam p le, W_STREET_1 and W_STREET_2 cannot be im p lem ented as tw o su b -p arts of a
d iscrete attribu te W_STREET.
1.4.9
Each attribu te, as d escribed in Clau se 1.3.1, m u st be accessible by the d ata m anager as a single
attribu te. For exam p le, S_DATA cannot be im p lem ented as tw o d iscrete attribu tes S_DATA_1 and S_DATA_2
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 18 of 130
1.4.10
The p rim ary key of each table m u st not d irectly rep resent the p hysical d isk ad d resses of the row or
any offsets thereof. The ap p lication m ay not reference row s u sing relative ad d ressing since they are sim p ly offsets
from the beginning of the storage sp ace. This d oes n ot p reclu d e hashing schem es or other file organizations w hich
have p rovisions for ad d ing, d eleting, and m od ifying record s in the ord inary cou rse of p rocessing. Excep tion: The
H istory table can u se relative ad d ressing bu t all other requ irem ents ap p ly.
Comment 1: It is the intent of this clau se that the ap p lication p rogram (see Clau se 2.1.7) execu ting the transaction, or
su bm itting the transaction requ est, not u se p hysical id entifiers, bu t logical id entifiers for all accesses, and contain no
u ser w ritten cod e w hich translates or aid s in the translation of a logical key to the location w ithin the table of the
associated row or row s. For exam p le, it is not legitim ate for the ap p lication to bu ild a "translation t able" of logical-top hysical ad d resses and u se it to enhance p erform ance.
Comment 2: Internal record or row id entifiers, for exam p le, Tu p le IDs or cu rsors, m ay be u sed u nd er the follow ing
cond itions:
1.
For each transaction execu ted , initial access to any row m u st be via the key(s) sp ecified in the transaction
p rofile and no other attribu tes. Initial access inclu d es insertion, d eletion, retrieval, and u p d ate of any row .
2.
Clau se 1.4.10 m ay not be violated .
1.4.11
While inserts and d eletes are not p erform ed on all tables, the system m u st not be configu red to take
sp ecial ad vantage of this fact d u ring the test. Althou gh inserts are inherently lim ited by the storage sp ace available
on the configu red system , there m u st be no restriction on inserting in any of the tables a m inim u m nu m ber of row s
equ al to 5% of the table card inality and w ith a key valu e of at least d ou ble the range of key valu es p resent in that
table.
Comment: It is requ ired that the sp ace for the ad d itional 5% table card inality be configu red for the test ru n and
p riced (as static sp ace p er Clau se 4.2.3) accord ingly. For system s w here sp ace is configu red and d ynam ically
allocated at a later tim e, this sp ace m u st be consid ered as allocated and inclu d ed as static sp ace w hen p riced .
1.4.12
The m inim um d ecim al p recision for any com p u tation p erform ed as p art of the ap p lication p rogram
m u st be the m axim u m d ecim al p recision of all the ind ivid u al item s in that calcu lation.
1.4.13
Any other ru les sp ecified elsew here in this d ocu m ent ap p ly to the im p lem entation (e.g., the
consistency ru les in Clau se 3.3).
1.4.14
The table attribu tes variable text, fixed text, d ate and tim e, and num eric m u st be im p lem ented u sing
native d ata typ es of the d ata m anagem ent system (i.e., not the ap p lication p rogram ) w hose d ocu m ented p urp ose is
to store d ata of the typ e d efined for the attribu te. For exam p le, d ate and tim e m u st be im p lem ented w ith a native
d ata typ e d esigned to store d ate and tim e inform ation.
1.5
Integrity Rules
1.5.1
In any com m itted state, the p rim ary key valu es m u st be u niqu e w ithin each table. For exam p le, in the
case of a horizontally p artitioned table, p rim ary key valu es of row s across all p artitions m u st be u niqu e.
1.5.2
In any com m itted state, no ill-form ed row s m ay exist in the d atabase. An ill-form ed row occu rs w hen
the valu e of any attribu tes cannot be d eterm ined . For exam p le, in the case of a vertically p artitioned table, a row
m u st exist in all the p artitions.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 19 of 130
1.6
D ata Access Transparency Requirements
Data Access Transp arency is the p rop erty of the system w hich rem oves from the ap p lication p rogram any
know led ge of the location and access m echanism s of p artitioned d ata. An im p lem entation w hich u ses vertical
and / or horizontal p artitioning m u st m eet the requ irem ents for transp arent d ata access d escribed here.
N o finite series of test can p rove that the system su p p orts com p lete d ata access transp arency. The requ irem ents
below d escribe the m inim um cap abilities need ed to establish that the system p rovid es transp arent d ata access.
Comment: The intent of this clau se is to requ ire that access to p hysically and / or logically p artitioned d ata be
p rovid ed d irectly and transp arently by services im p lem ented by com m ercially available layers below the ap p lication
p rogram su ch as the d ata/ file m anager (DBMS), the operating system , the hard w are, or any com bination of these.
1.6.1
Each of the nine tables d escribed in Clau se 1.3 m u st be id entifiable by n am es w hich have no
relationship to the p artitioning of tables. All d ata m anip u lation op erations in the ap p lication p rogram (see Clau se
2.1.7) m u st u se only these nam es.
1.6.2
The system m u st p revent any d ata m anip u lation op eration p erform ed u sing the nam es d escribed in
Clau se 1.6.1 w hich w ou ld resu lt in a violation of the integrity ru les (see Clau se 1.5). For exam p le: the system m u st
p revent a non -TPC-C ap p lication from com m itting the insertion of a row in a vertically p artitioned table u nless all
p artitions of that row have been inserted .
1.6.3
Using the nam es w hich satisfy Clau se 1.6.1, any arbitrary non-TPC-C ap p lication m u st be able to
m anip u late any set of row s or colu m ns:
• Id entifiable by any arbitrary cond ition su p p orted by the u nd erlying DBMS
• Using the nam es d escribed in Clau se 1.6.1 and u sing the sam e d ata m anip u lation sem antics and syntax for all
tables.
For exam p le, the sem antics and syntax u sed to u p d ate an arbit rary set of row s in any one table m u st also be u sable
w hen u p d ating another arbitrary set of row s in any other table.
Comment: The intent is that the TPC-C ap p lication p rogram u ses general p u rp ose m echanism s to m anip u late d ata
in the d atabase.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 20 of 130
Clause 2: TRAN SACTION and TERMIN AL PROFILES
2.1
D efinition of Terms
2.1.1
The term select as u sed in this sp ecification refers to the action of id entifyin g (e.g., referencing,
p ointing to) a row (or row s) in the d atabase w ithou t requ iring retrieval of the actu al content of the id entified row (s).
2.1.2
The term retrieve as u sed in this sp ecification refers to the action of accessing (i.e., fetching) the valu e
of an attribu te from the d atabase and passing this valu e to the ap p lication p rogram .
N ote: Field s that corresp on d to d atabase attribu tes are in UPPERCASE. Other field s, su ch as field s u sed by t he SUT,
or the RTE, for com p u tations, or com m u nication w ith the term inal, bu t not stored in the d atabase, are in lowercase
italics.
2.1.3
The term database transaction as u sed is this sp ecification refers to a u nit of w ork on the d atabase
w ith fu ll ACID p rop erties as d escribed in Clau se 3. A business transaction is com p rised of one or m ore d atabase
transactions. When u sed alone, the term transaction refers to a bu siness transaction.
2.1.4
The term [x .. y ] rep resents a closed range of valu es starting w ith x and end ing w ith y.
2.1.5
The term randomly selected w ithin [x .. y ] m eans ind ep end ently selected at rand om and u niform ly
d istribu ted betw een x and y, inclu sively, w ith a m ean of (x+y)/ 2, and w ith the sam e nu m ber of d igits of p recision as
show n. For exam p le, [0.01 .. 100.00] has 10,000 u niqu e valu es, w hereas [1 ..100] has only 100 u n iqu e valu es.
2.1.6
The term non-uniform random, u sed only for generating cu stom er nu m bers, cu stom er last nam e s,
and item nu m bers, m eans an ind ep end ently selected and non -u niform ly d istribu ted rand om nu m ber over the
sp ecified range of valu es [x .. y]. This nu m ber m u st be generated by u sing the fu nction N URand w hich p rod u ces
p ositions w ithin the range [x .. y]. The resu lts of N URand m ight have to be converted to p rod u ce a nam e or a
nu m ber valid for the im p lem entation.
N URand (A, x, y) = (((rand om (0, A) | rand om (x, y)) + C) % (y - x + 1)) + x
w here:
exp -1 | exp -2 stand s for the bitw ise logical OR op eration betw een exp -1 and exp -2
exp -1 % exp -2 stand s for exp -1 m od u lo exp -2
rand om (x, y) stand s for rand om ly selected w ithin [x .. y]
A is a constant chosen accord ing to the size of the range [x .. y]
for C_LAST, the range is [0 .. 999] and A = 255
for C_ID, the range is [1 .. 3000] and A = 1023
for OL_I_ID, the range is [1 .. 100000] and A = 8191
C is a ru n-tim e constant rand om ly chosen w ithin [0 .. A] that can be varied w ith ou t altering p erform ance.
The sam e C valu e, p er field (C_LAST, C_ID, and OL_I_ID), m u st be u sed by all em u lated term inals.
2.1.6.1
In ord er that the valu e of C u sed for C_LAST d oes not alter p erform ance the follow ing m u st be tru e:
Let C-Load be the valu e of C u sed to generate C_LAST w hen p op u lating the d atabase. C-Load is a valu e
in the range of [0..255] inclu d ing 0 and 255.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 21 of 130
Let C-Ru n be the valu e of C u sed to generate C_LAST for the m easu rem ent ru n.
Let C-Delta be the absolu te valu e of the d ifference betw een C -Load and C-Ru n. C-Delta m u st be a valu e in
the range of [65..119] inclu d ing the valu es of 65 and 119 and exclu d ing the valu e of 96 and 112.
2.1.7
The term application program refers to cod e that is not p art of the com m ercially available com p onents
of the system , bu t p rod u ced sp ecifically to im p lem ent the transaction p rofiles (see Clau ses 2.4.2, 2.5.2, 2.6.2, 2.7.4,
and 2.8.2) of this benchm ark. For exam p le, stored p roced u res, triggers, and r eferential integrity constraints are
consid ered p art of the ap p lication p rogram w hen u sed to im p lem ent any p ortion of the transaction p rofiles, bu t are
not consid ered p art of the ap p lication p rogram w hen solely u sed to enforce integrity ru les (see Clau se 1.5) or
transp arency requ irem ents (see Clau se 1.6) ind ep end ently of any transaction p rofile.
2.1.8
The term terminal as u sed in this sp ecification refers to the interface d evice cap able of entering and
d isp laying characters from and to a u ser w ith a m inim u m d isp lay of 24x80. A term inal is d efined as the com p onents
that facilitate end -u ser inp u t and the d isp lay of the ou tp u t as d efined in Clau se 2. The term inal m ay not contain any
know led ge of the ap p lication excep t field form at, typ e, and p osition.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 22 of 130
2.2
General Requirements for Terminal I/O
2.2.1
Input/Output Screen D efinitions
2.2.1.1
The layou t (p osition on the screen and size of titles an d field s) of the inp u t/ ou tp u t screens, as d efined
in Clau ses 2.4.3.1, 2.5.3.1, 2.6.3.1, 2.7.3.1, and 2.8.3.1, m u st be rep rod u ced by th e test sp onsor as closely as p ossible
given the featu res and lim itations of the im p lem ented system . Any d eviation from the i np u t/ ou tp u t screens m u st be
exp lained .
2.2.1.2
Inp u t/ ou tp u t screens m ay be altered to circu m vent lim itations of the im p lem entation p rovid ing that
no p erform ance ad vantage is gained . H ow ever, the follow ing ru les ap p ly:
1. Titles can be translated into any langu age.
2. The sem antic content cannot be altered .
3. The nu m ber of ind ivid u al field s cannot be altered .
4. The nu m ber of characters w ithin the field s (i.e., field w id th) cannot be d ecreased .
5. Reord ering or rep ositioning of field s is allow ed .
6. A cop y of the new screen sp ecifications and layou t m u st be inclu d ed in the Full Disclosu re Rep ort .
2.2.1.3
The am ou nt and p rice field s d efined in Clau se 2 are form atted for U.S. cu rrency. These form ats can be
m od ified to satisfy d ifferent cu rrency rep resentation (e.g., u se another cu rrency sign, m ove the d ecim al p oint
retaining at least one d igit on its right).
2.2.1.4
For inp u t/ ou tp u t screens w ith u nu sed field s (or grou p s of field s), it is not requ ired to enter or d isp lay
these field s. For exam p le, w hen an ord er has less than 15 item s, the grou p s of field s corresp ond ing to the rem aining
item s on the inp u t/ ou tp u t screen are u nu sed and need not be entered or d isp layed after being cleared . Sim ilarly,
w hen selecting a cu stom er u sing its last nam e, the cu stom er nu m ber field is unu sed and need not be entered or
d isp layed after being cleared .
2.2.1.5
All inp u t and ou tp u t field s that m ay change m u st be cleared at the beginning of each transaction even
w hen the sam e transaction typ e is consecu tively selected by a given term inal. Field s shou ld be cleared by d isp laying
them as sp aces or zeros.
Comment: In Clau ses 2.2.1.4 and 2.2.1.5, if the test sp onsor d oes not p rom ote u sing sp ace or zero as a clear character
for its im p lem entation, other clear characters can be u sed as long as a given field alw ays u ses the sam e clear
character.
2.2.1.6
A menu is u sed to select the next transaction typ e. The m enu , co nsisting of one or m ore lines, m u st be
d isp layed at the very top or at the very bottom of the inp u t/ ou tp u t screen. If an inp u t field is need ed to enter the
m enu selection, it m u st be located on the line(s) reserved for the m enu .
Comment: The m enu is in ad d ition to the screen form ats d efined in the term inal I/ O Clau se for each transaction
typ e.
2.2.1.7
The m enu m u st d isp lay exp licit text (i.e., it m u st contain the fu ll nam e of each transaction and the
action to be taken by the u ser to select each transaction). A m inim u m of 60 characters (exclu d ing sp ace s) m u st be
d isp layed on the m enu .
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 23 of 130
2.2.1.8
Any inp u t and ou tp u t field (s), other than the m and atory field s sp ecified in the inp u t/ ou tp u t screens
as d efined in Clau ses 2.4.3.1, 2.5.3.1, 2.6.3.1, 2.7.3.1, and 2.8.3.1, m u st be d isclosed , and the p u rp ose of su ch field (s)
exp lained .
2.2.2
Entering and D isplaying Fields
2.2.2.1
A field is said to be entered once all the significant characters that com p ose the in p u t d ata for that field
have been com m u nicated to the SUT by the em u lated term inal.
2.2.2.2
A field is said to be d isp layed once all significant characters that com p ose the d ata for that field have
been com m u nicated by the SUT to the em u lated term inal for d isp lay.
2.2.2.3
Com m u nicating inp u t and ou tp u t d ata d oes not requ ire transferring any sp ecific nu m ber of bytes.
Method s for op tim izing this com m u nication, su ch as m essage com p ression and d ata caching , are allow ed .
2.2.2.4
The follow ing featu res m u st be p rovid ed to the em u lated u ser:
1. The inp u t characters ap pear on the inp u t/ ou tp u t screen (i.e., are echoed ) as they are keyed in. This
requ irem ent can be satisfied by visu al insp ection at fu ll load w he re there are no p erceivable d elays.
Otherw ise, it is requ ired that the character echoing be verified by actu al m easu rem ents. For exam p le, that can
be d one u sing a p rotocol analyzer, RTE m easu rem ent, etc. to show that the echo resp onse tim e is less than 1
second . If local echo or block m od e d evices are u sed then verification is not requ ired .
Comment: A w eb brow ser im p lem entation, or a term inal or PC em u lating a term inal in either local echo or block
m od e, w ill m eet the echo resp onse tim e requ irem ent of one second , so there is no need for an echo test.
2. Inp u t is allow ed only in the p ositions of an inp u t field (i.e., ou tp u t -only field s, labels, and blanks sp aces on
the inp u t/ ou tp u t screen are p rotected from inp u t).
3. Inp u t-cap able field s are d esignated by som e m ethod of clearly id entifying them (e.g., highlighted areas,
u nd erscores, reverse vid eo, colu m n d ivid ers, etc.).
4. It m u st be p ossible to key in only significant characters into field s. For alp hanu m eric field s, non -keyed
p ositions m u st be translated to blanks or nu lls. For n u m eric field s, keyed inp u t of less than the m axim um
allow able d igits m u st be p resented right ju stified on th e ou tp u t screen.
5. All field s for w hich a valu e is necessary to allow the ap p lication to com p lete are requ ired to contain inp u t
p rior to the start of the m easu rem ent of the transaction RT, or the ap p lication m u st contain a set of error hand ling rou tines to inform the u ser that requ ired field s have not been entered .
6. Field s can be keyed and re-keyed in any ord er. Sp ecifically:
•
The em u lated u ser m u st be able to m ove the inp u t cu rsor forw ard and backw ard d irectly to the inp u t
cap able field s.
•
The ap p lication cannot rely on field s being entered in any p articu lar ord er.
•
The u ser can retu rn to a field that has been keyed in and change its valu e p rior to the start of the
m easu rem ent of the transaction RT.
7. N u m eric field s m u st be p rotected from non -nu m eric inp u t. If one or m ore non -nu m eric characters is entered
in a nu m eric field , a d ata entry error m u st be signaled to the u ser.
Comment: Inp u t valid ation m ay either be p erform ed by the term inal, by the ap p lication , or a com bination of
both. Inp u t valid ation requ ired by Item 5 and Item 7 m u st occu r p rior to starting a d atabase transaction .
Sp ecifically, invalid d ata entry m ay not resu lt in a rolled back transaction.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 24 of 130
2.2.2.5
All ou tp u t field s that d isp lay valu es that are u p d ated in the d atabase by the cu rrent bu siness
transaction m u st d isp lay the "new " (i.e., com m itted ) valu es for those field s.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 25 of 130
2.3
General Requirements for Transaction Profiles
Each transaction m u st be im p lem ented accord ing to the sp ecified transaction p rofiles . In ad d ition:
2.3.1
The ord er of the d ata m anip u lation s w ithin the transaction bou nd s is im m aterial (u nless o therw ise
sp ecified , see Clau se 2.4.2.3), and is left to the latitu d e of the test sp onsor , as long as the im p lem ented transactions
are fu nctionally equ ivalent to those sp ecified in the transaction p rofiles .
2.3.2
The transaction p rofiles sp ecify m inim al d ata retrieval and u p d ate requ irem ents for the transactions.
Ad d itional navigational step s or d ata m anip u lation op erations im p lem ented w ithin the d atabase transactions m u st
be d isclosed , and the p u rp ose of su ch ad d ition(s) m u st be exp lained .
2.3.3
Each attribu te m u st be obtained from the d esignated table in the transaction p rofiles .
Comment: The intent of this clau se is to p revent red u cing the nu m ber of logical d atabase op erations requ ired to
im p lem ent each transaction.
2.3.4
N o d ata m anip u lation op eration from the transaction p rofile can be p erform ed before all inp u t d ata
have been com m u nicated to the SUT, or after any ou tp u t d ata have been com m u nicated by the SUT to the em u lated
term inal.
Comment: The intent of this clau se is to ensu re that, for a given bu siness transaction , no d ata m anip u lation
op eration from the transaction p rofile is p erform ed p rior to the tim estam p taken at the beginning of the Transaction
RT or after the tim estam p taken at the end of the Transaction RT (see Clau se 5.3). For exam p le, in the N ew -Ord er
transaction the SUT is not allow ed to fetch the m atching row from the CUSTOMER table u ntil all inp u t d ata have
been com m u nicated to the SUT, even if this row is fetched again later d u ring the execu tion of that sam e transaction.
2.3.5
If transactions are rou ted or organized w ithin the SUT, a com m ercially available transaction
p rocessing m onitor or equ ivalent com m ercially available softw are (hereinafter referred to as TM ) is requ ired w ith
the follow ing featu res/ fu nctionality:
Operation - The TM m u st allow for:
• requ est/ service p rioritization
• m u ltip lexing/ d e m u ltip lexing of requ ests/ services
• au tom atic load balancing
• recep tion, qu eu ing, and execu tion of m u ltip le requ ests/ services concu rrently
Security - The TM m u st allow for:
• the ability to valid ate and au thorize execu tion of each service at the tim e the service is requ ested .
• the restriction of ad m inistrative fu nctions to au thorized u sers.
Administration/Maintenance - The TM m u st have the p red efined cap ability to p erform centralized , non
p rogram m atic (i.e., m u st be im p lem ented in the stand ard p rod u ct and not requ ire p rogram m ing) and
d ynam ic configu ration m anagem ent of TM resou rces inclu d ing hard w are , netw ork, services (single or
grou p ), qu eu e m anagem ent p rioritization ru les, etc.
Recovery - The TM m u st have the cap ability to:
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 26 of 130
• p ost error cod es to an ap p lication
• d etect and term inate long-ru nning transactions based on p red efined tim e-ou t intervals
Application Transparency - The m essage context(s) that exist betw een the client and server ap p lication
p rogram s m u st be m anaged solely by the TM . The client and server ap p lication p rogram s m u st not ha ve any
know led ge of the m essage context or the u nd erlying com m u nication m echanism s that su p p ort that context.
Comment 1: The follow ing are exam p les of im p lem entations that are non -com p liant w ith the Ap p lication
Transp arency requ irem ent.
1. Client and server ap p lication p rogram s u se the sam e id entifier (e.g., hand le or p ointer) to m aintain the
m essage context for m u ltip le transactions.
2. Change and / or recom p ilation of the client and / or server ap p lication p rogram s is requ ired w hen the
nu m ber of qu eu es or equ ivalent d ata stru ctu res u sed by the TM to m aintain the m essage context betw een
the client and server ap p lication p rogram s is changed by TM ad m inistra tion.
Comment 2: The intent of this clau se is to encou rage the u se of general p u rp ose, com m ercially available transaction
m onitors, and to exclu d e sp ecial p u rp ose softw are d evelop ed for benchm ark ing or other lim ited u se. It is
recognized that im p lem entations of featu res and functionality d escribed above vary across vend ors' architectu res.
Su ch d ifferences d o not p reclu d e com p liance w ith the requ irem ents of this clau se.
Comment 3: Functionality of TM or equ ivalent softw are is not requ ired if the DBMS m aintains an ind ivid u al context
for each em u lated u ser.
2.3.6
Any error that w ou ld resu lt in an invalid TPC-C transaction m u st be d etected and rep orted . An
invalid TPC-C transaction inclu d es transactions that, if com m itted , w ou ld violate the level of d atabase
consistency d efined in Clau se 3.3. These transactions m u st be rolled back. Th e d etection of these
invalid transactions m u st be rep orted to the u ser as p art of the ou tp u t screen or, in the case of the
d eferred p ortion of the d elivery transaction, the d elivery log.
Comment 1: Som e exam p les of the typ es of errors w hich cou ld resu lt in an invalid transaction are:

Select or u p d ate of a non -existent record

Failu re on insert of a new record

Failu re to d elete an existing record

Failu re on select or u p d ate of an existing record
Comment 2: The exact inform ation rep orted w hen an error occu rs is im p lem entation sp ecific and not d efined
beyond the requ irem ent that an error be rep orted .
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 27 of 130
2.4
The N ew -Order Transaction
The N ew -Ord er bu siness transaction consists of entering a com p lete ord er throu gh a single d atabase transaction . It
rep resents a m id -w eight, read -w rite transaction w ith a high frequ ency of execu tion and stringent resp onse tim e
requ irem ents to satisfy on -line u sers. This transaction is the backbone of the w orkload . It is d esigned to p lace a
variable load on the system to reflect on -line d atabase activity as typ ically fou nd in p rod u ction environm ents.
2.4.1
Input D ata Generation
2.4.1.1
For any given term inal, the hom e w arehou se nu m ber (W_ID) is constant over the w hole m easu rem e nt
interval (see Clau se 5.5).
2.4.1.2
The d istrict nu m ber (D_ID) is rand om ly selected w ithin [1 .. 10] from the hom e w arehou se (D_W_ID =
W_ID). The non -u niform rand om cu stom er nu m ber (C_ID) is selected u sing the N URand (1023,1,3000) fu nction from
the selected d istrict nu m ber (C_D_ID = D_ID) and the hom e w arehou se nu m ber (C_W_ID = W_ID).
2.4.1.3
The nu m ber of item s in the ord er (ol_cnt) is rand om ly selected w ithin [5 .. 15] (an average of 10). This
field is not entered . It is generated by the term inal em u lator to d eterm ine the size of the ord er. O_OL_CN T is later
d isp layed after being com p u ted by the SUT.
2.4.1.4
A fixed 1% of the N ew -Ord er transaction s are chosen at rand om to sim u late u ser d ata entry errors and
exercise the p erform ance of rolling back u p d ate transactions. This m u st be im p lem ented by generating a rand om
nu m ber rbk w ithin [1 .. 100].
Comment: All N ew -Ord er transaction s m u st have ind ep end ently generated inp u t d ata. The inp u t d ata from a rolled
back transaction cannot be u sed for a su bsequ ent transaction.
2.4.1.5
For each of the ol_cnt item s on the ord er:
1. A non-u niform rand om item nu m ber (OL_I_ID) is selected u sing the N URand (8191,1,100000) fu nction. If this
is the last item on the ord er and rbk = 1 (see Clau se 2.4.1.4), then the item num ber is set to an u nu sed valu e.
Comment: An unused valu e for an item nu m ber is a valu e not fou nd in the d atabase su ch that its u se w ill
p rod u ce a "not-fou nd " con d ition w ithin the ap p lication p rogram . This cond ition shou ld resu lt in rolling back
the cu rrent d atabase transaction .
2. A su p p lying w arehou se nu m ber (OL_SUPPLY_W_ID) is selected as the hom e w arehou se 99% of the tim e and
as a rem ote w arehou se 1% of the tim e. This can be imp lem ented by generating a rand om num ber x w ithin [1
.. 100];
- If x > 1, the item is su p p lied from the hom e w arehou se (OL_SUPPLY_W_ID = W_ID).
- If x = 1, the item is su p p lied from a rem ote w arehou se (OL_SUPPLY_W_ID is rand om ly selected w ithin the
range of active w arehou ses (see Clau se 4.2.2) other than W_ID).
Comment 1: With an average of 10 item s p er ord er, ap p roxim ately 90% of all ord ers can be su p p lied in fu ll by
stocks from the hom e w arehou se.
Comment 2: If the system is configu red for a single w arehou se, then all item s are su p p lied from that single
hom e w arehou se.
3. A qu antity (OL_QUAN TITY) is rand om ly selected w ithin [1 .. 10].
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 28 of 130
2.4.1.6
tim e.
The ord er entry d ate (O_EN TRY_D) is gener ated w ithin the SUT by u sing the cu rrent system d ate and
2.4.1.7
An ord er-line is said to be home if it is su p p lied by the hom e w arehou se (i.e., w hen
OL_SUPPLY_W_ID equ als O_W_ID).
2.4.1.8
An ord er-line is said to be remote w hen it is su p p lied by a rem ote w arehou se (i.e., w hen
OL_SUPPLY_W_ID d oes not equ al O_W_ID).
2.4.2
2.4.2.1
1.
Transaction Profile
Entering a new ord er is d one in a single d atabase transaction w ith the follow ing step s:
Create an ord er head er, com p rised of:
2 row selections w ith d ata retrieval,
1 row selection w ith d ata retrieval and u p d ate,
2 row insertions.
2.
Ord er a variable nu m ber of item s (average ol_cnt = 10), com p rised of:
(1 * ol_cnt) row selections w ith d ata retrieval,
(1 * ol_cnt) row selections w ith d ata retrieval and u p d ate,
(1 * ol_cnt) row insertions.
N ote: The above su m m ary is p rovid ed for inform ation only. The actu al requ irem ent is d efined by the d etailed
transaction p rofile below .
2.4.2.2
For a given w arehou se nu m ber (W_ID), d istrict nu m ber (D_W_ID , D_ID), cu stom er nu m ber (C_W_ID
, C_D_ID , C_ ID), cou nt of item s (ol_cnt, not com m u nicated to the SUT), and for a given set of item s (OL_I_ID),
su p p lying w arehou ses (OL_SUPPLY_W_ID), and qu antities (OL_QUAN TITY):
• The inp u t d ata (see Clau se 2.4.3.2) are com m u nicated to the SUT.
• A d atabase transaction is started .
• The row in the WAREH OUSE table w ith m atching W_ID is selected and W_TAX, the w arehou se tax r ate, is
retrieved .
• The row in the DISTRICT table w ith m atching D_W_ID and D_ ID is selected , D_TAX, the d istrict tax rate, is
retrieved , and D_N EXT_O_ID, the next available ord er nu m ber for the d istrict, is retrieved and increm ented
by one.
• The row in the CUSTOMER table w ith m atching C_W_ID, C_D_ID, and C_ID is selected and C_DISCOUN T,
the cu stom er's d iscou nt rate, C_LAST, the cu stom er's last nam e, and C_CREDIT, the cu stom er's cred it sta tu s,
are retrieved .
• A new row is inserted into both the N EW -ORDER table and the ORDER table to reflect the creation of the
new ord er. O_CARRIER_ID is set to a nu ll valu e. If the ord er inclu d es only hom e ord er -lines, then
O_ALL_LOCAL is set to 1, otherw ise O_ALL_LOCAL is set to 0.
• The nu m ber of item s, O_OL_CN T, is com p u ted to m atch ol_cnt.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 29 of 130
• For each O_OL_CN T item on the ord er:
-
The row in the ITEM table w ith m atching I_ID (equ als OL_I_ID) is selected and I_PRICE, the p ri ce of the
item , I_N AME, the nam e of the item , and I_DATA are retrieved . If I_ID has an u nu sed valu e (see Clau se
2.4.1.5), a "not-fou nd " cond ition is signaled , resu lting in a rollback of the d atabase transaction (see Clau se
2.4.2.3).
-
The row in the STOCK table w ith m atching S_I_ID (equ als OL_I_ID) and S_W_ID (equ als
OL_SUPPLY_W_ID) is selected . S_QUAN TITY, the quantity in stock, S_DIST_xx, w here xx rep resents the
d istrict nu m ber, and S_DATA are retrieved . If the retrieved valu e for S_QUAN TITY exceed s
OL_QUAN TITY by 10 or m ore, then S_QUAN TITY is d ecreased by OL_QUAN TITY; otherw ise
S_QUAN TITY is u p d ated to (S_QUAN TITY - OL_QUAN TITY)+91. S_YTD is increased by
OL_QUAN TITY and S_ORDER_CN T is increm ented by 1. If the or d er-line is rem ote, then
S_REMOTE_CN T is increm ented by 1.
-
The am ou nt for the item in the ord er (OL_AMOUN T) is com p u ted as:
OL_QUAN TITY * I_PRICE
-
The strings in I_DATA and S_DATA are exam ined . If they both inclu d e the string "ORIGIN AL", the brandgeneric field for that item is set to "B", otherw ise, the brand-generic field is set to "G".
-
A new row is inserted into the ORDER-LIN E table to reflect the item on the ord er. OL_DELIVERY_D is set
to a nu ll valu e, OL_N UMBER is set to a u niqu e valu e w ithin all the ORDER-LIN E row s that have the sam e
OL_O_ID valu e, and OL_DIST_IN FO is set to the content of S_DIST_xx, w here xx rep resents the d istrict
nu m ber (OL_D_ID)
• The total-amount for the com p lete ord er is com p u ted as:
su m (OL_AMOUN T) * (1 - C_DISCOUN T) * (1 + W_TAX + D_TAX)
• The d atabase transaction is com m itted , u nless it has been rolled back as a resu lt of an unused valu e for the last
item nu m ber (see Clau se 2.4.1.5).
• The ou tp u t d ata (see Clau se 2.4.3.3) are com m unicated to the term inal.
2.4.2.3
For transactions that rollback as a resu lt of an u nu sed item nu m ber, the com p lete transaction p rofile
m u st be execu ted w ith the excep tion that the follow in g step s need not be d one:
• Selecting and retrieving the row in the STOCK table w ith S_I_ID m atching the u nused item nu m ber.
• Exam ining the strings I_DATA and S_DATA for the u nu sed item .
• Inserting a new row into the ORDER-LIN E table for the u nu sed item .
• Ad d ing the am ou nt for the u nu sed item to the su m of all OL_AMOUN T.
The transaction is not com m itted . Instead , the transaction is rolled back.
Comment 1: The intent of this clau se is to ensu re that w ithin the N ew -Ord er transaction all valid item s are p rocessed
p rior to p rocessing the u nu sed item . Know led ge that an item is u nu sed , resu lting in rolling back the transaction, can
only be u sed to skip execu tion of the above step s. N o other op tim ization can resu lt from this know led ge (e.g.,
skip p ing other step s, changing the execu tion of other step s, u sing a d ifferent typ e of transaction, etc.).
Comment 2: This clau se is an excep tion to Clau se 2.3.1. The ord er of d ata m anip u lation s p rior to signaling a "not
fou nd " cond ition is im m aterial.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 30 of 130
2.4.3
Terminal I/O
2.4.3.1
For each transaction the originating term inal m u st d isp lay the follow ing inp u t/ ou tp u t screen w ith all
inp u t and ou tp u t field s cleared (w ith either sp aces or zeros) excep t for the Warehou se field w hich has not changed
and m u st d isp lay the fixed W_ID valu e associated w ith that term inal.
1
2
3
4
5
123456789012345678901234567890123456789012345678901234567
1
New Order
2 Warehouse: 9999
District: 99
3 Customer: 9999
Name: XXXXXXXXXXXXXXXX
Credit: X
4 Order Number: 99999999 Number of Lines: 99
W
5
6 Supp_W Item_Id Item Name
Qty Sto
7 9999
999999
XXXXXXXXXXXXXXXXXXXXXXXX 99
99
8 9999
999999
XXXXXXXXXXXXXXXXXXXXXXXX 99
99
9 9999
999999
XXXXXXXXXXXXXXXXXXXXXXXX 99
99
10 9999
999999
XXXXXXXXXXXXXXXXXXXXXXXX 99
99
11 9999
999999
XXXXXXXXXXXXXXXXXXXXXXXX 99
99
12 9999
999999
XXXXXXXXXXXXXXXXXXXXXXXX 99
99
13 9999
999999
XXXXXXXXXXXXXXXXXXXXXXXX 99
99
14 9999
999999
XXXXXXXXXXXXXXXXXXXXXXXX 99
99
15 9999
999999
XXXXXXXXXXXXXXXXXXXXXXXX 99
99
16 9999
999999
XXXXXXXXXXXXXXXXXXXXXXXX 99
99
17 9999
999999
XXXXXXXXXXXXXXXXXXXXXXXX 99
99
18 9999
999999
XXXXXXXXXXXXXXXXXXXXXXXX 99
99
19 9999
999999
XXXXXXXXXXXXXXXXXXXXXXXX 99
99
20 9999
999999
XXXXXXXXXXXXXXXXXXXXXXXX 99
99
21 9999
999999
XXXXXXXXXXXXXXXXXXXXXXXX 99
99
22 Execution Status: XXXXXXXXXXXXXXXXXXXXXXXX
23
24
2.4.3.2
The em u lated u ser m u st enter, in the ap p rop riate field s of the inp u t/ ou tp u t screen, th e requ ired inp u t
d ata w hich is d ivid ed in tw o grou p s and organized as follow s:
• Tw o field s: D_ID and C_ID.
Comment: The valu e for ol_cnt cannot be entered , bu t m u st be d eterm ined by the ap p lication u p on
p rocessing of the inp u t d ata.
• One rep eating grou p of field s: OL_I_ID, OL_SUPPLY_W_ID and OL_QUAN TITY. The grou p is rep eated
ol_cnt tim es (once p er item in the ord er). The valu es of these field s are chosen as per Clau se 2.4.1.5.
Comment: In ord er to m aintain a reasonable am ou nt of key ed inp u t, the su p p ly w arehou se field s m u st be
filled in for each item , even w hen the su p p ly w arehou se is the hom e w arehou se.
2.4.3.3
The em u lated term inal m ust d isp lay, in the ap p rop riate field s of the inp u t/ ou tp u t screen, all inp u t
d ata and the ou tp u t d ata resu lting from the execu tion of the transaction. The d isp lay field s are d ivid ed in tw o
grou p s as follow s:
• One non-rep eating grou p of field s: W_ID, D_ID, C_ID, O_ID, O_OL_CN T, C_LAST, C_CREDIT,
C_DISCOUN T, W_TAX, D_TAX, O _EN TRY_D, total_amount, and an op tional execu tion statu s m essage oth er
than "Item nu m ber is not valid ".
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 31 of 130
• One rep eating grou p of field s: OL_SUPPLY_W_ID, OL_I_ID, I_N AME, OL_QUAN TITY, S_QUAN TITY,
brand_generic, I_PRICE, an d OL_AMOUN T. The grou p is rep eated O_OL_CN T tim es (once p er item in th e
ord er), equ al to the com p u ted valu e of ol_cnt.
2.4.3.4
For transactions that are rolled back as a resu lt of an u nu sed item nu m ber (1% of all N ew -Ord er
transaction s), the em u lated term inal m u st d isp lay in the ap p rop riate field s of the inp u t/ ou tp u t screen the field s:
W_ID, D_ID, C_ID, C_LAST, C_CREDIT, O_ID, and the execu tion statu s m essage "Item nu m ber is not valid ". N ote
that no execu tion statu s m essage is req u ired for su ccessfu lly com m itted transactions. H ow ever, this field m ay not
d isp lay "Item nu m ber is not valid " if the transaction is su ccessfu l.
Comment: The nu m ber of the rolled back ord er, O_ID, m u st be d isp layed to verify that p art of t he transaction w as
p rocessed .
2.4.3.5
The follow ing table su m m arizes the term inal I/ O requirem ents for the N ew -Ord er transaction :
Enter
N on-rep eating
Grou p
D_ID
C_ID
Disp lay
After rollback
Disp lay
Row / Colu m n
W_ID
D_ID
C_ID
C_LAST
C_CREDIT
C_DISCOUN T
W_TAX
D_TAX
O_OL_CN T
O_ID
O_EN TRY_D
total-amount
W_ID
D_ID
C_ID
C_LAST
C_CREDIT
Coord inates
O_ID
"Item nu m ber
is not valid "
Rep eating Grou p
OL_SUPPLY_W_ID
OL_I_ID
OL_QUAN TITY
2.4.3.6
OL_SUPPLY_W_ID
OL_I_ID
I_N AME
OL_QUAN TITY
S_QUAN TITY
brand-generic
I_PRICE
OL_AMOUN T
For general term inal I/ O requ irem ents, see Clau se 2.2.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 32 of 130
2/ 12
2/ 29
3/ 12
3/ 25
3/ 52
3/ 64
4/ 51
4/ 67
4/ 42
4/ 15
2/ 61
22/ 71
22/ 19
7-22/ 3
7-22/ 10
7-22/ 20
7-22/ 45
7-22/ 51
7-22/ 58
7-22/ 63
7-22/ 72
2.5
The Payment Transaction
The Paym ent bu siness transaction u p d ates the cu stom er's balance and reflects the p aym ent on the d istrict and
w arehou se sales statistics. It rep resents a light -w eight, read -w rite transaction w ith a high frequ ency of execu tion and
stringent resp onse tim e requ irem ents to satisfy on -line u sers. In ad d ition, this transaction inclu d es non -p rim ary key
access to the CUSTOMER table.
2.5.1
Input D ata Generation
2.5.1.1
interval.
For any given term inal, the hom e w arehou se nu m ber (W_ID) is constant over the w hole m easu rem ent
2.5.1.2
The d istrict nu m ber (D_ID) is rand om ly selected w ithin [1 ..10] from the hom e w arehou se (D_W_ID) =
W_ID). The cu stom er is rand om ly selected 60% of th e tim e by last nam e (C_W_ID , C_D_ID, C_LAST) and 40% of
the tim e by nu m ber (C_W_ID , C_D_ID , C_ID). Ind ep end ent of the m od e of selection, the cu stom er resid ent
w arehou se is the hom e w arehou se 85% of the tim e and is a rand om ly selected rem ote w arehou se 15% of the tim e.
This can be im p lem ented by generating tw o rand om nu m bers x and y w ithin [1 .. 100];
• If x <= 85 a cu stom er is selected from the selected d istrict nu m ber (C_D_ID = D_ID) and the hom e w arehou se
nu m ber (C_W_ID = W_ID). The cu stom er is p aying throu gh h is/ her ow n w arehou se.
• If x > 85 a cu stom er is selected from a rand om d istrict nu m ber (C_D_ID is rand om ly selected w ithin [1 .. 10]),
and a rand om rem ote w arehou se nu m ber (C_W_ID is rand om ly selected w ithin the range of act ive
w arehou ses (see Clau se 4.2.2), and C_W_ID ≠ W_ID). The cu stom er is p aying throu gh a w arehou se and a
d istrict other than his/ her ow n.
• If y <= 60 a cu stom er last nam e (C_LAST) is generated accord ing to Clau se 4.3.2.3 from a non-u niform
rand om valu e u sing the N URand (255,0,999) fu nction. The cu stom er is u sing his/ her last nam e and is one of
the p ossibly several cu stom ers w ith that last nam e.
Comment: This case illu strates the situ ation w hen a cu stom er d oes not u se his/ h er u niqu e cu stom er nu m ber.
• If y > 60 a non-u niform rand om cu stom er nu m ber (C_ID) is selected u sing the N URand (1023,1,3000) function.
The cu stom er is u sing his/ her cu stom er nu m ber.
Comment: If the system is configu red for a single w arehou se, then all cu stom ers are selected from that single hom e
w arehou se.
2.5.1.3
The p aym ent am ou nt (H _AMOUN T) is rand om ly selected w ithin [1.00 .. 5,000.00].
2.5.1.4
The p aym ent d ate (H _DATE) in generated w ithin the SUT by u sing the cu rrent system d ate and tim e.
2.5.1.5
A Paym ent transaction is said to be home if the cu stom er belongs to the w areh ou se from w hich the
p aym ent is entered (w hen C_W_ID = W_ID).
2.5.1.6
A Paym ent transaction is said to be remote if the w arehou se from w hich the paym ent is entered is not
the one to w hich the cu stom er belongs (w hen C_W_ID d oes no t equ al W_ID).
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 33 of 130
2.5.2
Transaction Profile
2.5.2.1
The Paym ent transaction enters a cu stom er's p aym ent w ith a single d atabase transaction and is
com p rised of:
Case 1, the cu stom er is selected based on cu stom er nu m ber:
3 row selections w ith d ata retrieval and u p d ate,
1 row insertion.
Case 2, the cu stom er is selected based on cu stom er last nam e:
2 row selections (on average) w ith d ata retrieval,
3 row selections w ith d ata retrieval a nd u p d ate,
1 row insertion.
N ote: The above su m m ary is p rovid ed for inform ation only. The actu al requ irem ent is d efined by the d etailed
transaction p rofile below .
2.5.2.2
For a given w arehou se nu m ber (W_ID), d istrict nu m ber (D_W_ID , D_ID), cu stom er nu m be r (C_W_ID
, C_D_ID , C_ ID) or cu stom er last nam e (C_W_ID , C_D_ID , C_LAST), and p aym ent am ou nt (H _AMOUN T):
• The inp u t d ata (see Clau se 2.5.3.2) are com m u nicated to the SUT.
• A d atabase transaction is started .
• The row in the WAREH OUSE table w ith m atching W_ID is selected . W_N AME, W_STREET_1,
W_STREET_2, W_CITY, W_STATE, and W_ZIP are retrieved and W_YTD, the w arehou se's year -to-d ate
balance, is increased by H _ AMOUN T.
• The row in the DISTRICT table w ith m atching D_W_ID and D_ID is selected . D_N AME, D_STREET_1,
D_STREET_2, D_CITY, D_STATE, and D_ZIP are retrieved and D_YTD, the d istrict's year -to-d ate balance, is
increased by H _AMOUN T.
• Case 1, the cu stom er is selected based on cu stom er nu m ber: the row in the CUSTOMER table w ith m atching
C_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_PH ON E, C_SIN CE, C_CREDIT, C_CREDIT_LIM, C_DISCOUN T, and C_BALAN CE are
retrieved . C_BALAN CE is d ecreased by H _AMOUN T. C_YTD_PAYMEN T is increased by H _AMOUNT.
C_PAYMEN T_CN T is increm ented by 1.
Case 2, the cu stom er is selected based on cu stom er last nam e: all row s in the CUSTOMER table w ith
m atching C_W_ID, C_D_ID and C_LAST are selected sorted by C_FIRST in ascend ing ord er. Let n be the
nu m ber of row s selected . C_ID, C_FIRST, C_MIDDLE, C_STREET_1, C_STREET_2, C _CITY, C_STATE,
C_ZIP, C_PH ON E, C_SINCE, C_CREDIT, C_CREDIT_LIM, C_DISCOUN T, and C_BALAN CE are retrieved
from the row at p osition (n/ 2 rou nd ed u p to the next integer) in the sorted set of selected row s from the
CUSTOMER table. C_BALAN CE is d ecr eased by H _AMOUN T. C_YTD_PAYMEN T is increased by
H _AMOUN T. C_PAYMEN T_CN T is increm ented by 1.
• If the valu e of C_CREDIT is equ al to "BC", then C_DATA is also retrieved from the selected cu stom er and the
follow ing history inform ation: C_ID, C_D_ID, C_W_ID, D_ID, W_ID, and H _AMOUN T, are inserted at the
left of the C_DATA field by shifting the existing content of C_DATA to the right by an equ al nu m ber of bytes
and by d iscard ing the bytes that are shifted ou t of the right sid e of the C_DATA field . The content of the
C_DATA field never exceed s 500 characters. The selected cu stom er is u p d ated w ith the new C_DATA field . If
C_DATA is im p lem ented as tw o field s (see Clau se 1.4.9), they m u st be treated and op erated on as one single
field .
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 34 of 130
Comment: The form at u sed to store the history inform ation m u st be su ch that its d isp lay on the inp u t/ ou tp u t
screen is in a read able form at. (e.g. the W_ID p ortion of C_DATA m u st u se the sam e d isp lay form at as the
ou tp u t field W_ID).
• H _DATA is bu ilt by concatenating W_N AME and D_N A ME sep arated by 4 sp aces.
• A new row is inserted into the H ISTORY table w ith 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 d atabase transaction is com m itted .
• The ou tp u t d ata (see Clau se 2.5.3.3) are com m unicated to the term inal.
2.5.3
Terminal I/O
2.5.3.1
For each transaction the originating term inal m u st d isp lay the follow ing inp u t/ ou tp u t screen w ith all
inp u t and ou tp u t field s cleared (w ith either sp aces or zeros) excep t for the Warehou se field w hich has not changed
and m u st d isp lay the fixed W_ID valu e associated w ith that term inal. In ad d ition, all ad d ress field s (i.e.,
W_STREET_1, W_STREET_2, W_CITY, W_STATE, and W_ZIP) of the w arehou se m ay d isp lay the fixed valu es for
these field s if these valu es w ere alread y retrieved in a p reviou s transaction.
1
2
3
4
5
123456789012345678901234567890123456789012345678901234567
1
Payment
2 Date: DD-MM-YYYY hh:mm:ss
3
4 Warehouse: 9999
District:
5 XXXXXXXXXXXXXXXXXXXX
XXXXXXXXXX
6 XXXXXXXXXXXXXXXXXXXX
XXXXXXXXXX
7 XXXXXXXXXXXXXXXXXXXX XX XXXXX-XXXX
XXXXXXXXXX
8
9 Customer: 9999 Cust-Warehouse: 9999 Cust-District
10 Name:
XXXXXXXXXXXXXXXX XX XXXXXXXXXXXXXXXX
Si
11
XXXXXXXXXXXXXXXXXXXX
Cr
12
XXXXXXXXXXXXXXXXXXXX
%D
13
XXXXXXXXXXXXXXXXXXXX XX XXXXX-XXXX
Ph
14
15 Amount Paid:
$9999.99
New Cust-Balanc
16 Credit Limit:
$9999999999.99
17
18 Cust-Data: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
19
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
20
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
21
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
22
23
24
2.5.3.2
The em u lated u ser m u st enter, in the ap p rop riate field s of the inp u t/ ou tp u t screen, the requ i red inp u t
d ata w hich is organized as the d istinct field s: D_ID, C_ID or C_LAST, C_D_ID, C_W_ID, and H _AMOUN T.
Comment: In ord er to m aintain a reasonable am ou nt of keyed inp u t, the cu stom er w arehou se field m u st be filled in
even w hen it is th e sam e as the hom e w arehou se.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 35 of 130
2.5.3.3
The em u lated term inal m ust d isp lay, in the ap p rop riate field s of the inp u t/ ou tp u t screen, all inp u t
d ata and the ou tp u t d ata resu lting from the execu tion of the transaction. The follow ing field s are d i sp layed : 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_PH ON E, C_SIN CE, C_CREDIT, C_CREDIT_LIM, C_DISCOUN T, C_BALAN CE, the first 200
characters of C_DATA (only if C_CREDIT = "BC"), H _AMOUN T, and H _DATE.
2.5.3.4
The follow ing table su m m arizes the term inal I/ O requirem ents for the Paym ent transaction :
Enter
N on-rep eating Grou p
D_ID
C_ID 1
C_D_ID
C_W_ID
H _AMOUN T
C_LAST 2
Disp lay
Row / Colu m n
W_ID
D_ID
C_ID
C_D_ID
C_W_ID
H _AMOUN T
H _DATE
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_PH ON E
C_SIN CE
C_CREDIT
C_CREDIT_LIM
C_DISCOUN T
C_BALAN CE
C_DATA 3
Coord inates
4/ 12
4/ 52
9/ 11
9/ 54
9/ 33
15/ 24
2/ 7
5/ 1
6/ 1
7/ 1
7/ 22
7/ 25
5/ 42
6/ 42
7/ 42
7/ 63
7/ 66
10/ 9
10/ 26
10/ 29
11/ 9
12/ 9
13/ 9
13/ 30
13/ 33
13/ 58
10/ 58
11/ 58
16/ 18
12/ 58
15/ 56
18-21/ 12
1 Enter only for p aym ent by cu stom er nu m ber
Enter only for p aym ent by cu stom er last na m e
Disp lay the first 200 characters only if C_CREDIT = "BC"
2.5.3.5
For general term inal I/ O requ irem ents, see Clau se 2.2.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 36 of 130
2
3
2.6
The Order-Status Transaction
The Ord er-Statu s bu siness transaction qu eries the statu s of a cu stom er's last ord er. It rep resents a m id -w eight read only d atabase transaction w ith a low frequ ency of execu tion a nd resp onse tim e requ irem ent to satisfy on -line u sers.
In ad d ition, this table inclu d es non -p rim ary key access to the CUSTOMER table.
2.6.1
Input D ata Generation
2.6.1.1
interval.
For any given term inal, the hom e w arehou se nu m ber (W_ID) is constant over the w hole m easu rem ent
2.6.1.2
The d istrict nu m ber (D_ID) is rand om ly selected w ithin [1 ..10] from the hom e w arehou se. The
cu stom er is rand om ly selected 60% of the tim e by last nam e (C_W_ID, C_D_ID, C_LAST) and 40% of the tim e by
nu m ber (C_W_ID, C_D_ID, C_ID) from the selected d istrict (C_D_ID = D_ID) and the hom e w arehou se nu m ber
(C_W_ID = W_ID). This can be im p lem ented by generating a rand om nu m ber y w ithin [1 .. 100];
• If y <= 60 a cu stom er last nam e (C_LAST) is generated accord ing to Clau se 4.3.2.3 from a non -u niform
rand om valu e u sing the N URand (255,0,999) fu nction. The cu stom er is u sing his/ her last nam e and is one of
the, p ossibly several, cu stom ers w ith that last nam e.
Comment: This case illu strates the situ ation w hen a cu stom er d oes not u se his/ h er u niqu e cu stom er nu m ber.
• If y > 60 a non-u niform rand om cu stom er nu m ber (C_ID) is selected u sing the N URand (1023,1,3000) function.
The cu stom er is u sing his/ her cu stom er nu m ber.
2.6.2
2.6.2.1
1.
Transaction Profile
Qu erying for the statu s of an ord er is d one in a single d atabase transaction w ith the follow ing step s:
Find the cu stom er and his/ her last ord er, com p rised of:
Case 1, the cu stom er is selected based on cu stom er nu m ber:
2 row selections w ith d ata retrieval.
Case 2, the cu stom er is selected based on cu stom er last nam e:
4 row selections (on average) w ith d ata retrieval.
2.
Check statu s (d elivery d ate) of each item on the ord er (average item s -p er-ord er = 10), com p rised of:
(1 * item s-p er-ord er) row selections w ith d ata retrieval.
N ote: The above su m m ary is p rovid ed for inform ation only. The actu al requ irem ent is d efined by the d etailed
transaction p rofile below .
2.6.2.2
For a given cu stom er nu m ber (C_W_ID , C_D_ID , C_ ID):
• The inp u t d ata (see Clau se 2.6.3.2) are com m u nicated to the SUT.
• A d atabase transaction is started .
• Case 1, the cu stom er is selected based on cu stom er nu m ber: the row in the CUSTOMER table w ith m atching
C_W_ID, C_D_ID, and C_ID is selected and C_BALAN CE, C_FIRST, C_MIDDLE, and C_LAST are retrieved .
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 37 of 130
Case 2, the cu stom er is selected based on cu stom er last nam e: all row s in the CUSTOMER table w ith
m atching C_W_ID, C_D_ID and C_LAST are selected sorted by C_FIRST in ascend ing ord er. Let n be the
nu m ber of row s selected . C_BALAN CE, C_FIRST, C_MIDDLE, and C_LAST are retrieved from the row at
p osition n/ 2 rou nd ed u p in the sorted set of selected row s from the CUSTOMER table.
• The row in the ORDER table w ith m atching O_W_ID (equ als C_W_ID), O_D_ID (equ als C_D_ID), O_C_ID
(equ als C_ID), and w ith the largest existing O_ID, is selected . This is the m ost recent ord er p laced by that
cu stom er. O_ID, O_EN TRY_D, and O_CARRIER_ID are retrieved .
• All row s in the ORDER-LIN E table w ith m atching OL_W_ID (equ als O_W_ID), OL_D_ID (equ als O_D_ID),
and OL_O_ID (equ als O_ID) are selected and the corresp ond ing sets of OL_I_ID, OL_SUPPLY_W_ID,
OL_QUAN TITY, OL_AMOUN T, and OL_DELIVERY_D are retrieved .
• The d atabase transaction is com m itted .
Comment: a com m it is not requ ired as long as all ACID p rop erties are satisfied (see Clau se 3).
• The ou tp u t d ata (see Clau se 2.6.3.3) are com m unicated to the term inal.
2.6.3
Terminal I/O
2.6.3.1
For each transaction the originating term inal m u st d isp lay the follow ing inp u t/ ou tp u t screen w ith all
inp u t and ou tp u t field s cleared (w ith either sp aces or zeros) excep t for the Warehou se field w hich has not changed
and m u st d isp lay the fixed W_ID valu e associated w ith that term inal.
1
2
3
4
5
123456789012345678901234567890123456789012345678901234567
Order-Status
1
District: 99
2 Warehouse: 9999
Name: XXXXXXXXXXXXXXXX XX XXXXXXXX
3 Customer: 9999
4 Cust-Balance: $-99999.99
5
Entry-Date: DD-MM-YYYY hh:
6 Order-Number: 99999999
Item-Id
Qty
Amount
Deliver
7 Supply-W
9999
999999
99
$99999.99
DD-MM
8
9999
999999
99
$99999.99
DD-MM
9
9999
999999
99
$99999.99
DD-MM
10
9999
999999
99
$99999.99
DD-MM
11
9999
999999
99
$99999.99
DD-MM
12
9999
999999
99
$99999.99
DD-MM
13
9999
999999
99
$99999.99
DD-MM
14
9999
999999
99
$99999.99
DD-MM
15
9999
999999
99
$99999.99
DD-MM
16
9999
999999
99
$99999.99
DD-MM
17
9999
999999
99
$99999.99
DD-MM
18
9999
999999
99
$99999.99
DD-MM
19
9999
999999
99
$99999.99
DD-MM
20
9999
999999
99
$99999.99
DD-MM
21
9999
999999
99
$99999.99
DD-MM
22
23
24
2.6.3.2
The em u lated u ser m u st enter, in the ap p rop riate field of the inp u t/ ou tp u t screen, the requ ired inp u t
d ata w hich is organized as the d istinct field s: D_ID and either C_ID or C_LAST.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 38 of 130
2.6.3.3
The em u lated term inal m ust d isp lay, in the ap p rop riate field s of the inp u t/ ou tp u t screen, all inp u t
d ata and the ou tp u t d ata resu lting from the execu tion of the transaction. The d isp lay field s are d ivid ed in tw o
grou p s as follow s:
• One non-rep eating grou p of field s: W_ID, D_ID, C_ID, C_FIRST, C_MIDDLE, C_LAST, C_BALAN CE, O_ID,
O_EN TRY_D, and O_CARRIER_ID;
• One rep eating grou p of field s: OL_SUPPLY_W_ID, OL_I_ID, OL_QUANTITY, OL_AMOUN T, and
OL_DELIVERY_D. The grou p is rep eated O_OL_CN T tim es (once p er item in the ord er).
Comment 1: The ord er of item s show n on the Ord er -Statu s screen d oes not need to m atch the ord er in w hich the
item s w ere entered in its corresp ond ing N ew -Ord er screen.
Comment 2: If OL_DELIVERY_D is nu ll (i.e., the ord er has not been d elivered ), the term inal m u st d isp lay an
im p lem entation sp ecific nu ll d ate rep resentation (e.g., blanks, 99-99-9999, etc.). The chosen nu ll d ate rep resentation
m u st not change d u ring the test.
2.6.3.4
The follow ing table su m m arizes the term inal I/ O requirem ents for the Ord er-Statu s transaction :
Enter
N on-rep eating Grou p
D_ID
C_ID 1
C_LAST 2
Rep eating Grou p
Disp lay
Row / Colu m n
Coord inates
W_ID
D_ID
C_ID
C_FIRST
C_MIDDLE
C_LAST
C_BALAN CE
O_ID
O_EN TRY_D
O_CARRIER_ID
OL_SUPPLY_W_ID
OL_I_ID
OL_QUAN TITY
OL_AMOUN T
OL_DELIVERY_D
2/
2/
3/
3/
3/
3/
4/
6/
6/
6/
8-22/ 3
8-22/ 14
8-22/ 25
8-22/ 33
8-22/ 47
1 Enter only for qu ery by cu stom er nu m ber.
Enter only for qu ery by cu stom er last nam e.
2.6.3.5
12
29
11
24
41
44
16
15
38
76
For general term inal I/ O requ irem ents, see Clau se 2.2.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 39 of 130
2
2.7
The D elivery Transaction
The Delivery bu siness tran saction consists of p rocessing a batch of 10 new (not yet d elivered ) ord ers. Each ord er is
p rocessed (d elivered ) in full w ithin the scop e of a read -w rite d atabase transaction . The nu m ber of ord ers d elivered
as a grou p (or batched ) w ithin the sam e d atabase transaction is im p lem entation sp ecific. The bu siness transaction,
com p rised of one or m ore (u p to 10) d atabase transactions, has a low frequ ency of execu tion and m u st com p lete
w ithin a relaxed resp onse tim e requ irem ent.
The Delivery transaction is intend ed to be execu ted in d eferred m od e throu gh a qu eu ing m echanism , rather than
interactively, w ith term inal resp onse ind icating transaction com p letion. The resu lt of the d eferred execu tion is
record ed into a resu lt file.
2.7.1
Input D ata Generation
2.7.1.1
interval.
For any given term inal, the hom e w arehou se nu m ber (W_ID) is constant over the w hole m easu rem ent
2.7.1.2
The carrier nu m ber (O_CARRIER_ID) is rand om ly selected w ithin [1 .. 10].
2.7.1.3
and tim e.
The d elivery d ate (OL_DELIVERY_D) is generated within the SUT by u sing the cu rrent system d ate
2.7.2
D eferred Execution
2.7.2.1
Unlike the other transactions in this benchm ark, the Delivery transaction m u st be execu ted in d eferred
m od e. This m od e of execu tion is p rim arily characterized by qu eu ing the transaction for d efe rred execu tion,
retu rning control to the originating term inal ind ep end ently from the com p letion of the transaction, and record ing
execu tion inform ation into a resu lt file.
2.7.2.2
Deferred execu tion of the Delivery transaction m u st ad here to the follow ing ru les:
1. The bu siness transaction is qu eu ed for d eferred execu tion as a resu lt of entering the last inp u t character.
2. The d eferred execu tion of the bu siness transaction m u st follow the p rofile d efined in Clau se 2.7.4 w ith the
inp u t d ata d efined in Clau se 2.7.1 as entered throu gh the inp u t/ ou tp u t screen and com m unicated to the
d eferred execu tion qu eu e.
3. At least 90% of the bu siness transaction s m u st com p lete w ithin 80 second s of their being qu eu ed for
execu tion.
4. Up on com p letion of the bu siness transaction , the follow ing inform ation m u st have been record ed into a resu lt
file:
•
The tim e at w hich the bu siness transaction w as qu eu ed .
•
The w arehou se nu m ber (W_ID) and the carried nu m ber (O_CARRIER_ID) associated w ith the bu siness
transaction.
•
The d istrict nu m ber (D_ID) and the ord er nu m ber (O_ID) of each ord er d elivered by the bu siness
transaction.
•
The tim e at w hich the bu siness transaction com p leted .
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 40 of 130
2.7.2.3
The result file associated w ith the d eferred execu tion of the Delivery b u siness transaction is only for
the p u rp ose of record ing inform ation abou t that transaction and is not relevant to the bu siness fu nction being
p erform ed . The resu lt file m u st ad here to the follow in g ru les:
1.
All events m u st be com p leted before the related inform ation is record ed (e.g., the record ing of a d istrict
and ord er nu m ber m u st be d one after the d atabase transaction , w ithin w hich this ord er w as d elivered , has
been com m itted );
2.
N o ACID p rop erty is requ ired (e.g., the record ing of a d istrict and ord er nu m ber is not requ ired to be
atom ic w ith the actu al d elivery of that ord er) as the resu lt file is u sed for benchm arking p u rp oses only.
3.
Du ring the m easu rem ent interval the resu lt file m u st be located either on a d u rable m ed iu m (see clau se
3.5.1) or in the internal m em ory of the SUT. In this last case, the resu lt file m u st be transferred onto a
d u rable m ed iu m after the last m easu rem ent interval of the test ru n (see Clau se 5.5).
2.7.3
Terminal I/O
2.7.3.1
For each transaction the originating term inal m u st d isp lay the follow ing inp u t/ ou tp u t screen w ith all
inp u t and ou tp u t field s cleared (w ith either sp aces or zeros) excep t for the Warehou se field w hich has not changed
and m u st d isp lay the fixed W_ID valu e associated w ith that term inal.
1
2
3
4
5
123456789012345678901234567890123456789012345678901234567
1
Delivery
2 Warehouse: 9999
3
4 Carrier Number: 99
5
6 Execution Status: XXXXXXXXXXXXXXXXXXXXXXXXX
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
2.7.3.2
The em u lated u ser m u st enter, in the ap p rop riate inp u t field of the inp u t/ ou tp u t screen, the requ ired
inp u t d ata w hich is organized as one d istinct field : O_CARRIER_ID.
2.7.3.3
The em u lated term inal m ust d isp lay, in the ap p rop riate ou tp u t field of the inp u t/ ou tp u t screen, all
inp u t d ata and the ou tp u t d ata w hich resu lts from t he qu eu ing of the transaction. The follow ing field s are d isp layed :
W_ID, O_CARRIER_ID, and the statu s m essage "Delivery has been qu eu ed ".
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 41 of 130
2.7.3.4
The follow ing table su m m arizes the term inal I/ O requirem ents for the Delivery transaction :
Enter
N on-rep eating Grou p
O_CARRIER_ID
2.7.3.5
2.7.4
Disp lay
Row / Colu m n
Coord inates
W_ID
O_CARRIER_ID
"Delivery has been qu eu ed "
2/ 12
4/ 17
6/ 19
For general term inal I/ O requ irem ents, see Clau se 2.2.
Transaction Profile
2.7.4.1
The d eferred execu tion of the Delivery transaction d elivers one ou tstand ing ord er (average item s-p erord er = 10) for each one of the 10 d istricts of the selected w arehou se u sing one or m ore (u p to 10) d atabase
transaction s. Delivering each ord er is d one in the follow ing step s:
1.
Process the ord er, com p rised of:
1 row selection w ith d ata retrieval,
(1 + item s-p er-ord er) row selections w ith d ata retrieval and u p d ate.
2.
Up d ate the cu stom er's balance, com p rised of:
1 row selections w ith d ata u p d ate.
3.
Rem ove the ord er from the new -ord er list, com p rised of:
1 row d eletion.
Comment: This bu siness transaction can be d one w ithin a single d atabase tr ansaction or broken d ow n into u p to 10
d atabase transactions to allow the test sp onsor the flexibility to im p lem ent the bu siness transaction w ith th e m ost
efficient nu m ber of d atabase transactions.
N ote: The above su m m ary is p rovid ed for inform ation only. The actu al requ irem ent is d efined by the d etailed
transaction p rofile below .
2.7.4.2
For a given w arehou se nu m ber (W_ID), for each of the 10 d istricts (D_W_ID , D_ID) w ithin that
w arehou se, and for a given carrier nu m ber (O_CARRIER_ID):
• The inp u t d ata (see Clau se 2.7.3.2) are retrieved from the d eferred execu tion qu eu e.
• A d atabase transaction is started u nless a d atabase transaction is alread y active from being started as par t of
the d elivery of a p reviou s ord er (i.e., m ore than one ord er is d elivered w ithin the sam e d atabase transaction).
• The row in the N EW-ORDER table w ith m atching N O_W_ID (equ als W_ID) and N O_D_ID (equ als D_ID)
and w ith the low est N O_O_ID valu e is selected . This is the old est u nd elivered ord er of that d istrict.
N O_O_ID, the ord er nu m ber, is retrieved . If no m atching row is fou nd , then the d elivery of an ord er for this
d istrict is skip p ed . The cond ition in w hich no ou tstand in g ord er is p resent at a given d istrict m u st be hand led
by skip p ing the d elivery of an ord er for that d istrict only and resu m ing the d elivery of an ord er from all
rem aining d istricts of the selected w arehou se. If this cond ition occu rs in m ore than 1%, or in m ore than one,
w hichever is greater, of the bu siness transaction s, it m u st be rep orted . The resu lt file m u st be organized in
su ch a w ay that the p ercentage of skip p ed d eliveries and skip p ed d istricts can be d eterm ined .
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 42 of 130
• The selected row in the N EW-ORDER table is d eleted .
• The row in the ORDER table w ith m atching O_W_ID (equ als W_ ID), O_D_ID (equ als D_ID), and O_ID
(equ als N O_O_ID) is selected , O_C_ID, the cu stom er nu m ber, is retr ieved , and O_CARRIER_ID is u p d ated .
• All row s in the ORDER-LIN E table w ith m atching OL_W_ID (equ als O_W_ID), OL_D_ID (equ als O_D_ID),
and OL_O_ID (equ als O_ID) are selected . All OL_DELIVERY_D, the d elivery d ates, are u p d ated to the
cu rrent system tim e as retu rned by the op erating system and the su m of all OL_AMOUN T is retrieved .
• The row in the CUSTOMER table w ith m atching C_W_ID (equ als W_ID), C_D_ID (equ als D_ID), and C_ID
(equ als O_C_ID) is selected and C_BALAN CE is increased by the su m of all ord er -line am ou nts
(OL_AMOUN T) p reviou sly retrieved . C_DELIVERY_CN T is increm ented by 1.
• The d atabase transaction is com m itted u nless m ore ord ers w ill be d elivered w ithin this d atabase transaction.
• Inform ation abou t the d elivered ord er (see Clau se 2.7.2.2) is record ed into the resu lt file (see Clau se 2.7.2.3).
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 43 of 130
2.8
The Stock-Level Transaction
The Stock-Level bu siness transaction d eterm ines the nu m ber of recently sold item s that have a stock level below a
sp ecified threshold . It rep resents a heavy read -only d atabase transaction w ith a low frequ ency of execu tion, a
relaxed resp onse tim e requ irem ent, and relaxed consistency requ irem ents.
2.8.1
Input D ata Generation
2.8.1.1
Each term inal m u st u se a u niqu e valu e of (W_ID, D_ID) that is constant over the w hole
m easu rem ent, i.e., D_IDs cannot be re-u sed w ithin a w arehou se.
2.8.1.2
2.8.2
The threshold of m inim um qu antity in stock (threshold ) is selected at rand om w ithin [10 .. 20].
Transaction Profile
2.8.2.1
Exam ining the level of stock for item s on the last 20 ord ers is d one in one or m ore d atabase
transaction s w ith the follow ing step s:
1.
Exam ine the next available ord er nu m ber, com p rised of:
1 row selection w ith d ata retrieval.
2.
Exam ine all item s on the last 20 ord ers (average item s-p er-ord er = 10) for the d istrict, com p rised of:
(20 * item s-p er-ord er) row selections w ith d ata retrieval.
3.
Exam ine, for each d istinct item selected , if the level of stock available at the hom e w arehou se is be low the
threshold , com p rised of:
At m ost (20 * item s-p er-ord er) row selections w ith d ata retrieval.
N ote: The above su m m ary is p rovid ed for inform ation only. The actu al requ irem ent is d efined by the d etailed
transaction p rofile below .
2.8.2.2
(threshold):
For a given w arehou se nu m ber (W_ID), d istrict nu m ber (D_W_ID , D_ID), and stock level threshold
• The inp u t d ata (see Clau se 2.8.3.2) are com m u nicated to the SUT.
• A d atabase transaction is started .
• The row in the DISTRICT table w ith m atching D_W_ID and D_ID is selected and D_N EXT_O_ID is retrieved .
• All row s in the ORDER-LIN E table w ith m atching OL_W_ID (equ als W_ID), OL_D_ID (equ als D_ID), and
OL_O_ID (low er than D_N EXT_O_ID an d greater than or equ al to D_N EXT_O_ID m inu s 20) are selected .
They are the item s for 20 recent ord ers of the d istrict.
• All row s in the STOCK table w ith m atching S_I_ID (equ als OL_I_ID) and S_W_ID (equ als W_ID) from the list
of d istinct item nu m bers and w ith S_QUAN TITY low er than threshold are cou nted (giving low_stock).
Comment: Stocks m u st be cou nted only for d istinct item s. Thu s, item s that have been ord ered m ore than once
in the 20 selected ord ers m u st be aggregated into a sin gle su m m ary cou nt for t hat item .
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 44 of 130
• The cu rrent d atabase transaction is com m itted .
Comment: A com m it is not need ed as long as all the requ ired ACID p rop erties are satisfied (see Clau se
2.8.2.3).
• The ou tp u t d ata (see Clau se 2.8.3.3) are com m unicated to the term inal.
2.8.2.3
Full serializability and rep eatable read s are not requ ired for the Stock -Level bu siness transaction . All
d ata read m u st be com m itted and no old er than the m ost recently com m itted d ata p rior to the tim e this bu siness
transaction w as initiated . All other ACID p rop erties m u st be m aintained .
Comment: This clau se allow s the bu siness transaction to be broken d ow n into m ore than one d atabase transaction .
2.8.3
Terminal I/O
2.8.3.1
For each transaction the originating term inal m u st d isp lay the follow ing inp u t/ ou tp u t screen w ith all
inp u t and ou tp u t field s cleared (w ith either sp aces or zeros) excep t for the Warehou se and District field s w hich have
not changed and m u st d isp lay the fixed W_ID and D_ID valu es associated w ith that term inal.
1
2
3
4
5
12345678901234567890123456789012345678901234567890123456
1
Stock-Level
2 Warehouse: 9999
District: 99
3
4 Stock Level Threshold: 99
5
6 low stock: 999
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
2.8.3.2
The em u lated u ser m u st enter, in the ap p rop riate field of the inp u t/ ou tp u t screen, the requ ired inp u t
d ata w hich is organized as the d istinct field : threshold.
2.8.3.3
The em u lated term inal m u st d isp lay, in the ap p rop riate field of the inp u t/ ou tp u t screen, all inp u t d ata
and the ou tp u t d ata w hich resu lts from the execu tion of the transaction. The follow ing field s are d isp layed : W_ID,
D_ID, threshold, and low_stock.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 45 of 130
2.8.3.4
The follow ing table su m m arizes the term inal I/ O requirem ents for the Stock-Level transaction :
Enter
N on-rep eating Grou p
threshold
2.8.3.5
Disp lay
Row / Colu m n
Coord inates
W_ID
D_ID
threshold
low _stock
For general term inal I/ O requ irem ents, see Clau se 2.2.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 46 of 130
2/
2/
4/
6/
12
29
24
12
Clause 3: TRAN SACTION and SYSTEM PROPERTIES
3.1
The ACID Properties
It is the intent of this section to inform ally d efine the ACID p rop erties and to sp ecify a series of tests that m u st be
p erform ed to d em onstrate that these p rop erties are m et.
3.1.1
The ACID (Atom icity, Consistency, Isolation , and Du rability) p rop erties of transaction p rocessing
system s m u st be su p p orted by the system u nd er test d u ring the ru nning of this benchm ark. The only excep tion to
this ru le is to allow non -rep eatable read s for the Stock-Level transaction (see Clau se 2.8.2.3).
3.1.2
N o finite series of tests can p rove that the ACID p rop erties are fu lly su p p orted . Passing the sp ecified
tests is a necessary, bu t n ot su fficient, cond ition for m eeting the ACID requ irem ents. H ow ever, for fairness of
rep orting, only the tests sp ecified here are requ ired and m u st ap p ear in the Full Disclosu re Rep ort for this
benchm ark.
Comment: These tests are intend ed to d em onstrate th at the ACID p rincip les are su p p orted by the SUT and enabled
d u ring the p erform ance m easu rem ent interval. They are not intend ed to be an exhau stive qu ality assu rance test.
3.1.3
All m echanism s need ed to insu re fu ll ACID p rop erties m u st be enabled d u ring both the test p eriod
and the 8 hou rs of stead y state. For exam p le, if the system u nd er test relies on u nd o logs, then logging m u st be
enabled for all transactions inclu d ing those w hich d o not inclu d e rollback in the transaction p rofile. When this
benchm ark is im p lem ented on a d istribu ted system , tests m u st be p erform ed to verify that hom e and rem ote
transactions, inclu d ing rem ote transactions that are p rocessed on tw o or m ore nod es, satisfy the ACID p rop erties
(See Clau ses 2.4.1.7, 2.4.1.8, 2.5.1.5, and 2.5.1.6 for th e d efinition of hom e and rem ote transactions).
3.1.4
Althou gh the ACID tests d o not exercise all transaction typ es of TPC-C, the ACID p rop erties m u st be
satisfied for all the TPC-C transactions.
3.1.5
Test sp onsors rep orting TPC resu lts m ay p erform ACID tests on any one system for w hich resu lts
have been d isclosed , p rovid ed that they u se the sam e softw are execu tables (e.g., op erating system , d ata m anager,
transaction p rogram s). For exam p le, this clau se w ou ld be ap p licable w hen resu lts are rep orted for m u ltip le system s
in a p rod u ct line. H ow ever, the d u rability tests d escribed in Clau ses 3.5.3.2 and 3.5.3.3 m u st be ru n on all the system s
that are m easu red . All Fu ll Disclosu re Rep orts m u st id entify the system s w hich w ere u sed to verify ACID
requ irem ents and fu ll d etails of the ACID tests cond u cted and resu lts obtained .
Comment: All requ ired ACID tests m u st be p erform ed on new ly op tim ized binaries even if there have not been any
sou rce cod e changes.
3.2
Atomicity Requirements
3.2.1
Atomicity Property D efinition
The system u nd er test m ust gu arantee that d ata base transaction s are atom ic; the system w ill either p erform all
ind ivid u al op erations on the d ata, or w ill assu re that no p artially -com p leted op erations leave any effects on the d ata.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 47 of 130
3.2.2
Atomicity Tests
3.2.2.1
Perform the Paym ent transaction for a rand om ly selected w arehou se, d istrict, and cu stom er (by
cu stom er nu m ber as sp ecified in Clau se 2.5.1.2) and verify that the record s in the CUSTOMER , DISTRICT, and
WAREH OUSE tables have been changed ap p rop riately.
3.2.2.2
Perform the Paym ent transaction for a rand om ly selected w arehou se, d istrict, and cu stom er (by
cu stom er nu m ber as sp ecified in Clau se 2.5.1.2) and su bstitu te a ROLLBACK of the transaction for the COMMIT of
the transaction. Verify that the record s in the CUSTOMER, DISTRICT, and WAREH OUSE tables have N OT been
changed .
3.3
Consistency Requirements
3.3.1
Consistency Property D efinition
Consistency is the p rop erty of the ap p lication that requ ires any execu tion of a d atabase transaction to take the
d atabase from one consistent state to another, assu m ing that the d atabase is initially in a consistent state .
3.3.2
Consistency Conditions
Tw elve consistency cond itions are d efined in the follow ing clau ses to sp ecify the level of d atabase consistency
requ ired across the m ix of TPC-C transactions. A d atabase, w hen p op u lated as d efined in Clau se 4.3, m u st m eet all
of these cond itions to be consistent. If d ata is rep licated , each cop y m u st m eet these cond itions. Of the tw elve
cond itions, exp licit d em onstration that the cond itions are satisfied is requ ired for the first fou r only. Dem onstration
of the last eight consistency cond itions is not requ ired becau se of the lengthy tests w hich w ou ld be necessary.
Comment 1: The consistency cond itions w ere chosen so that they w ou ld rem ain valid w ithin the context of a larger
ord er-entry ap p lication that inclu d es the five TPC-C transactions (See Clau se 1.1.). They are d esigned to be
ind ep end ent of the length of tim e for w hich su ch an ap p lication w ou ld be e xecu ted . Thu s, for exam p le, a cond ition
involving I_PRICE w as not inclu d ed here since it is conceivable that w ithin a larger ap p lication I_PRICE is m od ified
from tim e to tim e.
Comment 2: For Consistency Cond itions 2 and 4 (Clau ses 3.3.2.2 and 3.3.2.4), sam p ling the first, last, and tw o
rand om w arehou ses is su fficient.
3.3.2.1
Consistency Cond ition 1
Entries in the WAREH OUSE and DISTRICT tables m ust satisfy the relationship :
W_YTD = su m (D_YTD)
for each w arehou se d efined by (W_ID = D_W_ID).
3.3.2.2
Consistency Cond ition 2
Entries in the DISTRICT, ORDER, and N EW-ORDER tables m u st satisfy the relationship :
D_N EXT_O_ID - 1 = m ax(O_ID) = m ax(N O_O_ID)
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 48 of 130
for each d istrict d efined by (D_W_ID = O_W_ID = N O_W_ID) and (D_ID = O_D_ID = N O_D_ID). This cond ition
d oes not ap p ly to the N EW-ORDER table for any d istricts w hich have no ou tstand ing new ord ers (i.e., the nu m be r of
row s is zero).
3.3.2.3
Consistency Cond ition 3
Entries in the N EW-ORDER table m u st satisfy the relationship :
m ax(N O_O_ID) - m in(NO_O_ID) + 1 = [nu m ber of row s in the N EW -ORDER table for this d istrict]
for each d istrict d efined by N O_W_ID and N O_D_ID. This cond ition d oes not ap p ly to any d istricts w hich have no
ou tstand ing new ord ers (i.e., the num ber of row s is zero).
3.3.2.4
Consistency Cond ition 4
Entries in the ORDER and ORDER-LIN E tables m u st satisfy the relationship :
su m (O_OL_CN T) = [nu m ber of row s in the ORDER-LIN E table for this d istrict]
for each d istrict d efined by (O_W_ID = OL_W_ID) and (O_D_ID = OL_D_ID).
3.3.2.5
Consistency Cond ition 5
For any row in the ORDER table, O_CARRIER_ID is set to a nu ll valu e if and only if there is a corresp ond ing row in
the N EW-ORDER table d efined by (O_W_ID, O_D_ID, O_ID) = (N O_W_ID, N O_D_ID, N O_O_ID).
3.3.2.6
Consistency Cond ition 6
For any row in the ORDER table, O_OL_CN T m u st equ al the nu m ber of row s in the ORDER-LIN E table for the
corresp ond ing ord er d efin ed by (O_W_ID, O_D_ID, O_ID) = (OL_W_ID, OL_D_ID, OL_O_ID).
3.3.2.7
Consistency Cond ition 7
For any row in the ORDER-LIN E table, OL_DELIVERY_D is set to a nu ll d ate/ tim e if and only if the corresp ond ing
row in the ORDER table d efined by (O_W_ID, O_D_ID, O_ID) = (OL_W_ID, OL_D_ID, OL_O_ID) has
O_CARRIER_ID set to a null valu e.
3.3.2.8
Consistency Cond ition 8
Entries in the WAREH OUSE and H ISTORY tables m u st satisfy the relationship :
W_YTD = su m (H _AMOUN T)
for each w arehou se d efined by (W_ID = H _W_ID).
3.3.2.9
Consistency Cond ition 9
Entries in the DISTRICT and H ISTORY tables m u st satisfy the relationship :
D_YTD = su m (H _AMOUN T)
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 49 of 130
for each d istrict d efined by (D_W_ID, D_ID) = (H _W_ID, H _D_ID).
3.3.2.10
Consistency Cond ition 10
Entries in the CUSTOMER, H ISTORY, ORDER, and ORDER-LIN E tables m u st satisfy the relationship :
C_BALAN CE = su m (OL_AMOUN T) - su m (H _AMOUN T)
w here:
H _AMOUN T is selected by (C_W_ID, C_D_ID, C_ID) = (H _C_W_ID, H _C_D_ID, H _C_ID)
and
OL_AMOUN T is selected by:
(OL_W_ID, OL_D_ID, OL_O_ID) = (O_W_ID, O_D_ID, O_ID) and
(O_W_ID, O_D_ID, O_C_ID) = (C_W_ID, C_D_ID, C_ID) and
(OL_DELIVERY_D is not a nu ll valu e)
3.3.2.11
Consistency Cond ition 11
Entries in the CUSTOMER, ORDER and N EW-ORDER tables m u st satisfy the relationship :
(cou nt(*) from ORDER) - (cou nt(*) from N EW-ORDER) = 2100
for each d istrict d efined by (O_W_ID, O_D_ID) = (N O_W_ID, N O_D_ID) = (C_W_ID, C_D_ID).
3.3.2.12
Consistency Cond ition 12
Entries in the CUSTOMER and ORDER-LIN E tables m u st satisfy the relationship :
C_BALAN CE + C_YTD_PAYMEN T = su m (OL_AMOUN T)
for any rand om ly selected cu stom ers and w here OL_DELIVERY_D is not set to a nu ll d ate/ tim e.
3.3.3
Consistency Tests
3.3.3.1
Verify that the d atabase is initially consistent by verifying that it m eets the consistency cond itions
d efined in Clau ses 3.3.2.1 to 3.3.2.4. Describe the step s u sed to d o this in su fficient d etail so that the step s ar e
ind ep end ently rep eatable.
3.3.3.2
Im m ed iately after p erform ing the verification p rocess d escribed in Clau se 3.3.3.1, d o the follow ing:
1.
Use the stand ard d riving m echanism to su bm it transactions to the SUT. The transaction rate m u st be at
least 90% of the rep orted tp m C rate and m eet all other requ irem ents of a rep orted m easu rem ent interval
(see Clau se 5.5). The test sp onsor m u st inclu d e at least one check -p oint (as d efined in Clau se 5.5.2.2)
w ithin this interval. The SUT m u st be ru n at this rate for a t least 5 m inu tes.
2.
Stop su bm itting transactions to the SUT and then repeat the verification step s d one for Clau se 3.3.3.1. The
d atabase m u st still be consistent after ap p lying transactions. Consistency Cond ition 4 need only be
verified for row s ad d ed to the ORDER and ORDER-LIN E tables since the p reviou s verification.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 50 of 130
3.4
Isolation Requirements
3.4.1
Isolation Property D efinition
Isolation can be d efined in term s of p henom ena that can occu r d u ring the execu tion of concu rrent d atabase
transaction s. The follow in g p henom ena are p ossible:
P0 ("Dirty Write"): Database transaction T1 read s a d ata elem ent and m od ifies it. Database transaction T2 then
m od ifies or d eletes that d ata elem ent, and p erform s a COMMIT. If T1 w ere to attem p t to re-read the d ata
elem ent, it m ay receive the m od ified valu e from T2 or d iscover that the d ata elem ent has been d eleted .
P1 ("Dirty Read "): Database transaction T1 m od ifies a d ata elem ent. Database transaction T2 then read s that d ata
elem ent before T1 p erform s a COMMIT. If T1 w ere to p erform a ROLLBACK, T2 w ill have read a valu e that
w as never com m itted and that m ay thu s be consid ered to have never existed .
P2 ("N on -rep eatable Read "): Database transaction T1 read s a d ata elem ent. Database transaction T2 then m od ifies
or d eletes that d ata elem ent, and p erform s a COMMIT. If T1 w ere to attem p t to re-read the d ata elem ent, it
m ay receive the m od ified valu e or d iscover that the d ata elem ent has been d eleted .
P3 ("Phantom "): Database transaction T1 read s a set of valu es N that satisfy som e <search cond ition>. Database
transaction T2 then execu tes statem ents that generate one or m ore d ata elem ents that sa tisfy the <search
cond ition> u sed by d atabase transaction T1. If d atabase transaction T1 w ere to rep eat the initial read w ith
the sam e <search cond ition>, it obtains a d ifferent set of valu es.
Each d atabase transaction T1 and T2 above m u st be execu ted com p letely or not at all.
The follow ing table d efines fou r isolation levels w ith resp ect to the p henom ena P0, P1, P2, and P3.
Isolation
Level
P0
P1
P2
P3
0
N ot Possible
Possible
Possible
Possible
1
N ot Possible
N ot Possible
Possible
Possible
2
N ot Possible
N ot Possible
N ot Possible
Possible
3
N ot Possible
N ot Possible
N ot Possible
N ot Possible
The follow ing term s are d efined :
T1 = N ew -Ord er transaction
T2 = Paym ent transaction
T3 = Delivery transaction
T4 = Ord er-Statu s transaction
T5 = Stock-Level transaction
Tn = Any arbitrary transaction
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 51 of 130
Althou gh arbitrary, the transaction Tn m ay not d o d irty w rites.
The follow ing table d efines the isolation requ irem ents w hich m u st be m et by the TPC -C transactions.
Req.
#
1.
For transactions
in this set:
these
p henom ena:
m u st N OT be seen
by this transaction:
{Ti, Tj}
P0, P1, P2, P3
Ti
Level 3 isolation betw een N ew Ord er, Paym ent, Delivery, and
Ord er-Statu s transaction s.
P0, P1, P2
Ti
Level 2 isolation for N ew -Ord er,
Paym ent, Delivery, and Ord erStatu s transactions relative to any
arbitrary transaction.
P0, P1
T5
Level 1 isolation for Stock-Level
transaction
relative to TPC-C
transactions and any arbitrary
transaction.
1 ≤i,j ≤4
{Ti, Tn }
2.
1 ≤i ≤4
{Ti, T5}
3.
1 ≤i ≤n
Textu al Descrip tion:
Su fficient cond itions m u st be enabled at either the system or ap p lication level to ensu re the requ ired isolation
d efined above is obtained .
3.4.2
Isolation Tests
For conventional locking schem es, isolation shou ld be tested as d escribed below . System s that im p lem ent other
isolation schem es m ay requ ire d ifferent valid ation techniqu es. It is the resp onsibility of the test sp onsor to d isclose
those techniqu es and the tests for them . If isolation schem es other than conventional locking are u sed , it is
p erm issible to im p lem ent these tests d ifferently p rovid ed fu ll d etails are d isclosed . (Exam p les of d ifferent valid ation
techniqu es are show n in Isolation Test 7, Clau se 3.4.2.7).
3.4.2.1
Isolation Test 1
This test d em onstrates isolation for read -w rite conflicts of Ord er-Statu s and N ew -Ord er transaction s. Perform the
follow ing step s:
1.
Start a N ew -Ord er transaction T1.
2.
Stop transaction T1 im m ed iately p rior to COMMIT.
3.
Start an Ord er-Statu s transaction T2 for the sam e cu stom er u sed in T1. Transaction T2 attem p ts to read the
d ata for the ord er T1 has created .
4.
Verify that transaction T2 w aits.
5.
Allow transaction T1 to com p lete. T2 shou ld now com p lete.
6.
Verify that the resu lts from T2 m atch the d ata entered in T1.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 52 of 130
3.4.2.2
Isolation Test 2
This test d em onstrates isolation for read -w rite conflicts of Ord er-Statu s and N ew -Ord er transaction s w hen the N ew Ord er transaction is ROLLED BACK. Perform the follow ing step s:
1.
Perform an Ord er-Statu s transaction T0 for som e cu stom er. Let T0 com p lete.
2.
Start a N ew -Ord er transaction T1 for the sam e cu stom er u sed in T0.
3.
Stop transaction T1 im m ed iately p rior to COMMIT.
4.
Start an Ord er-Statu s transaction T2 for the sam e cu stom er u sed in T0. Transaction T2 attem p ts to read the
d ata for the ord er T1 has created .
5.
Verify that transaction T2 w aits.
6.
ROLLBACK transaction T1. T2 sh ou ld now com p lete.
7.
Verify that the d ata retu rned from T2 m atch the d ata retu rned by T0.
3.4.2.3
Isolation Test 3
This test d em onstrates isolation for w rite-w rite conflicts of tw o N ew -Ord er transaction s. Perform the follow in g
step s:
1.
Start a N ew -Ord er transaction T1.
2.
Stop transaction T1 im m ed iately p rior to COMMIT.
3.
Start another N ew -Ord er transaction T2 for the sam e cu stom er as T1.
4.
Verify that transaction T2 w aits.
5.
Allow transaction T1 to com p lete. T2 shou ld now com p lete.
6.
Verify that the ord er nu m ber retu rned for T2 is one greater than the ord er nu m ber for T1. Verify that the
valu e of D_N EXT_O_ID reflects the resu lt s of both T1 and T2, i.e., it has been increm ented by tw o and is
one greater than the ord er nu m ber for T2.
3.4.2.4
Isolation Test 4
This test d em onstrates isolation for w rite-w rite conflicts of tw o N ew -Ord er transaction s w hen one transaction is
ROLLED BACK. Perform the follow ing step s:
1.
Start a N ew -Ord er transaction T1 w hich contains an invalid item nu m ber.
2.
Stop transaction T1 im m ed iately p rior to ROLLBACK.
3.
Start another N ew -Ord er transaction T2 for the sam e cu stom er as T1.
4.
Verify that transaction T2 w aits.
5.
Allow transaction T1 to com p lete. T2 shou ld now com p lete.
6.
Verify that the ord er nu m ber retu rned for T2 is one greater than the p reviou s ord er nu m ber. Verify that
the valu e of D_N EXT_O_ID reflects the resu lt of only T2, i.e., it has been increm ented by one and is one
greater than the ord er nu m ber for T2.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 53 of 130
3.4.2.5
Isolation Test 5
This test d em onstrates isolation for w rite-w rite conflicts of Paym ent and Delivery transaction s.
follow ing step s:
Perform the
1.
Start a Delivery transaction T1.
2.
Stop transaction T1 im m ed iately p rior to COMMIT.
3.
Start a Paym ent transaction T2 for the sam e cu stom er as one of the new ord ers being d elivered by T1.
4.
Verify that transaction T2 w aits.
5.
Allow transaction T1 to com p lete. T2 shou ld now com p lete.
6.
Verify that C_BALAN CE reflects the resu lts of both T1 and T2.
Comment: If the Delivery bu siness transaction is execu ted as m u ltip le d atabase transaction s, then the transaction T1,
in bu llet 6 above, can be chosen to be one of these d atabase transactions.
3.4.2.6
Isolation Test 6
This test d em onstrates isolation for w rite-w rite conflicts of Paym ent and Delivery transaction s w hen the Delivery
transaction is ROLLED BACK. Perform the follow ing step s:
1.
Start a Delivery transaction T1.
2.
Stop transaction T1 im m ed iately p rior to COMMIT.
3.
Start a Paym ent transaction T2 for the sam e cu stom er as one of the new ord ers being d elivered by T1.
4.
Verify that transaction T2 w aits.
5.
ROLLBACK transaction T1. T2 shou ld now com p lete.
6.
Verify that C_BALAN CE reflects the resu lts of only transaction T2.
3.4.2.7
Isolation Test 7
This test d em onstrates rep eatable read s for the N ew -Ord er transaction w hile an interactive transaction u pd ates the
p rice of an item . Given tw o rand om item num ber x and y, p erform the follow ing step s:
1.
Start a transaction T1. Qu ery I_PRICE from item s x and y. COMMIT transaction T1.
2.
Start a N ew -Ord er transaction T2 for a grou p of item s inclu d ing item x tw ice and item y.
3.
Stop transaction T2 after qu erying the p r ice of item x a first tim e and im m ed iately before qu erying the
p rices of item y and of item x a second tim e.
4.
Start a transaction T3. Increase the p rice of item s x and y by 10 p ercent.
Case A, if transaction T3 stalls:
5A.
Continu e transaction T2 and verify that the p rice of item s x (the second tim e) and y m atch the valu es read
by transaction T1. COMMIT transaction T2.
6A.
Transaction T3 shou ld now com p lete and be COMMITTED.
7A.
Start a transaction T4. Qu ery I_PRICE from item s x and y. COMMIT transaction T4.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 54 of 130
8A.
Verify that the p rices read by transaction T4 m atch the valu es set by transaction T3.
Case B, if transaction T3 d oes not stall and transaction T2 ROLLS BACK:
5B.
Transaction T3 has com p leted and has been COMMITTED.
6B.
Continu e transaction T2 and verify that it is instru cted to ROLL BACK by the d ata m anager.
7B.
Start a transaction T4. Qu ery I_PRICE from item s x and y. COMMIT transaction T4
8B.
Verify that the p rices read by transaction T4 m atch the valu es set by transaction T3.
Case C, if transaction T3 ROLLS BACK:
5C.
Verify that transaction T3 is instru cted to ROLL BACK by the d ata m anager.
6C.
Continu e transaction T2 and verify that the p rice of item s x (the second tim e) and y m atch the valu es read
by transaction T1. COMMIT transaction T2.
7C.
Start a transaction T4. Qu ery I_PRICE from item s x and y. COMMIT transaction T4
8C.
Verify that the p rices read by transaction T4 m atch the valu es read by transactions T1 and T2.
Case D , if transaction T3 d oes not stall and no transaction is ROLLED BACK:
5D.
Transaction T3 has com p leted and has been COMMITTED.
6D.
Continu e transaction T2 and verify that the p rice of item s x (the second tim e) and y m atch the valu es read
by transaction T1. COMMIT transaction T2.
7D.
Start a transaction T4. Qu ery I_PRICE from item s x and y. COMMIT transaction T4
8D.
Verify that the p rices read by transaction T4 m atch the valu es set by transaction T3.
Comment 1: This test is su ccessfu lly execu ted if either case A, B, C or D of the above step s are follow ed . The test
sp onsor m u st d isclose the case follow ed d u ring the execu tion of this test.
Comment 2: If the im p lem entation u ses rep lication on the ITEM table and all transactions in Isolation Test 7 u se the
sam e cop y of the ITEM table, u p d ates to the ITEM table are not requ ired to be p rop agated to other cop ies of the
ITEM table. This relaxation of ACID p rop erties on a rep licated table is only valid u nd er the above cond itions and in
the context of Isolation Test 7.
Comment 3: Transactions T1, T2, and T4 are not u sed to m easu re throu ghp u t and are only u sed in the context of
Isolation Test 7.
3.4.2.8 Isolation Test 8
This test d em onstrates isolation for Level 3 (p hantom ) p rotection betw een a Delivery and a N ew -Ord er transaction.
Perform the follow ing step s:
1.
Rem ove all row s for a rand om ly selected d istrict and w arehou se from the N EW -ORDER table.
2.
Start a Delivery transaction T1 for the selected w arehou se.
3.
Stop T1 im m ed iately after read ing the N EW-ORDER table for the selected d istrict. N o qu alifying row
shou ld be fou nd .
4.
Start a N ew -Ord er transaction T2 for the sam e w arehou se and d istrict.
Case A, if transaction T2 stalls:
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 55 of 130
5A.
Continu e transaction T1 by rep eating the read of the NEW -ORDER table for the selected d istrict.
6A.
Verify that there is still no q u alifying row fou nd .
7A.
Com p lete and COMMIT transaction T1.
8A.
Transaction T2 shou ld now com p lete.
Case B, if transaction T2 d oes not stall:
5B.
Com p lete and COMMIT transaction T2.
6B.
Continu e transaction T1 by rep eating th e read of the NEW-ORDER table for the selected d istrict.
7B.
Verify that there is still no qu alifying row fou nd .
8B.
Com p lete and COMMIT transaction T1.
Comment: N ote that other cases, besid es A and B, are p ossible. The intent of this test is to d em onstrate that in all
cases w hen T1 rep eats the read of the N EW -ORDER table for the selected d istrict, there is still no qu alifying row
fou nd .
3.4.2.9 Isolation Test 9
This test d em onstrates isolation for Level 3 (p hantom ) p rotection betw een an Ord er -Statu s and a N ew -Ord er
transaction . Perform the follow ing step s:
1.
Start an Ord er-Statu s transaction T1 for a selected cu stom er.
2.
Stop T1 im m ed iately after read ing the ORDER table for the selected cu stom er. The m ost recent ord er for
that cu stom er is fou nd .
3.
Start a N ew -Ord er transaction T2 for the sam e cu stom er.
Case A, if transaction T2 stalls:
5A.
Continu e transaction T1 by rep eating the read of the ORDER table for the selected cu stom er.
6A.
Verify that the ord er fou nd is the sam e as in step 2.
7A.
Com p lete and COMMIT transaction T1.
8A.
Transaction T2 shou ld now com p lete.
Case B, if transaction T2 d oes not stall.
5B.
Com p lete and COMMIT transaction T2.
6B.
Continu e transaction T1 by rep eating the read of the ORDER table for the selected d istrict.
7B.
Verify that the ord er fou nd is the sam e as in step 2.
8B.
Com p lete and COMMIT transaction T1.
Comment: N ote that other cases, besid es A and B, are p ossible. The intent of this test is to d em onstrate that in all
cases w hen T1 rep eats the read of the ORDER table for the selected cu stom er, the ord er fou nd is the sam e as in step
3.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 56 of 130
3.5
D urability Requirements
The tested system m u st gu arantee d u rability: the ability to p res erve the effects of com m itted transactions and ensu re
d atabase consistency after recovery from any one of the failu res listed in Clau se 3.5.3.
Comment 1: N o system p rovid es com p lete d u rability (i.e., d u rability u nd er all p ossible typ es of failu res). The
sp ecific set of single failu res ad d ressed in Clau se 3.5.3 is d eem ed su fficiently significant to ju stify d em onstration of
d u rability across su ch failu res. H ow ever, the lim ited natu re of the tests listed m u st not be interp reted to allow othe r
u nrecoverable single p oints of failu re.
Comment 2: The d u rability requ irem ent d oes not inclu d e the ability to p rotect against the effect of m u ltip le failu res
as d escribed in Clau se 3.5.3 even if those m u ltip le failu res are the resu lt of a single incid ent .
3.5.1
Du rable Med iu m is a Field Rep laceable Unit (FRU) d ata storage m ed iu m that is either:
1.
An inherently non -volatile m ed iu m (e.g., m agnetic d isk, m agnetic tap e, op tical d isk, etc.) or
2.
A volatile m ed iu m that w ill ensu re the transfer of d ata au tom atically, before any d ata is lost, to an
inherently non -volatile m ed iu m after the failu re of external p ow er ind ep end ently of reap p lication of
external p ow er.
A configu red and p riced Uninterru p tible Pow er Su p p ly (UPS) is not consid ered external p ow er.
Comment: A d u rable m ed iu m can fail; this is u su ally p rotected against by rep lication on a second d u rable m ed iu m
(e.g., m irroring) or logging to another d u rable m ed iu m . Mem ory can be consid ered a d u rable m ed iu m if it can
p reserve d ata long enou gh to satisfy the requ irem ent stated in item 2 above, for exam p le, if it is accom p anied by an
Uninterru p tible Pow er Su p p ly, and the contents of m em ory can be transferred to an inherently non -volatile m ed iu m
d u ring the failu re. N ote that no d istinction is m ad e betw een m ain m em ory and m em ory p erform ing sim ilar
p erm anent or tem p orary d ata storage in other p arts of the system (e.g., d isk controller caches).
3.5.2
Committed Property D efinition
A transaction is consid ered com m itted w hen the transaction m anager com p onent of the system h as either w ritten
the log or w ritten the d ata for the com m itted u p d ates associated w ith the transaction to a d u rable m ed iu m .
Comment 1: Transactions can be com m itted w ithou t the u ser su bsequ ently receiving notification of that fact, since
m essage integrity is not requ ired for TPC-C.
Comment 2: Althou gh the ord er of op erations in the transaction p rofiles (Clau se 2) is im m aterial, the actu al
com m u nication of the ou tp u t d ata cannot begin u ntil the com m it op eration has su ccessfu lly com p leted .
3.5.3
List of single failures
The Single Points of Failu re ap p ly to com p onents of th e SUT that contribu te to the d u rability requ irem ent. In
configu rations w here m ore than one instance of an op erating system p erform s an id entica l benchm ark fu nction, the
tests for the failu res listed here m u st be com p leted on at least one su ch instance. In ad d ition, if m u ltip le instances of
an op erating system m anage d ata that is m aintained as a single im age for the benchm ark ap p lication (e.g., a
d atabase clu ster), then the Pow er Failu re test m u st also be p erform ed sim u ltaneou sly on all su ch instances.
Comment 1: An exam p le of m u ltip le system s p erform ing an id entical fu nction is a single d atabase im age on a
clu stered system in TPC-C.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 57 of 130
Comment 2: A single test can ad equ ately satisfy the requ irem ents of m u ltip le single p oints of failu re (e.g., A single
"system crash test" cou ld be u sed for clau ses 3.5.3.2, 3.5.3.3, and 3.5.3.4.)
Comment 3: The term "sim u ltaneou sly" as ap p lied to a p ow er failu re of m u ltip le instances w ithin the SUT is
interp reted to m ean w ithin 3 second s to allow for variances in a m anu al p roced u re that m ay be u sed to accom p lish
the test.
3.5.3.1
Perm anent irrecoverable failu re of any single d u rable m ed iu m d u ring the Measu rem ent Interval
containing TPC-C d atabase tables or recovery log d ata.
Comment: If m ain m em ory is u sed as a d u rable m ed iu m , then it m u st be consid ered as a p otential single p oint of
failu re. Sam p le m echanism s to su rvive single d u rable m ed iu m failu res are d atabase archiving in conju nction w ith a
red o (after im age) log, and m irrored d u rable m ed ia. If m em ory is the d u rable m ed iu m and m irroring is the
m echanism u sed to ensu re d u rability, then the m irrored m em ories m u st be ind epend ently p ow ere d .
3.5.3.2
Instantaneou s interru p tion (system or su bsystem crash/ system hang) in p rocessing w hich cau ses all
or p art of the p rocessing of atom ic transactions to halt.
Comment 1: This m ay im p ly abnorm al system shu td ow n w hich requ ires load ing of a fresh cop y of the op erating
system from the boot d evice. It d oes not necessarily im p ly loss of volatile m em ory . When the recovery m echanism
relies on the p re-failu re contents of volatile m em ory, the m eans u sed to avoid the los s of volatile m em ory (e.g., an
Uninterru p tible Pow er Su p p ly) m u st be inclu d ed in the system cost calcu lation. A sam p le m echanism to su rvive an
instantaneou s interru p tion in p rocessing is an u nd o/ red o log.
Comment 2: In configu rations w here m ore than one instance of an op erating system can particip ate in an atom ic
transaction and are connected via a p hysical m ed iu m other than an integrated bu s (e.g., bu s extend er cable, high
sp eed LAN , or other connection m ethod s betw een the m u ltip le instances of the op erating system that cou ld be
vu lnerable to a loss from p hysical d isru p tion), the instantaneou s interru p tion of this com m u nication is inclu d ed in
this d efinition as an item that need s to be tested . Interru p tion of one instance of red u nd ant connections is requ ired .
Comment 3: It is not the intention of this clau se to requ ire interru p tion of com m u nication to d isk tow ers or a d isk
su bsystem w here red u nd ancy exists. For exam p le, log d isks can be assu m ed to p rovid e red u nd ancy for d ata d isks.
3.5.3.3
Failu re of all or p arts of m em ory (loss of contents).
Comment: This im p lies that all or p art of m em ory has failed . This m ay be cau sed by a loss of external p ow er or the
p erm anent failu re of a m em ory board .
3.5.3.4
Pow er Failu re
Comment 1: Loss of all external p ow er to the SUT for an ind efinite tim e p eriod . This m u st inclu d e at least all
p ortions of the SUT that p articip ate in the d atabase p ortions of transactions.
Comment 2: The p ow er failu re requ irem ent can be satisfied by p ricing su fficient UPS‟ s to gu arantee system
availability of all com p onents that fall u nd er the p ow er failu re requ irem ent for a p eriod of at least 30 m inu tes. Use
of a UPS p rotected configu ration m u st not introd u ce new single p oints of failu re that are not p rotected by other p arts
of the configu ration. The 30-m inu te requ irem ent m ay be p roven either throu gh a m easu rem ent or throu gh a
calcu lation of the 30-m inu te p ow er requ irem ents (in w atts) for the p ortion of the SUT that is p rotected m u ltip lied by
1.4.
Comment 3: The contribu tion of the UPS in satisfying this d u rability requ irem ent d oes not need to be tested .
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 58 of 130
3.5.4
D urability Tests
The intent of these tests is to d em onstrate that all transactions w hose ou tp u t m essages have been received at the
term inal or RTE have in fact been com m itted in sp ite of any single failu re from the list in Clau se 3.5.3 and that all
consistency cond itions are still m et after the d atabase is recov ered .
It is requ ired that the system crash test(s) and the loss of m em ory test(s) d escribed in Clau ses 3.5.3.2 and 3.5.3.3 be
p erform ed u nd er fu ll term inal load and a fu lly scaled d atabase. The tp m C of the test ru n(s) for Clau ses 3.5.3.2 and
3.5.3.3 m u st be at least 90% of the tp m C rep orted for the benchm ark.
The d u rable m ed ia failu re test(s) d escribed in Clau se 3.5.3.1 m ay be p erform ed on a su bset of the SUT configu ration
and d atabase. The tp m C of the test ru n for Clau se 3.5.3.1 m u st be at least 10% of the tom C rep orted for the
benchm ark.
For the SUT su bset, all m u ltip le hard w are com p onents, su ch as p rocessors and d isk/ controllers in the fu ll SUT
configu ration, m u st be rep resented by the greater of 10% of the configu ration or tw o of each of the m u ltip le
hard w are com p onents. The d atabase m u st be scaled to at least 10% of the fu lly scaled d atabase, w ith a m inim u m of
tw o w arehou ses. An excep tion to the configu ration requ irem ents stated above m ay be allow ed by the TPC Au d itor
in ord er to red u ce benchm ark com p lexity. Any su ch excep tion m u st be d ocu m ented in the attestation letter from the
Au d itor. Furtherm ore, the stand ard d riving m echanism m u st be u sed in this test. The test sp on sor m u st state that to
the best of their know led ge, a fu lly scaled test w ou ld also p ass all d u rability tests.
For each of the failu re typ es d efined in Clau se 3.5.3, p erform the follow ing step s:
1.
Com p u te the su m of D_N EXT_O_ID for all row s in the DISTRICT table to d eterm ine the cu rrent cou nt of
the total nu m ber of ord ers (cou nt1).
2.
Start su bm itting TPC-C transactions. The transaction rate m u st be that d escribed above and m eet all other
requ irem ents of a rep orted m easu rem ent interval (see Clau se 5.5), exclu d ing the requ irem ent that the
interval contain at least fou r checkp oint (see Clau se 5.5.2.2). The SUT m u st be run at this rate for at least 5
m inu tes. On the Driver System , record com m itted and rolled back N ew -Ord er transaction s in a "su ccess"
file.
3.
Cau se the failu re selected from the list in Clau se 3.5.3.
4.
Restart the system u nd er test u sing norm al recovery p roced u res.
5.
Com p are the contents of the "su ccess" file and the ORDER table to verify that every record in the "su ccess"
file for a com m itted N ew -Ord er transaction has a corresp ond ing record in the ORDER table and that no
entries exist for rolled back transactions.
Rep eat step 1 to d eterm ine the total nu m ber of ord ers (cou nt2). Verify that cou nt2 -cou nt1 is greater or
equ al to the nu m ber of record s in the "su ccess" file for com m itted N ew -Ord er transaction s. If there is an
inequ ality, the ORDER table m u st contain ad d itional record s and the d ifference m u st be less than or equ al
to the nu m ber of term inals sim u lated .
Comment: This d ifference shou ld be d u e only to transactions w hich w ere com m itted on the system u nd er
test, bu t for w hich the ou tp u t d ata w as not d isp layed on the inp u t/ ou tp u t screen before the failu re.
6.
Verify Consistency Cond ition 3 as sp ecified in Clau se 3.3.2.3.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 59 of 130
3.5.5
3.5.5.1
p rop erty.
Additional Requirements
The recovery m echanism cannot u se the contents of the H ISTORY table to su p p ort the d u rability
3.5.5.2
Roll-forw ard recovery from an archive d atabase cop y (e.g., a cop y taken p rior to the ru n) u sing red o
log d ata is not accep table as the recovery m echanism in the case of failu res listed in Clau se 3.5.3.2 and 3.5.3.3. N ote
that "checkp oints", "control p oints", "consistency p oints", etc. of the d atabase taken d u ring a ru n are not con sid ered
to be archives.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 60 of 130
Clause 4: SCALIN G and D ATABASE POPULATION
4.1
General Scaling Rules
The throu ghp u t of the TPC-C benchm ark is d riven by the activity of the term inals connected to each w arehou se. To
increase the throu ghp u t, m ore w arehou ses and their associated term inals m u st be configu red . Each w arehou se
requ ires a nu m ber of row s to p op u late the d atabase along w ith som e storage sp ace to m aintain the d ata generated
d u ring a d efined p eriod of activity called 60-day period. These requ irem ents d efine how storage sp ace and d atabase
p op u lation scale w ith throu ghp u t.
4.1.1
The intent of the scaling requ irem ents is to m aintain the ratio betw een the transaction load p resented
to the system u nd er test, the card inality of the tables accessed by the transactions, the requ ired sp ace for storage, and
the nu m ber of term inals generating the transaction load .
4.1.2
Shou ld any scaling valu e in Clau se 4.2 be exceed ed , the others m u st be increased p rop ortionally to
m aintain the sam e ratios am ong them as in Clau se 4.2.
4.1.3
The rep orted throu ghp u t m ay not exceed the m axim u m allow ed by the scaling requ irem ents in Clau se
4.2 and the pacing requ irem ents in Clau se 5.2. While the rep orted throu ghp u t m ay fall short of the m axim u m
allow ed by the configu red system , the p rice/ p erform ance com p u tation (see Clau se 7.1) m u st rep ort the p rice for the
system as actu ally configu red . To p revent over -scaling of system s, the rep orted throu ghp u t cannot fall short of 9
tp m C p er configu red w arehou se.
Comment: The m axim u m throu ghp u t is achieved w ith infinitely fast transactions resu lting in a nu ll resp onse tim e
and m inim um requ ired w ait tim es. The intent of this clau se is to p revent rep orting a throu ghp u t that exceed s this
m axim u m , w hich is com p u ted to be 12.86 tp m C p er w arehou se. The above 9 tp m C rep resents 70% of the com p u ted
m axim u m throu ghp u t.
4.2
Scaling Requirements
4.2.1
The WAREH OUSE table is u sed as the base u nit of scaling. The card inality of all other tables (excep t
for ITEM) is a fu nction of the nu m ber of configu red w arehou ses (i.e., card inality of the WAREH OUSE table). This
nu m ber, in tu rn, d eterm ines the load ap p lied to the system u nd er test w hich resu lts in a rep orted throu gh p u t (see
Clau se 5.4).
Comment 1: The card inality of the H ISTORY, N EW-ORDER, ORDER, and ORDER-LIN E tables w ill natu rally vary
as a resu lt of rep eated test execu tions. The initial d atabase p op u lation and the transaction p rofiles are d esigned to
m inim ize the im p act of this variation on p erform ance and m aintain rep eatability betw een su bsequ ent test resu lts.
Comment 2: The card inality of the ITEM table is constant regard less of the nu m ber of configu red w arehou ses, as all
w arehou ses m aintain stocks for the sam e catalog of item s.
4.2.2
Configuration
The follow ing scaling requ irem ents rep resent the initial configu ration for the test d escribed in Clau se 5:
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 61 of 130
1.
For each active w arehou se in the d atabase, the SUT m u st accep t requ ests for transactions from a
p op u lation of 10 term inals.
2.
For each table that com p oses the d atabase, the card inality of the initial p op u lation p er w arehou se is
sp ecified as follow s:
Table N am e
WAREH OUSE
DISTRICT
CUSTOMER
H ISTORY 1
ORDER 4
N EW-ORDER 4
ORDER-LIN E 4
STOCK
ITEM 2
Card inality
(in row s)
1
10
30k
30k
30k
9k
300k
100k
100k
Typ ical 3 Row
Length (in bytes)
89
95
655
46
24
8
54
306
82
Typ ical 3 Table
Size (in 1,000 bytes)
0.089
0.950
19,650
1,380
720
72
16,200
30,600
8,200
1
Sm all variations: su bject to test execu tion as row s m ay be inserted and d eleted by transaction ac tivity
from test execu tions.
2 Fixed card inality: d oes not scale w ith nu m ber of w arehou ses.
3
Typ ical lengths and sizes given here are exam p les, not requ irem ents, of w hat cou ld resu lt from an
im p lem entation (sizes d o not inclu d e storage/ access overhead s).
4
One p ercent (1%) variation in row card inality is allow ed to accou nt for the rand om variation
encou ntered d u ring the initial d ata load ing of the d atabase.
N ote: The sym bol "k" u sed in the card inality colu m n m eans one thou sand
3.
Storage m u st be p riced for su fficient sp ace to store and m aintain the d ata generated d u ring a p eriod of 60
d ays of activity w ith an average of 8 hou rs p er d ay at the rep orted th rou ghp u t called the 60-day period).
This sp ace m u st be com p u ted accord ing to Clau se 4.2.3 and m u st be u sable by the d ata m anager to store
and m aintain the row s that w ou ld be ad d ed to the HISTORY, ORDER, and ORDER-LIN E tables d u ring
the 60-d ay p eriod .
4.
The increm ent (granu larity) for scaling the d atabase and the term inal p op u lation is one w arehou se,
com p rised of one WAREH OUSE row , 10 DISTRICT row s, their associated CUSTOMER, H ISTORY,
ORDER, N EW-ORDER, and ORDER-LIN E row s, 100,000 STOCK row s, 10 term inals, and p riced storage
for the 60-d ay p eriod .
Comment: Over-scaling the d atabase, i.e., configu ring a larger nu m ber of w arehou ses and associated tables (Wc )
than w hat is actu ally accessed d u ring the m easu rem ent (Wa) is p erm itted , p rovid ed the follow ing cond itions are
m et:
Let,
Wc = nu m ber of w arehou ses configu red at d atabase generation,
Wa = nu m ber of w arehou ses accessed d u ring the m easu rem ent (active w arehou ses),
Wi = nu m ber of w arehou ses not accessed d u ring the m easu rem ent (inactive w arehou ses).
 It can be d em onstrated that inactive w arehou ses are not a ccessed d u ring the m easu rem ent. This fact m u st be
d em onstrated in one of the follow ing w ays:
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 62 of 130
1.
row s in the WAREH OUSE table that p ertain to the inactive w arehou ses (Wi) m u st be d eleted p rior to the
m easu rem ent,
2.
show that the su m of D_N EXT_O_ID for each of the inactive w arehou ses d oes not change d u ring the
m easu rem ent, and that W_YTD for each of the inactive w arehou ses d oes not change d u ring the m easu rem ent.
• the rep orted throu ghp u t cannot fall short of 9 tp m C p er configu red w arehou se (Wc -see Clau se 4.1.3),
• the 60-d ay sp ace com p u tations m u st be com p u ted based on Wc, the num ber of w arehou ses configu red at
d atabase generation.
4.2.3
60-D ay Space Computation
The storage sp ace requ ired for the 60-d ay p eriod m u st be d eterm ined as follow s:
1.
The test d atabase m u st be bu ilt inclu d ing the initial d atabase p op u lation (see Clau se 4.3) and all ind ices
p resent d u ring the test.
2.
The test d atabase m u st be bu ilt to su stain th e rep orted throu ghp u t d u ring an eight hou r p eriod . This
exclu d es p erform ing on the d atabase any op eration that d oes not occu r d u ring the m easu rem ent interval
(see Clau se 5.5).
3.
The total storage sp ace allocated for the test d atabase m u st be d ecom p osed into the follow ing:
• Free-Space: any sp ace allocated to the test d atabase and w hich is available for fu tu re u se. It is
com p rised of all d atabase storage sp ace not u sed to store a d atabase entity (e.g., a row , an ind ex, a
m etad atu m ) or not u sed as form atting overhead by the d ata m anager.
• D ynamic-Space: any sp ace u sed to store existing row s from th e d ynam ic tables (i.e., the H ISTORY,
ORDER, and ORDER-LIN E tables). It is com p rised of all d atabase storage sp ace u sed to store row s and
row storage overhead for the d ynam ic tables. It inclu d es any d ata that is ad d ed to the d atabase as a
resu lt of inserting a new row ind ep end ently of all ind ices. It d oes not inclu d e ind ex d ata or other
overhead s su ch as ind ex overhead , page overhead , block overhead , and table overhead .
• Static-Space: any sp ace u sed to store static inform ation and ind ices. It is com p rised of all sp ace
allocated to the test d atabase and w hich d oes not qu alify as either Free -Sp ace or Dynam ic-Sp ace.
4.
Given that the system m u st be configu red to su stain the rep orted throu ghp u t d u ring an eight hou r p eriod ,
the d atabase m u st allow the d ynam ic tables to grow accord ingly for at least eight hou rs w ithou t im p acting
p erform ance. Free-Space u sed to allow grow th of the d ynam ic tables for an eight hou r d ay at the rep orted
throu ghp u t is called the D aily-Grow th. Given W, the nu m ber of configu red w arehou ses on the test
system , the Daily-Grow th m u st be com p u ted as:
Daily-Grow th = (d ynam ic-Sp ace / (W * 62.5)) * tp m C
N ote: In the form u la above, 62.5 is u sed as a norm alizing factor since the initial d atabase p op u lation for
each w arehou se hold s the Dynam ic-Sp ace requ ired for an eight hou r d ay of activity at 62.5 tp m C.
5.
Any Free-Sp ace beyond 150% of the Daily-Grow th is called D aily-Spread, and m u st be ad d ed to the
Dynam ic-Sp ace w hen com p u ting the storage requ irem ent for the 60-d ay p eriod . The Daily-Sp read m u st be
com p u ted as:
Daily-Sp read = Free-Sp ace - 1.5 * Daily-Grow th
If the com p u ted Daily-Sp read is negative, then a nu ll valu e m u st be u sed for Daily -Sp read .
6.
The 60-D ay-Space m u st be com p u ted as:
60-Day-Sp ace = Static-Sp ace + 60 * (Daily-Grow th + Daily-Sp read )
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 63 of 130
7.
4.3
The Dynam ic-Sp ace p resent in the test d atabase is consid ered as p art of the 60-Day-Sp ace.
D atabase Population
4.3.1
The test d escribed in Clau se 5 requ ires that the p rop erly scaled p op u lation be p resent in the test
d atabase. Each table m u st contain the num ber of row s d efined in Clau se 4.2.2 p rior to test execu tion (e.g., the N ew Ord er table m u st contain 2,000 row s p er w arehou se).
4.3.2
D efinition of Terms
4.3.2.1
valu es.
The term random m eans ind ep end ently selected and u niform ly d istribu ted over the sp ecified range of
Comment: For the p u rp ose of p op u lating the initial d atabase only, rand om nu m bers can be generated by selecting
entries in sequ ence from a set of at least 10,000 p regenerated rand om nu m bers. This techniqu e cannot be u sed for the
field O_OL_CN T.
4.3.2.2
The notation random a-string [x .. y ] (resp ectively, n-string [x .. y ]) rep resents a string of rand om
alp hanu m eric (resp ectively, nu m eric) cha racters of a rand om length of m inim u m x, m axim u m y, and m ean (y+x)/ 2.
Comment: The character set u sed m u st be able to rep resent a m inim u m of 128 d ifferent characters. The character set
u sed m u st inclu d e at least 26 low er case letters, 26 u p p er case letter s, and the d igits „ 0‟ to „ 9‟ .
4.3.2.3
The cu stom er last nam e (C_LAST) m u st be generated by the concatenation of three variable length
syllables selected from the follow ing list:
0
1
2
3
4
5
6
7
8
9
BAR
OUGH T
ABLE
PRI
PRES
ESE
AN TI
CALLY
ATION
EIN G
Given a nu m ber betw een 0 and 999, each of the three syllables is d eterm ined by the corresp ond ing d igit in the three
d igit rep resentation of the nu m ber. For exam p le, the nu m ber 371 generates the nam e PRICALLYOUGH T, and the
nu m ber 40 generates the nam e BARPRESBAR.
4.3.2.4
The notation unique w ithin [x] rep resents any one valu e w ithin a set of x contigu ou s valu es, u niqu e
w ithin the grou p of row s being p op u lated . When several grou p s of row s of the sam e typ e are p op u lat ed (e.g., there
is one grou p of cu stom er typ e row s for each d istrict typ e row ), each grou p m u st u se the sam e set of x contigu ou s
valu es.
4.3.2.5
The notation random w ithin [x .. y ] rep resents a rand om valu e ind ep end ently selected and u niform ly
d istribu ted betw een x and y, inclu sively, w ith a m ean of (x+y)/ 2, and w ith the sam e nu m ber of d igits of p recision as
show n. For exam p le, [0.01 .. 100.00] has 10,000 u niqu e valu es, w hereas [1 ..100] has only 100 u niqu e va lu es.
4.3.2.6
The notation random permutation of [x .. y ] rep resents a sequ ence of nu m bers from x to y arranged
into a rand om ord er. This is com m only know n as a p erm u tation (or selection) w ithou t rep lacem ent.
4.3.2.7
The w arehou se zip cod e (W_ZIP), the d istrict zip cod e (D_ZIP) and the cu stom er zip cod e (C_ZIP) m u st be
generated by the concatenation of:
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 64 of 130
1. A rand om n-string of 4 num bers, and
2. The constant string '11111'.
Given a rand om n-string betw een 0 and 9999, the zip cod es are d eterm ined by concatenating the n -string and the
constant '11111'. This w ill create 10,000 u niqu e zip cod es. For exam p le, the n -string 0503 concatenated w ith 11111,
w ill m ake the zip cod e 050311111.
Comment: With 30,000 custom ers p er w arehou se and 10,000 zip cod es available, there w ill be an average of 3
cu stom ers p er w arehou se w ith the sam e zip cod e.
4.3.3
4.3.3.1
Table Population Requirements
The initial d atabase p op u lation m u st be com p rised of:
• 100,000 row s in the ITEM table w ith:
I_ID u niqu e w ithin [100,000]
I_IM_ID rand om w ithin [1 .. 10,000]
I_N AME rand om a-string [14 .. 24]
I_PRICE rand om w ithin [1.00 .. 100.00]
I_DATA rand om a-string [26 .. 50]. For 10% of the row s, selected at rand om , the string "ORIGIN AL" m u st
be held by 8 consecu tive characters starting at a rand om p osition w ithin I_DATA
• 1 row in the WAREH OUSE table for each configu red w arehou se w ith:
W_ID u niqu e w ithin [number_of_configured_warehouses]
W_N AME rand om a-string [6 .. 10]
W_STREET_1 rand om a-string [10 .. 20]
W_STREET_2 rand om a-string [10 .. 20]
W_CITY rand om a-string [10 .. 20]
W_STATE rand om a-string of 2 letters
W_ZIP generated accord ing to Clau se 4.3.2.7
W_TAX rand om w ithin [0.0000 .. 0.2000]
W_YTD = 300,000.00
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 65 of 130
For each row in the WAREH OUSE table:
o 100,000 row s in the STOCK table w ith:
S_I_ID u niqu e w ithin [100,000]
S_W_ID = W_ID
S_QUAN TITY rand om w ithin [10 .. 100]
S_DIST_01 rand om a-string of 24 letters
S_DIST_02 rand om a-string of 24 letters
S_DIST_03 rand om a-string of 24 letters
S_DIST_04 rand om a-string of 24 letters
S_DIST_05 rand om a-string of 24 letters
S_DIST_06 rand om a-string of 24 letters
S_DIST_07 rand om a-string of 24 letters
S_DIST_08 rand om a-string of 24 letters
S_DIST_09 rand om a-string of 24 letters
S_DIST_10 rand om a-string of 24 letters
S_YTD = 0
S_ORDER_CN T = 0
S_REMOTE_CN T = 0
S_DATA rand om a-string [26 .. 50]. For 10% of the row s, selected at rand om , the string
"ORIGIN AL" m u st be held by 8 consecu tive characters starting at a rand om p osition w ithin
S_DATA
o 10 row s in th e DISTRICT table w ith:
D_ID u niqu e w ithin [10]
D_W_ID = W_ID
D_N AME rand om a-string [6 .. 10]
D_STREET_1 rand om a-string [10 .. 20]
D_STREET_2 rand om a-string [10 .. 20]
D_CITY rand om a-string [10 .. 20]
D_STATE rand om a-string of 2 letters
D_ZIP generated accord ing to Clau se 4.3.2.7
D_TAX rand om w ithin [0.0000 .. 0.2000]
D_YTD = 30,000.00
D_N EXT_O_ID = 3,001
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 66 of 130
For each row in the DISTRICT table:
* 3,000 row s in the CUSTOMER table w ith:
C_ID u niqu e w ithin [3,000]
C_D_ID = D_ID
C_W_ID = D_W_ID
C_LAST generated accord ing to Clau se 4.3.2.3, itera ting throu gh the range of [0 .. 999] for the first
1,000 cu stom ers, and generating a non -u niform rand om nu m ber u sing the fu nction
N URand (255,0,999) for each of the rem aining 2,000 custom ers. The ru n -tim e constant C (see Clau se
2.1.6) u sed for the d atabase p op u lation m u st be rand om ly chosen ind ep end ently from the test
ru n(s).
C_MIDDLE = "OE"
C_FIRST rand om a-string [8 .. 16]
C_STREET_1 rand om a-string [10 .. 20]
C_STREET_2 rand om a-string [10 .. 20]
C_CITY rand om a-string [10 .. 20]
C_STATE rand om a-string of 2 letters
C_ZIP generated accord ing to Clau se 4.3.2.7
C_PH ON E rand om n-string of 16 nu m bers
C_SIN CE d ate/ tim e given by the op erating system w hen the CUSTOMER table w as p op u lated .
C_CREDIT = "GC". For 10% of the row s, selected at rand om , C_CREDIT = "BC"
C_CREDIT_LIM = 50,000.00
C_DISCOUN T rand om w ithin [0.0000 .. 0.5000]
C_BALAN CE = -10.00
C_YTD_PAYMEN T = 10.00
C_PAYMEN T_CN T = 1
C_DELIVERY_CN T = 0
C_DATA rand om a-string [300 .. 500]
For each row in the CUSTOMER table:
- 1 row in the H ISTORY table w ith:
H _C_ID = C_ID
H _C_D_ID = H _D_ID = D_ID
H _C_W_ID = H _W_ID = W_ID
H _DATE cu rrent d ate and tim e
H _AMOUN T = 10.00
H _DATA rand om a-string [12 .. 24]
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 67 of 130
* 3,000 row s in the ORDER table w ith:
O_ID u niqu e w ithin [3,000]
O_C_ID selected sequ entially from a rand om p erm u tation of [1 .. 3,000]
O_D_ID = D_ID
O_W_ID = W_ID
O_EN TRY_D cu rrent d ate/ tim e given by the op erating system
O_CARRIER_ID rand om w ithin [1 .. 10] if O_ID < 2,101, nu ll otherw ise
O_OL_CN T rand om w ithin [5 .. 15]
O_ALL_LOCAL = 1
For each row in the ORDER table:
- A nu m ber of row s in the ORDER-LIN E table equ al to O_OL_CN T, generated accord ing to the ru les
for inp u t d ata generation of the N ew -Ord er transaction (see Clau se 2.4.1) w ith:
OL_O_ID = O_ID
OL_D_ID = D_ID
OL_W_ID = W_ID
OL_N UMBER u niqu e w ithin [O_OL_CN T]
OL_I_ID rand om w ithin [1 .. 100,000]
OL_SUPPLY_W_ID = W_ID
OL_DELIVERY_D = O_ENTRY_D if OL_O_ID < 2,101, nu ll otherw ise
OL_QUAN TITY = 5
OL_AMOUN T = 0.00 if OL_O_ID < 2,101, rand om w ithin [0.01 .. 9,999.99] otherwise
OL_DIST_IN FO rand om a-string of 24 letters
* 900 row s in the N EW-ORDER table corresp ond ing to the last 900 row s in the ORDER table for that
d istrict (i.e., w ith N O_O_ID betw een 2,101 and 3,000), w ith:
N O_O_ID = O_ID
N O_D_ID = D_ID
N O_W_ID = W_ID
Comment: Five p ercent (5%) variation from the target card inality of S_DATA w ith ” ORGIN AL” , I_DATA w ith
“ ORIGIN AL” , and C_CREDIT w ith “ BC” is allow ed to accou nt for the rand om variation encou ntered d u ring the
initial d ata load ing of the d atabase.
4.3.3.2
The im p lem entation m ay not take ad vantage of the fact that som e field s are initially p op u lated w ith a
fixed valu e. For exam p le, storage sp ace cannot be saved by d efining a d efau lt valu e for the field C_CREDIT_LIM
and storing this valu e only once in the d atabase.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 68 of 130
Clause 5: PERFORMAN CE METRICS and RESPON SE TIME
5.1
D efinition of Terms
5.1.1
The term measurement interval refers to a stead y state p eriod d u ring the execu tion of the benchm ark
for w hich the test sp onsor is rep orting a throu ghp u t rating (see Clau se 5.5 for d etailed requ irem ents).
5.1.2
The term completed transactions refers to any bu siness transaction (see Clau se 2.1.3) that has been
su ccessfu lly com m itted at the SUT and w hose ou tp u t d ata has been d isp layed by the Rem ote Term inal Em u lator (in
case of a N ew -Ord er, Paym ent, Ord er-Statu s, or Stock-Level transaction ) or for w hich a com p lete entry has been
w ritten into a resu lt file (in case of a Delivery transaction ). N ew -Ord er transaction s that are rolled back, as requ ired
by Clau se 2.4.1.4, are consid ered as com p leted transactions.
5.2
Pacing of Transactions by Emulated Users
5.2.1
The figu re below illu strates the cycle execu ted by each em u lated u ser (see Clau se 5.2.2). The active
p ortion of the screen is rep resented w ith bold face text:
Prev ious
Screen
menu
1 - Select transaction ty pe
3 - Measure Menu RT
2 - Display Screen
Input
Screen
menu
4 - Wait (Key ing Time)
6 - Measure Txn. RT
Output
Screen
menu
5 - Display Data
7 - Wait (Think Time)
5.2.2
follow s:
1.
Each em u lated u ser execu tes a cycle com p rised of screens, w ait tim es, and resp onse tim es (RTs) as
Selects a transaction typ e from the m enu accord ing to a w eighted d istribu tion (see Clau se 5.2.3).
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 69 of 130
2.
Waits for the Inp u t/ Ou tp u t Screen to be d isp layed .
3.
Measu res the Menu RT (see Clau se 5.3.3).
4.
Enters the requ ired num ber of inp u t field s (see Clau se 2) over the d efined m inim u m Keying Tim e (see
Clau se 5.2.5.2).
5.
Waits for the requ ired nu m ber of ou tp u t field s (see Clau se 2) to be d isp layed on the Inp u t/ Ou tp u t Screen.
6.
Measu res the Transaction RT (see Clau se 5.3.4).
7.
Waits for the d efined m inim u m Think Tim e (see Clau se 5.2.5.4) w hile the inp ut/ ou tp u t screen rem ains
d isp layed .
At the end of the Think Tim e (Step 7) the em u lated u ser loop s back to select a transaction typ e from the m enu (Step
1).
Comment: N o action is requ ired on the p art of the SUT to cycle from Step 7 back to Step 1.
5.2.3
Each transaction typ e (i.e., bu siness transaction ) is available to each term inal throu gh the Menu . Over
the m easu rem ent interval, the term inal p op u lation m u st m aintain a m inim u m p ercentage of m ix for each transaction
typ e as follow s:
Transaction Typ e
N ew -Ord er 1
Paym ent
Ord er-Statu s
Delivery
Stock-Level
Minim u m % of m ix
n/ a
43.0
4.0
4.0
4.0
1 There is no m inim u m for the N ew -Ord er transaction as its m easu red rate is the rep orted throu ghp u t .
Comment 1: The intent of the m inim um p ercentage of m ix for each transaction typ e is to execu te ap p roxim ately one
Paym ent transaction for each N ew -Ord er transaction and ap p roxim ately one Ord er-Statu s transaction , one Delivery
transaction , and one Stock-Level transaction for every 10 N ew -Ord er transactions. This m ix resu lts in the com p lete
bu siness p rocessing of each ord er.
Comment 2: The total nu m ber of transactions, from w hich the m inim u m p ercentages of m ix are d erived , m ay be
calcu lated in either of tw o w ays:

Based on all transactions that w ere selected from the Menu and com p leted (see Clau se 5.1.2) w ithin the
m easu rem ent interval.

Based on all tran sactions w hose Transaction RT (see Clau se 5.3.4) w as com p letely m easu red at the RTE
d u ring the m easu rem ent interval.
Comment 3: As an ease of benchm arking issu e, the ap p roach in Clau se 5.4.2 m ay be u sed to com p u te the transaction
m ix p ercentage and throu gh p u t d ata.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 70 of 130
5.2.4
Regulation of Transaction Mix
Transaction typ es m u st be selected u niform ly at rand om w hile m aintaining the requ ired m inim u m p ercentage of
m ix for each transaction typ e over the m easu rem ent interval. This m u st be d one u sing one of the techniqu es
d escribed in Clau ses 5.2.4.1 and 5.2.4.2.
5.2.4.1
A w eight is associated to each transaction typ e on the m enu . The requ ired m ix is achieved by selecting
each new transaction u niform ly at rand om from a w eighted d istribu tion. The follow ing requ irem ents m u st be
satisfied w hen u sing this techniqu e:
1.
The actu al w eights are chosen by the test sp onsor and m u st resu lt in m eeting the requ ired m inim u m
p ercentages of m ix in Clau se 5.2.3.
2.
For the p u rp ose of achieving the requ ired transaction m ix, the RTE can d ynam ically ad ju st the w eigh t
associated to each transaction typ e d u ring the m easu rem ent interval. These ad ju stm ents m u st be lim ited
so as to keep the w eights w ithin 5% on either sid e of their resp ective initial valu e.
5.2.4.2
One or m ore card s in a d eck are associated to each transaction typ e on the Menu . The requ ired m ix is
achieved by selecting each new transaction u niform ly at rand om from a d eck w hose content gu arantees the requ ired
transaction m ix. The follow ing requ irem ents m u st be satisfied w hen u sing this techniqu e:
1.
Any nu m ber of term inals can share the sam e d eck (inclu d ing bu t not lim ited to one d eck p er term inal or
one d eck for all term inals).
2.
A d eck m u st be com p rised of one or m ore sets of 23 card s (i.e., 10 N ew -Ord er card s, 10 Paym ent card s,
and one card each for Ord er-Statu s, Delivery, and Stock-level). The m inim u m size of a d eck is one set p er
term inal sharing this d eck. If m ore than one d eck is u sed , then all d ecks m u st be of equ al sizes.
Comment: Generating the m axim u m p ercentage of N ew -Ord er transaction s w hile achieving the requ ired
m ix can be d one for exam p le by sharing a d eck of 230 card s betw een 10 term inals.
3.
Each p ass throu gh a d eck m u st be m ad e in a d ifferent u niform ly rand om ord er. If a d eck is accessed
sequ entially, it m u st be rand om ly shu ffled each tim e it is exhau sted . If a d eck is accessed at rand om , card s
that are selected cannot be p laced back in the d eck u ntil it is exhau sted .
Comment: All term inals m u st select transactions u sing the sam e techniqu e. Gaining a p erform ance or a
p rice/ p erform ance ad vantage by d riving one or m ore term inals d ifferently than the rest of the term inal p op u lation
is not allow ed .
5.2.5
Wait Times and Response Time Constraints
5.2.5.1
The Menu step is transaction ind ep end ent. At least 90% of all Menu selections m u st have a Menu RT
(see Clau se 5.3.3) of less than 2 second s.
5.2.5.2
For each transaction typ e, the Keying Tim e is constant and m u st be a m inim u m of 18 second s for N ew Ord er, 3 second s for Paym ent, and 2 second s each for Ord er-Statu s, Delivery, and Stock-Level.
5.2.5.3
At least 90% of all transactions of each typ e m u st have a Transaction RT (see Clau se 5.3.4) of less than
5 second s each for N ew -Ord er, Paym ent, Ord er-Statu s, and Delivery, and 20 second s for Stock-Level.
Comment: The total nu m ber of transactions, from w hich the Transaction RT of N ew -Ord er is com p u ted , inclu d es
N ew -Ord er transaction s that rollback as requ ired by Clau se 2.4.1.4.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 71 of 130
5.2.5.4
For each transaction typ e, think tim e is taken ind ep end ently from a negative exp onential d istribu tion.
Think tim e, Tt , is com p u ted from the follow ing equ ation:
Tt = -log(r) * 
w here: log = natu ral log (base e)
Tt = think tim e
r = rand om nu m ber uniform ly d istribu ted betw een 0 and 1
 = m ean think tim e
Each d istribu tion m ay be tru ncated at 10 tim es its m ean valu e
5.2.5.5
The beginning of all w ait tim es (Keying Tim es and Think Tim es) are to be taken after the last character
of ou tp u t has been d isp layed (see Clau se 2.2.2) by the em u lated term inal.
5.2.5.6
The 90th p ercentile resp onse tim e for the N ew -Ord er, Paym ent, Ord er-Statu s, Stock-Level and the
interactive p ortion of the Delivery transactions m u st be greater than or equ al to the average resp onse tim e of that
transaction. If the 90th and the average resp onse tim es are d ifferent by less that 100m s (.1 second s), then they are
consid ered equ al. This requ irem ent is for the term inal resp onse tim es only and d oes not ap p ly to the d eferred
p ortion of the Delivery transaction or to the m enu step .
5.2.5.7
The follow ing table su m m arizes the tran saction m ix, wait tim es, and resp onse tim e constraints:
Transaction
Typ e
Minim u m
% of m ix
N ew -Ord er
Paym ent
Ord er-Statu s
Delivery 1
Stock-Level
n/ a
43.0
4.0
4.0
4.0
Minim u m
Keying Tim e
18 sec.
3 sec.
2 sec.
2 sec.
2 sec.
90th Percentile
Resp onse Tim e
Constraint
Minim u m Mean
of Think Tim e
Distribu tion
5 sec.
5 sec.
5 sec.
5 sec.
20 sec.
12 sec.
12 sec.
10 sec.
5 sec.
5 sec.
1 The resp onse tim e is for the term inal resp onse (acknow led ging that the transaction has been qu eu ed ), not
for the execu tion of the transaction itself. At least 90% of the transactions m u st com p lete w ithin 80 second s
of their being qu eu ed (see Clau se 2.7.2.2).
Comment 1: The resp onse tim e constraints are set su ch that the throu ghp u t of the system is exp ected to be
constrained by the resp onse tim e requ irem ent for the N ew -Ord er transaction . Resp onse tim e constraints for other
transactions are relaxed for that p u rp ose.
Comment 2: The keying tim es for the transactions are chosen to be ap p roxim ately p rop ortional to the nu m ber of
characters inp u t, and the think tim es are chosen to be ap p roxim ately p rop ortional to the nu m ber of charact ers
ou tp u t.
5.2.5.8
For each transaction typ e, all configu red term inals of the tested system s m u st u se the sam e target
Keying Tim e and the sam e target m ean of Think Tim e. These tim es m u st com p ly w ith the requ irem ents su m m arized
in Clau se 5.2.5.7.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 72 of 130
5.3
Response Time D efinition
5.3.1
Each com p leted transaction su bm itted to the SUT m u st be ind ivid u ally tim ed .
5.3.2
Resp onse Tim es m u st be m easu red at the RTE. A Response Time (or RT) is d efined by:
RT = T2 - T1
w here:
T1 and T2 are m easu red at the RTE and d efined as:
T1 = tim estam p taken before the last character of inp u t d ata is entered by the em u lated u s er.
T2 = tim estam p taken after the last character of ou tp u t is received by the em u lated term inal.
The resolu tion of the tim estam p s m u st be at least 0.1 second s.
Comment: The intent of the benchm ark is to m easu re resp onse tim e as exp erienced by the em u lated u ser.
5.3.3
The Menu Resp onse Tim e (Menu RT) is the tim e betw een the tim estam p taken before the last
character of the Menu selection has been entered and the tim estam p taken after th e last character of the
Inp u t/ Ou tp u t Screen has been received (inclu d ing clearing all inp u t and ou tp u t field s and d isp laying fixed field s,
see Clau se 2).
Comment: System s that d o not requ ire SUT/ RTE interaction for the Menu selection and the screen d isp lay can
assu m e a nu ll Menu RT and the com p onents that p rovid e the resp onse for the Menu requ est (e.g. screen caching
term inals) m u st be inclu d ed in the SUT and therefore m u st be p riced .
5.3.4
The Transaction Resp onse Tim e (Transaction RT) is the tim e betw een the tim estam p taken before the
last character of the requ ired inp u t d ata has been sent from the RTE (see Clau se 2) and the tim estam p taken after the
last character of the requ ired ou tp u t d ata has been received by the RTE (see Clau se 2) resu lting from a transaction
execu tion.
Comment: If the em u lated term inal m u st p rocess the d ata being entered or d isp layed , the tim e for this p rocessing
m u st be d isclosed and taken into accou nt w hen calcu lating the Transaction RT.
5.4
Computation of Throughput Rating
The TPC-C transaction m ix rep resents a com p lete bu siness cycle. It consists of m u ltip le bu siness transaction s w hich
enter new ord ers, qu ery the statu s of existing ord ers, d eliver ou tstand ing ord ers, enter p aym ents from custom ers,
and m onitor w arehou se stock levels.
5.4.1
The m etric u sed to rep ort Maxim u m Qu alified Throu ghp u t (MQTh) is a nu m ber of ord ers p rocessed
p er m inu te. It is a m easu re of "bu siness throu ghp u t " rather than a transaction execu tion rate. It im p licitly takes into
accou nt all transactions in the m ix as their ind ivid u al throu ghp u t is controlled by the w eighted Menu selection and
the m inim u m p ercentages of m ix d efined in Clau se 5.2.3.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 73 of 130
5.4.2
The rep orted MQTh is the total nu m ber of com p leted N ew -Ord er transaction s (see Clau se 5.1.2),
w here the Transaction RT (see Clau se 5.3.4) w as com pletely m easu red at the RTE d u ring the m easu rem ent interval,
d ivid ed by the elap sed tim e of the interval. N ew -Ord er transactions that rollback, as requ ired by Clau se 2.4.1.4, m u st
be inclu d ed in the rep orted MQTh.
5.4.3
The nam e of the m etric u sed to rep ort the MQTh of the SUT is tpmC.
5.4.4
All rep orted MQTh m u st be m easu red , rather than interp ola ted or extrap olated , and truncated to
exactly zero d ecim al p laces. For exam p le, su p p ose 105.548 tp m C is m easu red on a 100 term inal test for w hich 90% of
the N ew -Ord er transactions com p leted in less than 4.8 second s and 117.572 tp m C is m easu red on a 110 term inal test
for w hich 90% of the transactions com p leted in less than 5.2 second s. Then the reported tp m C is 105.
5.4.5
To be valid , the m easu rem ent interval m u st contain no m ore than 1% or no m ore than one (1),
w hichever is greater, of the Delivery transaction s skip p ed becau se there w ere few er than necessary ord ers p resent in
the N ew -Ord er table.
5.5
Measurement Interval Requirements
5.5.1
Steady State
5.5.1.1
of the SUT.
The test m u st be cond u cted in a steady state cond ition that rep resents the tru e su stainable throu ghp u t
5.5.1.2
Althou gh the m easu rem ent interval m ay be as short as 120 m inu tes, the system u nd er test m u st be
configu red to ru n the test at the rep orted tp m C for a continu ou s p eriod of at least eight hou rs w ithou t op erator
intervention , m aintaining fu ll ACID p rop erties. For exam p le, the m ed ia u sed to store at least 8 hou rs of log d ata
m u st be configu red if requ ired to recover from any single p oint of failu re (see Clau se 3.5.3.1).
Comment 1: An exam p le of a configu ration that w ou ld not com p ly is one w here a log file is allocated su ch that
better p erform ance is achieved d u ring the m easu red portion of the test than d u ring the rem aining p ortion of an eight
hou r test, p erhap s becau se a d ed icated d evice w as u sed initially bu t sp ace on a shared d evice is u sed later in the fu ll
eight hou r test.
Comment 2: Stead y state is easy to d efine (e.g., su stainable throu ghp u t ) bu t d ifficu lt to p rove. The test sp onsor
(and / or the au d itor) is requ ired to rep ort the m ethod u sed to verify stead y state su stainable throu ghp u t. The au d itor
is encou raged to u se available m onitoring tools to help d eterm ine the stead y state.
Comment 3: Som e asp ects of an im p lem entation can resu lt in system atic bu t sm all va riations in su stained
throu ghp u t over an 8 hou r p eriod . The cu m u lative effect of su ch variations m ay be u p to 2% of the rep orted
throu ghp u t. There is no requ irem ent for an 8 hou r ru n.
5.5.1.3
In the case w here a ram p -u p p eriod is u sed to reach stead y state, the p rop erly scaled initial d atabase
p op u lation is requ ired at the beginning of the ram p u p p eriod . The transaction m ix and the requ irem ents
su m m arized in Clau se 5.2.5.7 m u st be follow ed d u ring the ram p -u p as w ell as stead y state p eriod .
Comment: The intent of this clau se is to p revent significant alteration to the p rop erly scaled initial d atabase
p op u lation d u ring the ram p -u p p eriod .
5.5.1.4
A sep arate m easu rem ent to d em onstrate rep rod u cibility is not requ ired .
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 74 of 130
5.5.1.5
While variability is allow ed , the RTE cannot be artificially w eighted to generate inp u t d ata d ifferent
from the requ irem ents d escribed in Clau ses 2.4.1, 2.5.1, 2.6.1, 2.7.1, and 2.8.1. To be valid , the inp u t d ata generat ed
d u ring a rep orted m easu rem ent interval m u st not exceed the follow ing variability:
1.
At least 0.9% and at m ost 1.1% of the N ew -Ord er transaction s m u st roll back as a resu lt of an u nu sed item
nu m ber.
2.
The average num ber of ord er-lines p er ord er m u st be in the range of 9.5 to 10.5 and the num ber of ord er lines p er ord er m u st be u niform ly d istribu ted from 5 to 15 for the N ew -Ord er transaction s that are
su bm itted to th e SUT d u ring the m easu rem ent interval.
3.
The nu m ber of rem ote ord er-lines m u st be at least 0.95% and at m ost 1.05% of the nu m ber of ord er -lines
that are filled in by the N ew -Ord er transactions that are su bm itted to the SUT d u ring the m easu rem ent
interval.
4.
The num ber of rem ote Paym ent transaction s m u st be at least 14% and at m ost 16% of the nu m ber of
Paym ent transactions that are su bm itted to the SUT d u ring the m easu rem ent interval.
5.
The nu m ber of cu stom er selections by cu stom er last nam e in the Paym ent transaction m u st be at least 57%
and at m ost 63% of the nu m ber of Paym ent transactions that are su bm itted to the SUT d u ring the
m easu rem ent interval.
6.
The nu m ber of cu stom er selections by cu stom er last nam e in the Ord er-Statu s transaction m u st be at least
57% and at m ost 63% of the nu m ber of Ord er -Statu s transactions that are su bm itted to the SUT d u ring the
m easu rem ent interval.
5.5.1.6
To be valid , the m easu rem ent interval m u st contain no m ore than 1% or no m ore than one (1),
w hichever is greater, of the Delivery transaction s skip p ed becau se there w ere few er than necessary ord ers p resent in
the N ew -Ord er table.
5.5.2
5.5.2.1
D uration
The m easu rem ent interval m u st:
1.
Begin after the system reaches stead y state.
2.
Be long enou gh to generate rep rod u cible th rou ghp u t resu lts w hich are rep resentative of the p erform ance
w hich w ou ld be achieved d u ring a su stained eight hou r p eriod .
3.
Extend u ninterru p ted for a m inim u m of 120 m inu tes.
5.5.2.2
Som e system s d o not w rite m od ified d atabase record s/ p ages to d u rable m ed ia at the tim e of
m od ification, bu t instead d efer these w rites. At som e su bsequ ent tim e, the m od ified record s/ p ages are w ritten to
m ake the d u rable cop y cu rrent. This p rocess is d efined as a checkp oint in this d ocu m ent.
For system s w hich d efer d atabase w rite to d u rable m ed ia, it is a requ irem ent that:
1.
The tim e betw een check points (know n as the Checkp oint Interval (CI)), m u st be less than or equ al to 30
m inu tes. The Checkp oint Du ration , tim e requ ired by the DBMS to w rite m od ified d atabase record s/ p ages
to d u rable m ed ia, m u st be less than or equ al to the Checkp oint Interval.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 75 of 130
Comment: For system s w hich recover from instantaneou s interru p tions by ap p lying recovery d ata to the
d atabase stored on d u rable m ed ia (d atabase system s that d o not p erform checkp oints), it is a requ irem ent
that no recovery d ata old er than 30 m inu tes p rior to the interru p tion be u sed . The consequ ence of this
requ irem ent is that the d atabase contents stored on d u rable m ed ia cannot at any tim e d u ring the
Measu rem ent Interval (MI) be m ore than 30 m inu tes old er than the m ost cu rrent state of the d atabase
(±5%).
2.
5.6
All w ork requ ired to p erform a checkp oint m u st occu r at least once before, d u ring stead y state, and at least
fou r tim es d u ring the Measu rem ent Interval. The start tim e and d u ration in second s of at least the fou r
longest checkp oints d u ring the Measu rem ent Interval m u st be d isclosed ..
Required Reporting
5.6.1
The frequ ency d istribu tion of resp onse tim es of all transactions, started and com p leted d u ring the
m easu rem ent interval, m ust be rep orted ind ep end ently for each of the five transaction typ es (i.e., N ew -Ord er,
Paym ent, Ord er-Statu s, Delivery, and Stock-Level). The x-axis rep resents the transaction RT and m u st range from 0
to fou r tim es the m easu red 90th p ercentile RT (N ) for that transaction. The y -axis rep resents the frequ ency of the
transactions at a given RT. At least 20 d ifferent intervals, of equ al length, m u st be rep orted . The m axim u m , average,
and 90th p ercentile resp onse tim es m u st also be rep orted . An exam p le of su ch a grap h is show n below .
A verage Res pon se T ime
90 th P erce ntil e
Resp ons e Ti me
Numbe r of
T ra nsa ctio ns
0
N
Resp ons e Ti me (sec .)
4N
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 76 of 130
5.6.2
A grap h of resp onse tim es versu s throu ghp u t for the N ew -Ord er transaction , ru n w ithin the m ix
requ ired in Clau se 5.2.3, m u st be rep orted . The x-axis rep resents the m easu red N ew -Ord er throu ghp u t. The y-axis
rep resents the corresp ond ing 90th p ercentile of resp onse tim es. A grap h m u st be p lotted at ap p roxim ately 50%, 80%,
and 100% of rep orted throu ghp u t rate (ad d itional d ata p oints are op tional). The 50% and 80% d ata p oints are to be
m easu red on the sam e configu ration as the 100% ru n, for a m inim u m interval of 20 m inu tes, varying either the
Think Tim e of one or m ore transaction typ es or the nu m ber of active term inals. Interp olation of the grap h betw een
these d ata p oints is p erm itted . Deviations from the requ ired transaction m ix are perm itted for the 50% and 80% d ata
p oints. An exam p le of su ch a grap h is show n below .
90 th P erce ntil e
Resp ons e Ti me
5s ec.
Repo rted MQTh
0
50 %
80 %
10 0%
MQT h
5.6.3
The frequ ency d istribu tion of Think Tim es for the N ew -Ord er transaction , started and com p leted
d u ring the m easu rem ent interval, m u st be rep orted . The x-axis rep resents the Think Tim e and m u st range from 0 to
fou r tim es the actu al m ean of Think Tim e for that transaction. The y -axis rep resents the frequ ency of the transaction s
w ith a given Think Tim e. At least 20 d ifferent intervals, of equ al length, m u st be rep orted . The m ean Think Tim e
m u st also be rep orted . An exam p le of su ch a grap h is show n below .
Th in k Time Fre que ncy
Mean T hi nk T ime
0
12 .5
T hi nk Ti me (sec .)
50
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 77 of 130
5.6.4
A grap h of the throu ghp u t of the N ew -Ord er transaction versu s elap sed tim e (i.e., w all clock) m u st be
rep orted for both ram p -u p tim e and m easu rem ent interval. The x-axis rep resents the elap sed tim e from the start of
the ru n. The y-axis rep resents the throu ghp u t in tp m C. At least 240 d ifferent intervals shou ld be u sed w ith a
m axim u m interval size of 30 second s. The op ening and the closing of the m easu rem ent interval m u st also be
rep orted and show n on the grap h. The start tim e for each of the checkp oints m u st be ind icated on the grap h. An
exam p le of su ch a grap h is show n below .
MQTh
Ramp-up
Steady State
Measurement Interval
Start
0
Ramp-down
Measurement Interval
End
Elapsed Time (sec.)
5.7 Primary Metrics
To be com p liant w ith the TPC-C stand ard and the TPC‟ s Fair Use Policies and Gu id elines, all p u blic
references to TPC-C resu lts for a configu ration m u st inclu d e the follow ing com p onents w hich w ill be
know n as the Prim ary Metrics.
5.7.1

The TPC-C Maxim um Qu alified Throu ghp u t (MQTh) rating exp ressed in tp m C. This is know n as the
Perform ance Metric. (See Clau se 5.4.)

The TPC-C total 3-year p ricing d ivid ed by the MQTh and exp ressed as p rice/ tp m C. This is also know n
as the Price/ Perform ance m etric. (See Clau se 7.3.)

The d ate w hen all p rod u cts necessary to achieve the stated p erform ance w ill be available (stated as a
single d ate on the execu tive su m m ary). This is know n as the availability d ate. (See Clau se 8.1.8.3.)

When the op tional TPC-Energy stand ard is u sed , the ad d itional p rim ar y m etric exp ressed as
w atts/ Ktp m C m u st be rep orted . In ad d ition, the requ irem ents of the TPC -Energy Sp ecification, located
at w w w .tp c.org, m u st be m et.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 78 of 130
Clause 6: SUT, D RIVER, and COMMUN ICATION S D EFIN ITION
6.1
Models of the Target System
Som e exam p les of a system w hich rep resents the target (object) of this benchm ark are show n p ictorially below . By
w ay of illu stration, the figu res also d ep ict the RTE/ SUT bou nd ary (see Clau ses 6.3 and 6.4) w here the resp onse tim e
is m easu red .
Example 1
RTE
Terminal Network
SUT
Serv er Sy stem(s)
T
S
E
R
V
E
R
T
Network*
S-S
Network*
SUT
Legend: C = Client
K/D = Key board/Display
RTE = Remote Terminal Emulator
S
= Serv er
SUT = Sy stem Under Test
T
= Terminal
WS = Workstation
*
= Optional
T
Example 2
RTE
SUT
Serv er Sy stem(s)
Response Time Measured Here
K/D
ws
WS - S
Network*
ws
*
K/D
Example 3
RTE
Terminal Network
SUT
Serv er Sy stem(s)
Client Sy stem(s)
T
T
C-S
Network*
S
E
R
V
E
R
S-S
Network*
*
T
Network*
C
L
I
E
N
T
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 79 of 130
S
E
R
V
E
R
S-S
Network*
6.2
Test Configuration
The test configu ration consists of the follow ing elem ents:
• System Und er Test (SUT)
• Driver System (s)
• Driver/ SUT Com m u nications Interface(s)
If one of the netw orks is a WAN , the tested configu rations need not inclu d e th e WAN long -hau l com m u nications
lines.
6.3
System Under Test (SUT) D efinition
6.3.1
The SUT consists of:
• One or m ore p rocessing u nits (e.g., host, front -end s, w orkstations, etc.) w hich w ill ru n the transaction m ix
d escribed in Clau se 5.2.3, and w hose aggregate p erform ance (total Maxim u m Qu alified Throu ghp u t) w ill be
d escribed by the m etric tp m C.
• Any front-end system s are consid ered to be p art of the SUT. Exam p les of front-end system s are front-end
d ata com m unication p rocessors, clu ster controllers, d atabase clients (as in the client/ server m od el), and
w orkstations.
• The host system (s), inclu d ing hard w are and softw are, su p p orting the d atabase em p loyed in the benchm ark.
• The hard w are and softw are com p onents of all netw orks requ ired to con nect and su p p ort the SUT
com p onents.
• Data storage m ed ia su fficient to satisfy both the scalin g requ irem ents in Clau se 4.2 and the ACID p rop erties
of Clau se 3.
6.3.2
A single benchm ark resu lt m ay be u sed for m u ltip le SUTs p rovid ed the follow in g cond itions are m et:
• Each SUT m u st have the sam e hard w are and softw are architectu re and configu ration.
• The only excep tion allow ed are for elem ents not involved in the p rocessing logic of the SUT (e.g., num ber of
p erip heral slots, p ow er su p p ly, cabinetry, fans, etc.)
• Each SUT m u st su p p ort the p riced configu ration.
6.4
D river D efinition
6.4.1
An external Driver System (s), w hich p rovid es Rem ote Term inal Em u lator (RTE) fu nctionality, m u st be
u sed to em u late the target term inal p op u lation and their em u lated u sers d u ring the benchm ark ru n.
6.4.2
The RTE p erform s the follow ing fu nctions:
• Em u lates a u ser entering inp u t d ata on the inp u t/ ou tp u t screen of an em u lated term inal by generating and
send ing transactional m essages to the SUT;
• Em u lates a term inal d isp laying ou tp u t m essages on an inp u t/ ou tp u t scr een by receiving resp onse m essages
from the SUT;
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 80 of 130
• Record s resp onse tim es;
• Perform s conversion and / or m u ltip lexing into the com m u nications p rotocol u sed by the com m u nications
interface betw een the d river and the SUT ;
• Perform s statistical accou nting (e.g., 90th p ercentile resp onse tim e m easu rem ent, throu ghp u t calcu lation, etc.)
is also consid ered an RTE fu nction.
6.4.3
N orm ally, the Driver System is exp ected to p erform RTE fu nctions only. Work d one on the Driver
System in ad d ition to the RTE as sp ecified in Clau se 6.4.2 m u st be thorou ghly ju stified as sp ecified in Clau se 6.6.3.
6.4.4
The intent is that the Driver System m u st reflect the p rop osed term inal configu ration and cannot ad d
fu nctionality or p erform ance above the p riced netw ork com p onents in the SUT. It m u st be d em onstrated that
p erform ance resu lts are not enhanced by u sing a Driver System .
6.4.5
Softw are or hard w are w hich resid es on the Driver w hich is not the RTE is to be consid ered as p art of
the SUT. For exam p le, in a "client/ server" m od el, the client softw are m ay be ru n or be sim u lated on the Driver
System (see Clau se 6.6.3).
6.5
Communications Interface D efinitions
6.5.1
I/O Channel Connections
6.5.1.1
All p rotocols u sed m u st be com m ercially available.
Comment: It is the intention of this d efinition to exclu d e non -stand ard I/ O channel connections. The follow ing
situ ations are exam p les of accep table channel connections:
• Configu rations or architectu res w here term inals or term inal controllers are norm ally and rou tinely connected
to an I/ O channel of a p rocessor.
• Where the p rocessor(s) in the SUT is/ are connected to the local com m u nications netw ork via a front -end
p rocessor, w hich is channel connected . The front-end processor is p riced as p art of the SUT.
6.5.2
D river/SUT Communications Interface
6.5.2.1
The com m u nications interface betw een the Driver System (s) and the SUT m u st be the m echan ism by
w hich the system w ou ld be connected w ith the term inal (see Clau se 2.1.8) in the p rop osed configu ration.
6.6
Further Requirements on the SUT and D river System
6.6.1
Restrictions on D river System
Cop ies of any p art of the tested d atabase or file system or its d ata stru ctu res, ind ices, etc. m ay not be p resent on the
Driver System d u ring the test.
Comment: Synchronization betw een RTE and SUT is d isallow ed .
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 81 of 130
6.6.2
Individual Contexts for Emulated Terminals
The SUT m u st contain context for each term inal em u lated , and m u st m aintain that context for the d u ration of that
test. That context m u st be id entical to the one w hich w ou ld su p p ort a real term inal. A term inal w hich send s a
transaction cannot send another u ntil the com p letion of that transaction, w ith the excep tion of the d eferred execu tion
of the Delivery transaction .
Comment: The context referred to in this clau se sh ou ld consist of inform ation su ch as term inal id entification,
netw ork id entification, and other inform ation necessary for a real term inal to be know n to (i.e., configu red on) the
SUT. The intention is to allow p seu d o-conversational transactions. The intent of this clau se is sim p ly to p revent a test
sp onsor from m u ltip lexing m essages from a very large nu m ber of em u lated term inals into a few inp u t lines and
claim ing or im p lying that the tested system su p p orts that nu m ber of u sers regard less of w hether the system actu ally
su p p orts that nu m ber of real term inals. It is allow ab le for a term inal to lose its connection to the SUT d u ring the
Measu rem ent Interval as long as its context is not lost and it is reconnected w ithin 90 second s u sing the sam e
context. The loss and re-entry of a u ser m u st be logged and the total nu m ber repo rted .
6.6.3
D river System D oing More Than RTE Function
In the event that a Driver System m u st be u sed to em u late ad d itional fu nctionality other than that d escribed in
Clau se 6.4, then this m u st be ju stified as follow s:
6.6.3.1
It m u st be d em onstrated that the architectu re of the p rop osed solu tion m akes it u neconom ical to
p erform the benchm ark w ithou t p erform ing the w ork in qu estion on the d river (e.g., in a "client/ server" d atabase
im p lem entation, w here the client softw are w ou ld ru n on a large nu m ber of w orkstations).
6.6.3.2
Ru le 6.6.1 m u st not be violated .
6.6.3.3
It m u st be d em onstrated that execu tables p laced on the Driver System are fu nctionally equ ivalent to
those on the p rop osed (target) system .
6.6.3.4
It m u st be d em onstrated that p erform ance resu lts are not enhanced by p erform ing the w ork in
qu estion on the Driver System . The intent is that a test shou ld be ru n to d em onstrate that the fu nctionality,
p erform ance, and connectivity of the em u lated solu tion is the sam e as that for the p riced system . These test d ata
m u st be inclu d ed in the Fu ll Disclosu re Rep ort.
For exam p le, if the Driver System em u lates the fu nction of a term inal concentrator, there m u st be test d ata to
d em onstrate that a real concentrator configu red w ith the claim ed nu m ber of attached d evices w ou ld d eliver the
sam e (or better) resp onse tim e as is m easu red w ith the Driver System . The t erm inal concentrator m u st be con figu red
as it w ou ld be in the p riced system and load ed to the m axim u m nu m ber of lines u sed in the p riced configu ration.
The d em onstration test m u st be ru n as p art of the SUT configu ration that is ru nning a fu ll load on a p rop erly scaled
d atabase. The follow ing d iagram illu strates the configu ration of a p ossible d em onstration test:
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 82 of 130
Side-A
Side-B
RTE
RTE
Terminal
Concentrator
SUT
In the above exam p le, the d ifference in the m easu red resp onse tim e betw een Sid e -A and Sid e-B shou ld be less than
or equ al to any ad ju stm ents to the resp onse tim e rep orted in the Full Disclosu re Rep ort .
If the resp onse tim e d elay generated from a d em onstration test is to be u sed in m u ltip le benchm ark tests, th e
d em onstration m u st be p erform ed on a SUT generating the highest tp m C rate on the term inal concentrator.
6.6.3.5
Ind ivid u al contexts m u st continu e to be m aintained from the RTE throu gh to the SUT.
6.6.3.6
A com p lete fu nctional d iagram of both the benchm ark configu ration and the configu ration of the
p rop osed (target) system m u st be d isclosed . A d etailed list of all softw are and hard w are fu nctionality being
p erform ed on the Driver System , and its interface to the SUT, m u st be d isclosed .
6.6.3.7
When em u lating end -u ser d evices u tilizing a w eb brow ser, the im p lem ent or shall inclu d e a 0.1 second
resp onse tim e d elay in the em u lation to com p ensate for the d elay encou ntered in the p rop o sed end -to-end
configu ration for the brow ser d elay.
Comment:
6.6.4
The u se of a m easu red d elay is not allow ed on this non -p riced com p onent.
D isclosure of N etw ork Configuration and Emulated Portions
The test sp onsor shall d escribe com p letely the netw ork configu rations of both the tested services and the prop osed
real (target) services w hich are being rep resented . A thorou gh exp lanation of exactly w hich p arts of the p rop osed
configu ration are being rep laced by the Driver System m u st be given.
6.6.5
Limits on Concentration
The level of concentration of m essages betw een the Driver System (s) and the SUT in the benchm ark configu ration
m u st not exceed that w hich w ou ld occu r in the p rop osed (target) configu ration. In p articu lar, the num ber of
com m u nications p ackets w hich can be concentrated m u st not exceed the num ber of term inal s w hich w ou ld be
d irectly connected to that concentrator in the p rop osed configu ration.
Comment: The intent is to allow only first level concentration on the RTE, bu t d oes not p reclu d e ad d itional levels of
concentration on the SUT.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 83 of 130
6.6.6
Limits on Operator Intervention
System s m u st be able to ru n for at least 8 hou rs w ithou t op erator intervention.
6.6.7
Limits on Profile-D irected Softw are Optimizations
Sp ecial ru les ap p ly to the u se of so-called p rofile-d irected op tim ization (PDO), in w hich binary execu tables are
reord ered or otherw ise op tim ized to best su it the need s of a p articu lar w orkload . These ru les d o not ap p ly to the
rou tine u se of PDO by a d atabase vend or in the cou rse of bu ild ing com m ercially available and su p p orted d atabase
p rod u cts; su ch u se is not restricted . Rather, the ru les ap p ly to the u se of PDO by a test sp onsor to op tim ize
execu tables of a d atabase prod u ct for a p articu lar w orkload . Su ch op tim ization is p erm issible if all of the follow ing
cond itions are satisfied :
1. The u se of PDO or sim ilar p roced u res by the test sp onsor m u st be d isclosed .
2. The p roced u re and any scrip ts u sed to p erform the op tim ization m u st be d isclosed .
3. The p roced u re u sed by the test sp onsor cou ld reasonably be u sed by a cu stom er on a ship p ed d atabase
execu table.
4. The op tim ized d atabase execu tables resu lting form the ap p lication of the p roced u re m u st be su p p orted by
the d atabase softw are vend or.
5. The sam e set of DBMS execu tables m u st be u sed for all au d ited p hases of the benchm ark.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 84 of 130
Clause 7: PRICIN G
Ru les for p ricing the Priced Configuration and associated softw are and m aintenance are inclu d ed in the cu rrent
revision of the TPC Pricing Sp ecification, located at w w w .tp c.org.
7.1
Pricing Methodology
7.1.1
The intent of this section is to d efine the m ethod ology to be u sed in calcu lating the 3 -year p ricing and the
p rice/ p erform ance (p rice/ tp m C). The fu nd am ental p rem ise is that w hat is tested and / or em u lated is p riced and
w hat is p riced is tested and / or em u lated . Excep tions to this p rem ise are noted below .
7.1.2
The p rop osed system to be p riced is the aggregation of the SUT and netw ork com p onents that w ou ld be
offered to achieve the rep orted p erform ance level. Calcu lation of the p riced system consists of:
• Price of the SUT as tested and d efined in Clau se 6. This exclu d es term inals and the term inal netw ork (see
Clau se 6.1).
• Price of all em u lated com p onents exclu d ing term inals and the term inal netw ork (see Clau se 6.1).
• Price of on-line storage for the d atabase p op u lation, 8 hou rs of p rocessing at the rep orted tp m C , d ata
generated by 60 8-hou r d ays of p rocessing at the rep orted tp m C, and the system softw are necessary to create,
op erate, ad m inister, and m aintain the ap p lication .
• Price of ad d itional p rod u cts that are requ ired for the op eration, ad m inistration or m aintenance of the p riced
system .
• Price of ad d itional p rod u cts requ ired for ap p lication d evelop m ent.
Comment: Any com p onent, for exam p le a N etw ork Interface Card (N IC), m u st be inclu d ed in the p rice of the
SUT if it d raw s resou rces for its ow n op eration from the SUT. This inclu d es, bu t is not lim ited to, p ow er and
cooling resou rces. In ad d ition, if the com p onent p erform s any of the fu nction d efined in the TPC -C
sp ecification it m u st be p riced regard less of w here is d raw s its resou rces.
7.1.3 In ad d ition to the p ricing m ethod ology requ ired by the cu rrent revision of the TPC Pricing Sp ecification ,
term inals and the term inal netw ork (see d iagram in Clau se 6.1) are exclu d ed from the p riced system . For end -u ser
d evices p rovid ing m ore fu nction, m onitors, and keyboard s need not be p r iced if cap able of being p riced sep arately.
7.2
Priced System
7.2.1 The nu m ber of u sers for TPC-C is d efined to be equ al to the num ber of term inals em u lated in the tested
configu ration. Any u sage p ricing for the above nu m ber of u sers shou ld be based on the p ricing p olicy of the
com p any su p p lying the p riced com p onent.
7.2.2
Terminals and N etw ork Pricing
7.2.2.1
The p rice of the Driver System is not inclu d ed in the calcu lation. In the case w here the Driver System
p rovid e fu nctionality in ad d ition to the RTE d escribed in Clau se 6, then the p rice of the em u lated
hard w are/ softw are com p onents are to be inclu d ed , excep t term inals and the term inal netw ork.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 85 of 130
7.2.2.2
The term inals m u st be com m ercially available p rod u cts cap able of entering via a keyboard all
alp habetic and nu m eric characters and cap able of d isp laying sim u ltaneou sly the d ata and the field s d escribed in
Clau se 2.
7.2.2.3
For WAN configu rations, the num ber of d evices to be connected to a single line m u st be no greater
than that em u lated p er Clau se 6.
7.2.3
D atabase Storage and Recovery Log Pricing
7.2.3.1
Within the p riced system , there m u st be su fficient on -line storage to su p p ort any exp and ing system
files and the d u rable d atabase p op u lation resu lting from execu ting the TPC -C transaction m ix for 60 eight-hou r d ays
at the rep orted tp m C (see Clau se 4.2.3). Storage is consid ered on -line, if any record can be accessed rand om ly and
u p d ated w ithin 1 second . On -line storage m ay inclu d e m agnetic d isks, op tical d isks, solid -state storage or any
com bination of these, p rovid ed that the above m entioned access criteria is m et.
Comment 1: The intent of this clau se is to consid er as on -line any storage d evice cap able of p rovid ing an access tim e
to d ata, for rand om read or u p d ate, of one second or less, even if this access tim e requ ires the creation of a logical
access p ath not p resent in the tested d atabase. For exam p le, a d isk based sequ ential file m ight requ ire the creation of
an ind ex to satisfy the access tim e requ irem ent.
Comment 2: Du ring the execu tion of the TPC-C transaction m ix, the ORDER, N EW-ORDER, ORDER-LIN E, and
H ISTORY tables grow beyond the initial d atabase p op u lation requ irem ents of the benchm ark as sp ecified in Clau se
4. Becau se these tables grow natu rally, it is intend ed that 60 d ays of grow th beyond the sp ecified initial d atabase
p op u lation also be taken into accou nt w hen p ricing the system .
7.2.3.2
Recovery d ata m u st be m aintained in su ch a w ay that the p u blished tp m C transaction rate cou ld be
su stained for an 8-hou r p eriod . Roll-back recovery d ata m u st be either in m em ory or in on-line storage at least u ntil
transactions are com m itted . Roll-forw ard recovery d ata m ay be stored on an off-line d evice, p rovid ing the follow ing:
• The p rocess w hich stores th e roll-forw ard d ata is active d u rin g the m easu rem ent interval.
• The roll-forw ard d ata w hich is stored off-line d u ring the m easu rem ent interval (see Clau se 5.5) m u st be at
least as great as the roll-forw ard recovery d ata that is generated d u ring the p eriod (i.e., the d ata m ay be first
created in on -line storage and then m oved to off-line storage, bu t the creation and the m ovem ent of the d ata
m u st be in stead y state).
• All ACID p rop erties m u st be retained .
7.2.3.3
It is p erm issible to not have the storage requ ired for the 60-d ay sp ace on the tested system . H ow ever,
any ad d itional storage d evice inclu d ed in the p riced system bu t not configu red on the tested system m u st be of th e
typ e(s) actu ally u sed d u rin g the test and m u st satisfy norm al system configu ration ru les.
Comment: Storage d evices are consid ered to be of th e sam e typ e if they are id entical in all asp ects of their p rod u ct
d escrip tion and technical sp ecifications.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 86 of 130
7.2.3.4
The requ irem ent to su p p ort eight hou rs of recovery log d ata can be m et w ith storage on any d u rable
m ed ia (see Clau se 3.5.1) if all d ata requ ired for recovery from failu res listed in Clau ses 3.5.3.2 and 3.5.3.3 are on -line.
7.2.4
Additional Operational Components
7.2.4.1
Ad d itional p rod u cts that m ight be inclu d ed on a custom er installed configu ration, su ch as op erator
consoles and m agnetic tap e d rives, are also to be inclu d ed in the p riced sys tem if exp licitly requ ired for the
op eration, ad m inistration, or m aintenance, of the p riced system .
7.2.4.2
Cop ies of the softw are, on ap p rop riate m ed ia, and a softw are load d evice, if required for initial load or
m aintenance u p d ates, m u st be inclu d ed .
7.2.4.3
The p rice of an Uninterru p tible Pow er Su p p ly , sp ecifically contribu ting to a d u rability solu tion, m u st
be inclu d ed (see Clau se 3.5.1).
7.2.4.4
inclu d ed .
7.2.5
The p rice of all com p onents, inclu d ing cables, u sed to interconnect com p onents of the SUT m u st be
Additional Softw are
7.2.5.1
The p rice m u st inclu d e the softw are licenses necessary to create, com p ile, link, and execu te this
benchm ark ap p lication as w ell as all ru n -tim e licenses requ ired to execu te on host system (s), client system (s) and
connected w orkstation(s) if u sed .
7.2.5.2
In the event the ap p lication p rogram is d evelop ed on a system other than the SUT, the p rice of that
system and any com p ilers and other softw are u sed m u st also be inclu d ed as p art of the p riced system .
7.2.6
Component Substitution
7.2.6.1
As p er the cu rrent revision of the TPC Pricing Sp ecification, the follow ing com p onents in the
m easu red configu ration m ay be su bstitu ted if they are no longer ord erable by the p u blication d ate:

front-end system s

d isks, d isk enclosu res, external storage controllers

term inal servers

netw ork ad ap ters

rou ters, brid ges, rep eaters, sw itches

cables
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 87 of 130
7.2.6.2
Su bstitu tion of the Server or the H ost system , OS, DBMS or TP Monitor is not allow ed u nd er any
circu m stances.
7.3
Required Reporting
7.3.1
Tw o m etrics w ill be rep orted w ith regard to p ricing. The first is the total 3-year p ricing as d escribed in
the p reviou s clau ses. The second is the total 3-year p ricing d ivid ed by the rep orted Maxim u m Qu alified Throu ghp u t
(tp m C), as d efined in Clau se 5.4.
7.3.2
The 3-year p ricing m etric m u st be fu lly rep orted in the basic m onetar y u nit of the local cu rrency
rou nd ed u p and the p rice/ p erform ance m etric m u st be rep orted to a m inim u m p recision of three significant d igits
rou nd ed u p . N either m etric m ay be interp olated or extrap olated . For exam p le, if the total p rice i s $ 5,734,417.89USD
and the rep orted throu ghp u t is 105 tp m C, then the 3-year p ricing is $ 5,734,418USD and the p rice/ p erform ance is $
54,700USD/ tp m C (5,734,418/ 105).
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 88 of 130
Clause 8: FULL D ISCLOSURE
Requ irem ents for p ricing-related item s in the Full Disclosu re Rep ort are inclu d ed in the cu rrent revision of the TPC
Pricing Sp ecification, located at w w w .tp c.org.
8.1
Full D isclosure Report Requirements
A Full Disclosu re rep ort is requ ired in ord er for resu lts to be consid ered com p liant w ith the TPC -C benchm ark
sp ecification.
Comment: The intent of this d isclosu re is for a cu stom er to be able to rep licate the resu lts of this benchm ark given
the ap p rop riate d ocu m entation and p rod u cts.
This section inclu d es a list of requ irem ents for the Full Disclosu re rep ort .
8.1.1
General Items
8.1.1.1
The ord er and titles of sections in the Test Sp onsor‟ s Full Disclosu re rep ort m u st corresp ond w ith the
ord er and titles of sections from the TPC-C stand ard sp ecification (i.e., this d ocu m ent). The intent is to m ake it as
easy as p ossible for read ers to com p are and contrast m aterial in d ifferent Full Disclosu re rep orts.
8.1.1.2
The TPC Execu tive Su m m ary Statem ent m u st be inclu d ed near the beginning of the Full Disclosu re
rep ort d escribing the com p onents of the p riced configu ration that are requ ired to achieve the p erform ance resu lt . An
exam p le of the Execu tive Su m m ary Statem ent is p resented in Ap p end ix B. The latest version of the requ ired form at
is available from the TPC Ad m inistrator. When the op tional TPC-Energy stand ard is u sed , the ad d itional
requ irem ents and form atting of TPC-Energy related item s in the execu tive su m m ary m u st be rep orted and u sed . In
ad d ition, the requ irem ents of the TPC-Energy Sp ecification, located at w w w .tp c.org, m u st be m et.
Comment 1: The p rocessor inform ation to be inclu d ed is as follow s:

N od e cou nt if ap p licable

For each p rocessor typ e, total enabled p rocessor cou nt, total enabled p rocessor core cou nt, total enabled
p rocessor thread cou nt and p rocessor m od el and sp eed in H z. If m ore than one proces sor typ e is u sed , they
m u st be d escribed on sep arate lines

The nu m ber rep orted in the "Database Processors" box in the Execu tive Su m m ary m u st sp ecify the total
p rocessor/ core/ thread inform ation for all the enabled p rocessors in the d atabase server(s).
Processor inform ation for all servers in the SUT is rep orted in the "System Com p onents" box and not in the
“ Processors” box
Comment 2: If a p ackage is p riced bu t all of its com p onents are not u sed in the p riced benchm ark configu ration, the
p ackage m u st be listed in the p ricing sp read sheet, inclu d ing any p u rchased com p onents not u sed in running the
benchm ark. H ow ever, only the com p onents actu ally need ed to p rod u ce the rep orted p erform ance m etric shou ld
ap p ear in the Execu tive Su m m ary configu ration inform ation.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 89 of 130
8.1.1.3
rep ort:
The num erical qu antities listed below m u st be su m m arized near the beginning of the Full Disclosu re
• com p u ted Maxim u m Qu alified Throu ghp u t in tp m C,
• ninetieth p ercentile, average and m axim u m resp onse tim es for the N ew -Ord er, Paym ent, Ord er-Statu s, StockLevel, Delivery (d eferred and interactive) and Menu transactions,
• tim e in second s ad d ed to resp onse tim e to com p ensate for d elays associated w ith em u lated com p onents,
• p ercentage of transaction m ix for each transaction typ e,
• m inim u m , average, and m axim u m key and think tim es for the N ew -Ord er, Paym ent, Ord er-Statu s, StockLevel, and Delivery (interactive),
• ram p -u p tim e in m inu tes,
• m easu rem ent interval in m inu tes,
• nu m ber of checkp oints in the m easu rem ent interval,
• checkp oint interval in m inutes,
• nu m ber of transactions (all typ es) com p leted w ithin the m easu rem ent interval,
Comment: Ap p end ix C contains an exam p le of su ch a su m m ary. The intent is for d ata to be conveniently and easily
accessible in a fam iliar arrangem ent and style. It is not requ ired to p recisely m im ic the layou t show n in Ap p end ix C.
8.1.1.4
The ap p lication p rogram (as d efined in Clau se 2.1.7) m u st be d isclosed . This inclu d es, bu t is not
lim ited to, the cod e im p lem enting the five transactions and the term inal inp u t and ou tp u t fu nctions.
8.1.1.5
p rovid ed .
A statem ent id entifying the benchm ark sp onsor(s) and other p articip ating com p anies m u st be
8.1.1.6
Settings m u st be p rovid ed for all cu stom er -tu nable p aram eters and op tions w hich have been chang ed
from the d efau lts fou nd in actu al p rod u cts, inclu d ing bu t not lim ited to:
• Database tu ning op tions.
• Recovery/ com m it op tions.
• Consistency/ locking op tions.
• Op erating system and ap p lication configu ration p aram eters.
• Com p ilation and linkage op tions and ru n -tim e op tim izations u sed to create/ install ap p lication s, OS, and / or
d atabases.
Comment 1: This requ irem ent can be satisfied by p rovid ing a fu ll list of all p aram eters and op tions.
Comment 2: The intent of the above clau se is that anyone attem p ting to recreate the benchm ark environm ent has
su fficient inform ation to com p ile, link, op tim ize, and execu te all softw are u sed to p rod u ce the d isclosed benchm ark
resu lt.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 90 of 130
8.1.1.7
Diagram s of both m easu red and p riced configu rations m u st be p rovid ed , accom p anied by a
d escrip tion of the d ifferences. This inclu d es, bu t is not lim ited to:
• N u m ber and typ e of p rocessors/ cores/ thread s.
• Size of allocated m em ory, and any sp ecific m ap p ing/ p artitioning of m em ory u niqu e to the test.
• N u m ber and typ e of d isk u nits (and controllers, if ap p licable).
• N u m ber of channels or bu s connections to d isk u nits, inclu d ing their p rotocol typ e.
• N u m ber of LAN (e.g., Ethernet) connections, inclu d ing rou ters, w orkstations, term inals, etc., that w ere
p hysically u sed in the test or are incorp orated into the p ricing stru ctu re (see Clau se 8.1.8).
• Typ e and the ru n -tim e execu tion location of softw are com p onents (e.g., DBMS, client p rocesses, transaction
m onitors, softw are d rivers, etc.).
Comment: Detailed d iagram s for system configu rations and architectu res can wid ely vary, an d it is im p ossible to
p rovid e exact gu id elines su itable for all im p lem entations. The intent here is to d escribe the system com p on ents and
connections in su fficient d etail to allow ind ep end ent reconstru ction of the m easu rem ent environm ent.
The follow ing sam p le d iagram illu strates a w orkstation/ rou ter/ server benchm ark (m easu red ) configu ration u sing
Ethernet and a single p rocessor. N ote that this d iagram d oes not d ep ict or im p ly any op tim al configu ration for the
TPC-C benchm ark m easu rem ent.
Concentrator
Concentrator
Concentrator
Concentrators:
LAN :
CPU:
Disk:
16 1.2 Gby te Disk Units
Model xxx
CPU
128Mby tes
4 I/O cards
1 Ethernet
adapter
System _WW w ith 10 d iskless w orkstations each
Ethernet u sing N ET_XX rou ters
Mod el_YY w ith 128 Mbytes of m ain m em ory, 4 I/ O card s w ith SCSI II p rotocol su p p ort
Vend or_ZZ 1.2 Gbyte d rives
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 91 of 130
8.1.2
Logical D atabase D esign Related Items:
8.1.2.1
Listings m u st be p rovid ed for all table d efinition statem ents and all other statem ents u sed to set -u p
the d atabase.
8.1.2.2
The p hysical organization of tables and ind ices, w ithin the d atabase, m u st be d isclosed .
Comment: The concep t of p hysical organization inclu d es, bu t is not lim ited to: record clu stering (i.e., row s from
d ifferent logical tables are co-located on the sam e p hysical d ata p age), ind ex clu stering (i.e., row s and leaf nod es of
an ind ex to these row s are co-located on the sam e p hysical d ata p age), and p artial fill-factors (i.e., p hysical d ata
p ages are left p artially em p ty even thou gh ad d itional row s are available to fill them ).
8.1.2.3
It m u st be ascertained that insert and / or d elete op erations to any of the tables can occu r concu rrently
w ith the TPC-C transaction m ix. Fu rtherm ore, any restriction in the SUT d atabase im p lem entation that p reclu d es
inserts beyond the lim its d efined in Clau se 1.4.11 m ust be d isclosed . This inclu d es the m axim u m nu m ber of row s
that can be inserted and the m axim u m key valu e for these new row s.
8.1.2.4
While there are a few restrictions p laced u p on horizontal or vertical p artitioning of tables and row s in
the TPC-C benchm ark (see Clau se 1.6), any su ch p artitioning m u st be d isclosed . Using the CUSTOMER table as an
exam p le, su ch p artitioning cou ld be d enoted as:
C_p art_1
C_ID
C_D_ID
C_W_ID
------------------------ vertical p artition ---------------C_p art_2
C_FIRST
C_MIDDLE
C_LAST
C_STREET_1
C_STREET_2
C_CITY
C_STATE
C_ZIP
C_PH ON E
C_SIN CE
------------------------ vertical p artition ---------------C_p art_3
C_CREDIT
C_CREDIT_LIM
C_DISCOUN T
C_BALAN CE
C_YTD_PAYMEN T
C_PAYMEN T_CN T
C_DELIVERY_CN T
------------------------ vertical p artition ---------------C_p art_4
C_DATA
Once the p artitioned d atabase elem ents have been so id entified , they can be referred to by, for exam p le, their
T_part_N notation w hen d escribing the p hysical allocation of d atabase files (see Clau se 8.1.5), w here T ind icates the
table nam e and N ind icates the p artition segm ent nu m ber.
8.1.2.5
Rep lication of tables, if u sed , m u st be d isclosed (see Clau se 1.4.6).
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 92 of 130
8.1.2.6
Ad d itional and / or d u p licated attribu tes in any table m u st be d isclosed along w ith a statem ent on the
im p act on p erform ance (see Clau se 1.4.7).
8.1.3
Transaction and Terminal Profiles Related Items
8.1.3.1
The m ethod of verification for the rand om nu m ber generation m u st be d escribed .
8.1.3.2
The actu al layou ts of the term inal inp u t/ ou tp u t screens m u st be d isclosed .
8.1.3.3
The m ethod u sed to verify that the em u lated term inals p rovid e all the featu res d escribed in Clau se
2.2.2.4 m u st be exp lained . Althou gh not sp ecifically p riced , the typ e and m od el of the term inals u sed for the
d em onstration in 8.1.3.3 m u st be d isclosed and com m ercially available (inclu d ing su p p orting softw are and
m aintenance).
8.1.3.4
Any u sage of p resentation m anagers or intelligent term inals m u st be exp lained .
Comment 1: The intent of this clau se is to d escribe any sp ecial m anip u lations p erform ed by a local term inal or
w orkstation to off-load w ork from the SUT. This inclu d es, bu t is not lim ited to: screen p resentations, m essage
bu nd ling, and local storage of TPC-C row s.
Comment 2: This d isclosu re also requ ires that all d ata m anip u lation fu nctions p erform ed by the local term inal to
p rovid e navigational aid s for transaction(s) m u st also be d escribed . Within this d isclosu re, the p u rp ose of su ch
ad d itional fu nction(s) m u st be exp lained .
8.1.3.5
The p ercentage of hom e and rem ote ord er -lines in the N ew -Ord er transaction s m u st be d isclosed .
8.1.3.6
The p ercentage of N ew -Ord er transaction s that w ere rolled back as a resu lt of an u nu sed item nu m ber
m u st be d isclosed .
8.1.3.7
The nu m ber of item s p er ord ers entered by N ew -Ord er transaction s m u st be d isclosed .
8.1.3.8
The p ercentage of hom e and rem ote Paym ent transaction s m u st be d isclosed .
8.1.3.9
The p ercentage of Paym ent and Ord er -Statu s transaction s that u sed non -p rim ary key (C_LAST) access
to the d atabase m u st be d isclosed .
8.1.3.10
The p ercentage of Delivery transaction s that w ere skip p ed as a resu lt of an insu fficient nu m ber of
row s in the N EW-ORDER table m u st be d isclosed .
8.1.3.11
The m ix (i.e., p ercentages) of transaction typ es seen by the SUT m u st be d isclosed .
8.1.3.12
The qu eu ing m echanism u sed to d efer the execu tion of the Delivery transaction m u st be d isclosed .
8.1.4
Transaction and System Properties Related Items
8.1.4.1
The resu lts of the ACID tests m u st be d isclosed along w ith a d escrip tion of how the ACID
requ irem ents w ere m et. This inclu d es d isclosing w hich case w as follow ed for the execu tion of Isolation Test 7.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 93 of 130
8.1.5
Scaling and D atabase Population Related Items
8.1.5.1
The card inality (e.g., the nu m ber of row s) of each table, as it existed at the start of the benchm ark ru n
(see Clau se 4.2), m u st be d isclosed . If the d atabase w as over -scaled and inactive row s of the WAREH OUSE table
w ere d eleted (see Clau se 4.2.2), the card inality of the WAREH OUSE table as initially configu red and the nu m ber of
row s d eleted m u st be d isclosed .
8.1.5.2
The d istribu tion of tables and logs across all m ed ia m u st be exp licitly d ep icted for the tested and
p riced system s.
Disk name: WDC01
For each disk WDC01 to WDC05
20% of each WAREHOUSE, DISTRICT, CUSTOMER,
NEW_ORDER, ORDER, ORDER-LINE, ITEM and STOCK
database tables and indexes
Disk name: WDC05
CPU
Disk name: HIST01
History 100%
Two additional v olumes were used
Operating sy stem root disk
Operating sy stem user disk
Disk name: LOG01
Phy sical log: 100%
Logical log: 100%
Disk name: LOG02
Logical log: 100%
(mirrored w/LOG01)
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 94 of 130
CPU
root
Operating
Sy stem
root
v olume
/usr
Operating
Sy stem
/user
f iles
db03
db08
db04
Sy stem
page1 page
v olume
hist
log
db01
HISTORY
f ile
100%
phy sical
log f ile
100%
db02
10% of
WAREHOUSE
CUSTOMER
DISTRICT
NEW_ORDER
ORDER
ORDER_LINE
tables
10%
10%
10%
db09
db05
db07
10%
10%
db10
db06
10%
10%
10%
10%
item
ITEM
STOCK
tables
100%
Comment: Detailed d iagram s for layou t of d atabase files on d isks can w id ely vary, and it is d ifficu lt to p rovid e exact
gu id eline su itable for all im p lem entations. The intent is to p rovid e su fficient d etail to allow ind ep end ent
reconstru ction of the test d atabase. The tw o figu res below are exam p les of d atabase layou t d escrip tions and are not
intend ed to d ep ict or im p ly any op tim al layou t for the TPC -C d atabase.
8.1.5.3
A statem ent m u st be p rovid ed that d escribes:
1. The d ata m od el im p lem ented by the DBMS u sed (e.g., relational, netw ork, hierarchical)
2. The d atabase interface (e.g., em bed d ed , call level) and access langu age (e.g., SQL, DL/ 1, COBOL read / w rite)
u sed to im p lem ent the TPC-C transactions. If m ore than one interface/ access langu age is u sed to im p lem ent
TPC-C, each interface/ access langu age m u st be d escribed and a list of w hich interface/ access langu age is
u sed w ith w hich transaction typ e m u st be d isclosed .
8.1.5.4
The m ap p ing of d atabase partitions/ rep lications m u st be exp licitly d escribed .
Comment: The intent is to p rovid e su fficient d etail ab ou t p artitioning and rep lication to allow ind ep end ent
reconstru ction of the test d atabase.
An d escrip tion of a d atabase p artitioning schem e is p resented below as an exam p le. The nom enclatu re of this
exam p le w as ou tlined u sing the CUSTOMER table (in Clau se 8.1.2.1), and has been extend ed to u se the ORDER and
ORDER_LIN E tables as w ell.
C_p art_1
C_ID
C_D_ID
C_W_ID
--------- p artition------C_p art_2
C_FIRST
O_p art_1
O_ID
O_D_ID
O_W_ID
O_C_ID
----------- p artition-------
OL_p art_1
OL_O_ID
OL_D_ID
OL_W_ID
OL_N UMBER
OL_I_ID
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 95 of 130
C_MIDDLE
C_LAST
C_STREET_1
C_STREET_2
C_CITY
C_STATE
C_ZIP
C_PH ON E
C_SIN CE
----------partition------C_p art_3
C_CREDIT
C_CREDIT_LIM
C_DISCOUN T
C_BALAN CE
C_YTD_PAYMEN T
C_PAYMEN T_CN T
C_DELIVERY_CN T
----------partition------C_p art_4
C_DATA
O_p art_2
O_EN TRY_D
O_OL_CN T
----------- p artition------O_p art_3
O_CARRIER_ID
O_ALL_LOCAL
C_part_1
O_part_1
OL_part_1
----------- p artition------OL_p art_2
OL_SUPPLY_W_ID
OL_DELIVERY_D
OL_QUAN TITY
OL_AMOUN T
----------- p artition------OL_p art_3
OL_DIST_IN FO
C_part_3
O_part_2
C_part_2
C_part_4
O_part_3
OL_part_3
OL_part_2
One WAREHOUSE Customer/Order/Order_line "cell"
8.1.5.5
Details of the 60-d ay sp ace com p u tations along w ith p roof that the d atabase is configu red to su stain 8
hou rs of grow th for the d ynam ic tables (Ord er, Ord er -Line, and H istory) m u st be d isclosed (see Clau se 4.2.3).
8.1.6
8.1.6.1
Performance Metrics and Response Time Related Items
Measu red tp m C m u st be rep orted .
8.1.6.2
N inetieth p ercentile, m axim u m an d average resp onse tim es m u st be rep orted for all transaction typ es
as w ell as for the Menu resp onse tim e.
8.1.6.3
The m inim u m , the average, and the m axim u m keying and think tim es m u st be rep orted for each
transaction typ e.
8.1.6.4
typ e.
Resp onse Tim e frequ ency d istribu tion cu rves (see Clau se 5.6.1) m u st be rep orted for each transaction
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 96 of 130
8.1.6.5
The p erform ance cu rve for resp onse tim es versu s throu ghp u t (see Clau se 5.6.2) m u st be rep orted for
the N ew -Ord er transaction .
8.1.6.6
transaction .
Think Tim e frequ ency d istribu tion cu rves (see Clau se 5.6.3) m u st be rep orted for the N ew -Ord er
8.1.6.7
There is no requ irem ent to rep ort Keying Tim e d istribu tion cu rves.
8.1.6.8
transaction .
A grap h of throu ghp u t versu s elap sed tim e (see Clau se 5.6.4) m u st be rep orted for the N ew -Ord er
8.1.6.9
The m ethod u sed to d eterm ine that the SUT had reached a stead y state p rior to com m encing the
m easu rem ent interval (see Clau se 5.5) m u st be d escribed .
8.1.6.10
A d escrip tion of how the w ork norm ally p erform ed d u ring a su stained test (for exam p le
checkp ointing, w riting red o/ u nd o log record s, etc.), actu ally occu rred d u ring the m easu rem ent interval m u st be
rep orted .
8.1.6.11
The start tim e and d u ration in second s of at least the fou r (4) longest checkp oints d u ring the
Measu rem ent Interval m u st be d isclosed (see Clau se 5.5.2.2 (2)).
8.1.6.12
A statem ent of the d u ration of the m easu rem ent interval for the rep orted Maxim u m Qu alified
Throu ghp u t (tp m C) m u st be inclu d ed .
8.1.6.13
The m ethod of regu lation of the transaction m ix (e.g., card d ecks or w eighted rand om d istribu tion)
m u st be d escribed . If w eighted d istribu tion is u sed and the RTE ad ju sts the w eights associated w ith each transaction
typ e, the m axim u m ad ju stm ents to the w eight from the initial valu e m u st be d isclosed .
8.1.6.14
The p ercentage of the total m ix for each transaction typ e m u st be d isclosed .
8.1.6.15
d isclosed .
The p ercentage of N ew -Ord er transaction s rolled back as a resu lt of invalid item nu m ber m u st be
8.1.6.16
The average nu m ber of ord er-lines entered p er N ew -Ord er transaction m u st be d isclosed .
8.1.6.17
The p ercentage of rem ote ord er-lines entered p er N ew -Ord er transaction m u st be d isclosed .
8.1.6.18
The p ercentage of rem ote Paym ent transaction s m u st be d isclosed .
8.1.6.19
The p ercentage of cu stom er selections by cu stom er last nam e in the Paym ent and Ord er-Statu s
transaction s m u st be d isclosed .
8.1.6.20
The p ercentage of Delivery transaction s skip p ed d u e to there being few er than necessary ord ers in the
N ew -Ord er table m u st be d isclosed .
8.1.6.21
The nu m ber of checkp oints in the Measu rem ent Interval, the tim e in second s from the start of the
Measu rem ent Interval to the first checkp oint and the Checkp oint Interval m u st be d isclosed .
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 97 of 130
8.1.7
SUT, D river, and Communication D efinition Related Items
8.1.7.1
The RTE inp u t p aram eters, cod e fragm ents, fu nctions, etc. u sed to generate each transaction inp u t
field m u st be d isclosed .
Comment: The intent is to d em onstrate the RTE w as configu red to generate transaction inp u t d ata as sp ecified in
Clau se 2.
8.1.7.2
The nu m ber of term inal connections lost d u ring the Measu rem ent Interval m u st be d isclosed (see
Clau se 6.6.2).
8.1.7.3
It m u st be d em onstrated that the fu nctionality and p erform ance of the com p onents being em u lated in
the Driver System are equ ivalent to that of the p riced system . Th e resu lts of the test d escribed in Clau se 6.6.3.4 m u st
be d isclosed .
8.1.7.4
A com p lete fu nctional d iagram of both the benchm ark configu ration and the configu ration of the
p rop osed (target) system m u st be d isclosed . A d etailed list of all softw are and har d w are fu nctionality bein g
p erform ed on the Driver System , and its interface to the SUT m u st be d isclosed (see Clau se 6.6.3.6).
8.1.7.5
The netw ork configu ration s of both the tested services and the p rop osed (targ et) services w hich are
being rep resented and a thorou gh exp lanation of exactly w hich p arts of the p rop osed configu ration are being
rep laced w ith the Driver System m u st be d isclosed (see Clau se 6.6.4).
8.1.7.6
The band w id th of the netw ork(s) u sed in the tested / p riced configu ration m u st be d isclosed .
8.1.7.7
If the configu ration requ ires op erator intervention (see Clau se 6.6.6), the m echanism and the frequ ency
of this intervention m u st be d isclosed .
8.1.8
Pricing Related Items
8.1.8.1
Ru les for rep orting p ricin g inform ation are inclu d ed in the cu rrent revision of the TPC Pricing
Sp ecification, located at w w w .tp c.org.
8.1.9
Audit Related Items
8.1.9.1
The au d itor‟ s nam e, ad d ress, p hone nu m ber, and a cop y of the au d itor's attestation letter ind icating
the au d itor‟ s op inion of com p liance m u st be inclu d ed in the Full Disclosu re Rep ort .
8.2
Availability of the Full D isclosure Report
The Full Disclosu re Rep ort m u st be read ily available to the p u blic at a reasonable charge, sim ilar to charges for
sim ilar d ocu m ents by that test sp onsor . The rep ort m u st be m ad e available w hen resu lts are m ad e p u blic. In ord er to
u se the p hrase "TPC Benchm ark™C", the Fu ll Disclosu re Rep ort m u st have been su bm itted to the TPC Ad m inistrator
as w ell as w ritten p erm ission obtained to d istribu te sam e.
8.3
Revisions to the Full D isclosure Report
8.3.1
In ad d ition to the requ irem ents for revising the Full Disclosu re Rep ort fou nd in the cu rrent revision of
the TPC Pricing Sp ecification , the follow ing com p onents in the p riced configu ration m ay be su bstitu ted if they are
no longer ord erable:
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 98 of 130

front-end system s

d isks, d isk enclosu res, external storage controllers

term inal servers

netw ork ad ap ters

rou ters, brid ges, rep eaters, sw itches

cables
8.3.2
Su bstitu tion of the Server or the H ost system , OS, DBMS or TP Monitor is not allow ed u nd er any
circu m stances.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 99 of 130
Clause 9: AUD IT
9.1
General Rules
9.1.1
An ind ep end ent au d it of the benchm ark resu lts by an au d itor certified by the TPC is requ ired . An
au d it checklist is p rovid ed as p art of this sp ecification. Please obtain the cu rrent au d it checklist from one of the
au d itors. The term "ind epend ent" is d efined as: "the ou tcom e of the benchm ark carries no financial benefit to the
au d iting agency other than fees earned d irectly related to the au d it." In ad d ition, the au d iting agency cannot have
su p p lied any p erform ance consu lting u nd er contract for the benchm ark u nd er aud it. The term "certified " is d efined
as: "the TPC has review ed the qu alification of the au d itor and certified t hat the au d itor is cap able of verifying
com p liance of the benchm ark resu lt." Please see the TPC Au d it Policy for a d etailed d escrip tion of the au d itor
certification p rocess.
In ad d ition, the follow ing cond itions m u st be m et:
1.
The au d iting agency cannot be financially related to the sp onsor. For exam p le, the au d iting agency is
financially related if it is a d ep end ent d ivision, the m ajority of its stock is ow ned by the sp onsor, etc.
2.
The au d iting agency cannot be financially related to any one of the su p p liers of the m easu red / p riced
com p onents, e.g., the DBMS su p p lier, the term inal or term inal concentrator su p p lier, etc.
9.1.2
The au d itor's attestation letter m u st be m ad e read ily available to the p u blic as p art of the Full
Disclosu re Rep ort, bu t a d etailed rep ort from the au d itor is not requ ired .
9.1.3
For the p u rp ose of the au d it, only transactions that are generated by the Driver System and the d ata
associated w ith those transactions shou ld b e u sed for the au d it tests, w ith the excep tion of the initial d atabase
p op u lation verification.
9.1.4
In the case of au d ited TPC-C resu lts w hich are u sed as a basis for new TPC-C resu lts, the sp onsor of
the new benchm ark can claim that the resu lts w ere au d ited if, and only if:
1.
The au d itor ensu res that the hard w are and softw are prod u cts are the sam e.
2.
The au d itor review s the Fu ll Disclosu re Rep ort (FDR) of the new resu lts and ensu res that they m atch w hat
is contained in the original sp onsor's FDR.
3.
The au d itor can attest to Clau ses 9.2.8.
The au d itor is not requ ired to follow any of the rem aining au d itor's check list item s from Clau se 9.2.
9.2
Auditor's check list
9.2.1 Clause 1 Logical D atabase D esign Related Items
9.2.1.1
Verify that sp ecified attribu tes (i.e., colu m ns) and row s exist, and that they conform to the
sp ecifications.
9.2.1.2
Verify that th e row id entifiers are not d isk or file offsets.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 100 of 130
9.2.1.3
Verify that all tables su p p ort retrievals, inserts and d eletes.
9.2.1.4
Verify the rand om ness of the inp u t d ata to the system u nd er test for all transact ions. Inclu d e
verification that the valu es generated are u niform across the entire set of row s in the configu red d atabase necessary
to su p p ort the claim ed tp m C rating p er Clau se 5.4.
9.2.1.5
Verify w hether any horizontal and / or vertical p artit ioning has been u sed , and , if so, w hether it w as
im p lem ented in accord ance w ith the TPC-C requ irem ents.
9.2.1.6
Verify w hether any rep lication of tables has been u sed , and , if so, w hether it w as im p lem ented in
accord ance w ith the TPC-C requ irem ents.
9.2.1.7
Verify that no m ore than 1%, or no m ore than one (1), w hichever is greater, of the Delivery
transaction s skip p ed becau se there w ere few er than necessary ord ers p resent in the N ew -Ord er table.
9.2.2 Clause 2 Transaction and Terminal Profiles Related Items
9.2.2.1
Verify that the ap p lication p rogram s m atch the resp ective transaction p rofiles.
9.2.2.2
Verify that the inp u t d ata satisfy the requ irem ents and that inp u t/ ou tp u t scree n layou ts are p reserved .
9.2.2.3
Verify com p liance w ith the error d etection and rep orting requ irem ent as sp ecified in clau se 2.3.6.
Comment: This m ay be verified by cod e insp ection at the d iscretion of the au d itor.
9.2.2.4
Verify that each N ew -Ord er transaction u ses ind ep end ently generated inp u t d ata and not d ata from
rolled back transactions.
9.2.2.5
Verify that the rand om ly generated inp u t d ata satisfies the follow ing constraints:
1.
At least 0.9% and at m ost 1.1% of the N ew -Ord er transaction s roll back as a resu lt of an u nu sed item
nu m ber. For these transactions the requ ired p rofile is execu ted , and the correct screen is d isp layed .
Furtherm ore, verify that the ap p lication m akes only p erm itted u se of the fact that the inp u t d ata contains
an u nu sed item nu m ber.
2.
The average nu m ber of ord er-lines p er ord er is in the range of 9.5 to 10.5 and the nu m ber of ord er -lines is
u niform ly d istribu ted from 5 to 15 for the N ew -Ord er transaction s that are su bm itted to the SUT d u ring
the m easu rem ent interval.
3.
The nu m ber of rem ote ord er-lines is at least 0.95% and at m ost 1.05% of the nu m ber of ord er -lines that are
filled in by the N ew -Ord er transaction s that are su bm itted to the SUT d u ring the m easu rem ent interval,
and the rem ote w arehou se nu m bers are u niform ly d istribu ted w ithin the range of active w arehou ses (see
Clau se 4.2.2).
4.
The nu m ber of rem ote Paym ent transaction s is at least 14% and at m ost 16% of the nu m ber of Paym ent
transactions that are su bm itted to the SUT d u ring the m easu rem ent interval, and the rem ote w arehou se
nu m bers are u niform ly d istribu ted w ithin the range of active w arehou ses (see Clau se 4.2.2).
5.
The nu m ber of cu stom er selections by cu stom er last nam e in the Paym ent transaction is at least 57% and at
m ost 63% of the nu m ber of Paym ent transactions that are su bm itted to the SUT d u ring the m easu rem ent
interval.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 101 of 130
6.
The nu m ber of cu stom er selections by cu stom er last nam e in the Ord er-Statu s transaction is at least 57%
and at m ost 63% of the n u m ber of Ord er -Statu s transactions that are su bm itted to the SUT d u ring the
m easu rem ent interval.
9.2.2.6
Verify that resu lts from execu ting the Delivery transaction in d eferred m od e are record ed into a resu lt
file. Verify that the resu lt file is m aintained on the p rop er typ e of d u rable m ed iu m . Furtherm ore, verify that no
action is record ed into the resu lt file u ntil after the action has been com p leted .
9.2.2.7
transaction.
Verify that all inp u t and ou tp u t field s that m ay change on screens are clear ed at the beginning of each
9.2.2.8
Using one of the configu red term inals, verify that the inp u t/ ou tp u t screen for each transaction typ es
p rovid es all the featu res d escribed in Clau se 2.2.2.4.
9.2.2.9
The au d itor can fu rther verify the com p liance of the inp u t d ata by qu erying the follow ing attribu tes:
• O_ALL_LOCAL can be u sed to verify that ap p roxim ately 10% of all ord ers contain at least one rem ote ord er line.
• C_PAYMEN T_CN T can be u sed to verify that w ithin the Paym ent tran saction cu stom ers w ere selected
accord ing to the requ ired non -u niform rand om d istribu tion.
• S_YTD can be u sed to verify that w ithin the N ew -Ord er transaction the qu antity ord ered for each item w as
w ithin the requ ired range.
• S_ORDER_CN T can be u sed to verify that w ithin the N ew -Ord er transaction item s w ere selected accord ing to
the requ ired non-u niform rand om d istribu tion.
• S_REMOTE_CN T can be u sed to verify that w ithin the N ew -Ord er transaction rem ote ord er-lines w ere
selected accord ing to the requ ired u niform rand om d istribu tion.
9.2.3
9.2.3.1
9.2.4
9.2.4.1
Clause 3 Transactions and System Properties Related Items
Verify that the requ irem ents of each of the ACID tests w ere m et.
Clause 4 Scaling and D atabase Population Related Items
Verify that the d atabase is initially p op u lated w ith the p rop erly scaled requ ired p op u lation.
9.2.4.2
Verify the correct card inalities of the nine d atabase tables, at the start of the benchm ark ru n as w ell as
at the end of it, and that the grow th in the N ew -Ord er table, in p articu lar, is consistent w ith the nu m ber and typ e of
execu ted transactions.
9.2.6
Clause 5 Performance Metrics and Response Time Related Items
9.2.6.1
m ix.
Verify that the m ix of transactions as seen by the SUT satisfies the requ ired m inim u m p ercentage of
9.2.6.2
Verify the valid ity of the m ethod u sed to m easu re the resp onse tim e at the RTE.
9.2.6.3
If p art of the SUT is em u lated , verify that the rep orted resp onse tim e is no less than the resp onse tim e
that w ou ld be seen by a real term inal u ser.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 102 of 130
9.2.6.4
Verify the m ethod u sed to d eterm ine that the SUT had reached a stead y state p rior to com m encing the
m easu rem ent interval (see Clau se 5.5).
9.2.6.5
Verify that all w ork norm ally d one in a stead y state environm ent actu ally occu rred d u ring the
m easu rem ent interval, for exam p le checkp ointing, w riting red o/ u nd o log record s to d isk, etc.
9.2.6.6
Verify the d u ration of the m easu rem ent interval for the rep orted tp m C.
9.2.6.7
Verify that the resp onse tim es have been m easu red in the sam e tim e interval as the test.
9.2.6.8
Verify that th e requ ired Keying and Think Tim es for the em u lated u sers occu r in accord ance w ith th e
requ irem ents.
9.2.6.9
Verify that the 90th p ercentile resp onse tim e for each transaction typ e is greater than or equ al to the
average resp onse tim e of that transaction typ e.
9.2.6.10
If the RTE ad ju sts the w eights associated to each transaction typ e, verify that these ad ju stm ents have
been lim ited to keep the w eights w ithin 5% on either sid e of their resp ective initial valu e.
9.2.6.11
If the RTE u ses card d ecks (see Clau se 5.2.4.2) verify that they m eet the requ irem ents.
9.2.6.12
If p eriod ic checkp oints are u sed , verify that they are p rop erly sched u led and execu t ed d u ring the
m easu rem ent interval.
9.2.6.13
Verify that the average think tim e for each transaction typ e is equ al to or greater than the m inim um
sp ecified in Clau se 5.2.5.7
9.2.7
Clause 6 SUT, D river, and Communications D efinition Related Items
9.2.7.1
Describe the m ethod u sed to verify the accu rate em u lation of the tested term inal p op u lation by the
Driver System if one w as u sed .
9.2.7.2
Verify term inal connectivity an d context m aintenance as requ ired in Clau se 6.6.2.
9.2.7.3
Verify that the restrictions on op erator intervention are m et.
9.2.8
Clause 7 Pricing Related Items
9.2.8.1
Ru les for verification of p ricing related item s are inclu d ed in the cu rr ent revision of the TPC Pricing
Sp ecification, located at w w w .tp c.org.
9.2.9
TPC-Energy Related Items
9.2.9.1
When the op tional TPC-Energy stand ard is u sed , the ad d itional au d it requ irem ents m u st be follo w ed .
In ad d ition, the requ irem ents of the TPC-Energy Sp ecification, located at w w w .tp c.org, m u st be m et.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 103 of 130
9.2.10
Full D isclosure Related Items
9.2.10.1
Verify that the enabled num bers of p rocessors, cor es and thread s rep orted by the test sp onsor are
consistent w ith those rep orted by the op erating system and that any p rocessors, cores or thread s that existed on the
SUT, bu t are claim ed as d isabled , d o not contribu te to the p erform ance of the benchm ark.
9.2.10.2
Any DBMS artifact, u tilized in a TPC-C ap p lication, requ ires p u blic d ocu m entation or a letter from the
DBMS vend or to the au d itor, d escribing the behavior and ongoing su p p ort of the sam e behavior.
Comment: For exam p le, a DBMS artifact is the selection of row s in the ord er of the p rim ary ind ex even thou gh there
is no ORDER BY clau se in the cu rsor d efinition.
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 104 of 130
Index
5
5-year pricing 83, 85
9
90th percentile response tim e 70, 74, 79, 99
A
ACID 6, 20, 37, 40, 44, 46, 54, 72, 78, 84, 90, 98
Ad d ing 18
Application 6, 7, 9, 17, 18, 19, 20, 21, 23, 25, 26, 27, 30, 47, 51,
82, 83, 85, 86, 87, 97
Arbitrary 19, 50, 51
Atom icity 46
Attributes 17
Aud itor's check list 96
Data m anipulation 19, 25, 29, 90
Database transaction 20, 23, 25, 27, 28, 29, 33, 34, 36, 37, 39,
40, 41, 42, 43, 44, 46, 47, 50, 53
Deck 69, 94, 99
Deletes 18, 50, 96
Deleting 18
Delivery transaction 39, 41, 50, 53, 54, 67, 68, 70, 71, 73, 80,
90, 94, 97, 98, 109
Dirty read 50
Dirty w rite 50
District 12, 28, 33, 43, 46, 47, 48, 58, 60, 64, 65
Driver 58, 78, 79, 80, 81, 83, 94, 96, 99
Durability 46, 56, 57
Durable 56
Dynam ic-space 61
E
Em ulated users 67
Executive sum m ary 125
F
B
Bound aries 17
Business transaction 20, 24, 25, 27, 32, 36, 39, 40, 41, 43, 44,
53, 67, 68, 71
Free-space 61
Front-end system s 78, 95
Full Disclosure Report ∑7, 22, 46, 80, 81, 82, 86, 95, 96, 127
H
C
C_LAST 13, 20, 28, 30, 31, 32, 33, 34, 35, 36, 37, 38, 62, 65, 89,
90, 92
Card inality 10, 18, 59, 60, 66, 90
Checkpoint 58, 73, 86, 93, 94, 99, 127
Checkpoint interval 73, 94
Com m ercially available 6, 19, 21, 25, 26, 79, 82, 84, 90
Com m it 47, 50, 51, 52, 53, 54, 55, 104, 106, 108, 109, 111, 114,
115, 116, 118, 119, 120, 122
Com m itted 18, 24, 29, 31, 34, 37, 40, 42, 44, 50, 56, 57, 58, 67,
84
Concentration 81
Consistency 46, 47, 48, 49, 58, 87
Context 9, 14, 26, 47, 54, 80, 81
Custom er 13, 25, 28, 33, 36, 37, 42, 46, 47, 49, 60, 65, 89, 92
H ard w are 7, 17, 19, 25, 58, 78, 79, 81, 82, 94, 96
H ashing 18
H orizontal partitioning 17
I
Inserts 18, 88, 96, 119
Integrity 18
Isolation 46, 50, 51, 52, 53, 54, 55, 90
K
Keying tim e 68, 69, 70
D
L
Daily-grow th 61
Daily-spread 61
LAN 11, 13, 33, 35, 36, 37, 38, 42, 49, 53, 65, 87, 88, 89, 92
Last nam e 20, 22, 28, 32, 33, 35, 36, 37, 38, 62, 73, 94, 97, 123
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 105 of 130
Load balancing 25
Locking 6, 51, 87
Logical database d esign 88, 96
M
Measurem ent interval 10, 27, 32, 36, 39, 40, 46, 49, 58, 61, 67,
68, 69, 71, 72, 73, 74, 75, 84, 86, 93, 94, 97, 98, 99, 127
Mem ory 40, 56, 57, 84, 87, 88, 95
Menu 22, 67, 68
Mirroring 56, 57
Mix I, 3, 6, 7, 47, 68, 69, 70, 71, 72, 74, 78, 84, 86, 88, 90, 94, 98
Mod ifying 18
Multiplexing 25, 79, 80
R
Rand om 20, 27, 32, 36, 39, 43, 46, 47, 49, 53, 54, 60, 62, 63, 64,
65, 66, 68, 69, 84, 90, 94, 97, 98, 123
Rand om ly 20, 27, 32, 36, 39, 46, 47, 49, 54, 65, 69, 84, 97
Recovery 25, 84, 87
Rem ote ord er-lines 72, 90, 94, 97, 98
Rem ote p aym ent transaction 72, 90, 94, 97
Replicated table 17, 54
Replication 17, 89
Response tim e 67
Response tim e constraints 69
Rollback 47, 50, 104, 123
Roll-forw ard 58, 84
Routers 87, 88, 95
RTE 20, 23, 57, 69, 70, 71, 72, 77, 78, 79, 80, 81, 94, 98, 99
N
N etw ork configuration 81
N ew -Ord er 14, 28, 41, 47, 48, 49, 54, 55, 59, 60, 66, 84, 90
N ew -Ord er transaction 25, 27, 29, 31, 50, 51, 52, 53, 54, 55,
58, 66, 67, 68, 69, 70, 71, 72, 74, 75, 90, 93, 94, 97, 98, 103
N inetieth percentile 93
N on-repeatable read 50
N on-uniform 20, 27, 32, 36, 65, 98, 123
N on-volatile 56
N URand 20, 27, 32, 36, 65, 112, 120
S
Scaling 59, 90, 98
Space 10, 18, 22, 23, 30, 34, 37, 40, 44, 59, 60, 61, 66, 72, 84, 93
Static-space 61
Stock-Level transaction 43, 45, 46, 50, 51, 67, 68, 111
Storage 18, 56, 59, 60, 61, 66, 78, 83, 84, 90
SUT 20, 23, 25, 27, 28, 32, 33, 36, 39, 40, 43, 46, 49, 58, 59, 67,
68, 70, 71, 72, 73, 77, 78, 79, 80, 81, 82, 83, 85, 88, 90, 93, 94,
95, 97, 98, 99
O
T
Operating system 17, 19, 42, 46, 57, 65, 66
Ord er 14, 15, 16, 28, 29, 37, 41, 42, 43, 47, 48, 49, 54, 55, 58, 59,
60, 61, 64, 66, 84, 90, 92, 98, 103, 105, 107, 109
Ord er-Line 29, 48, 49, 59, 60, 61, 84
Ord er-Status transaction 36, 38, 50, 51, 52, 55, 68, 73, 90, 94,
97, 107
Over-scaling 60
Term inal 6, 20, 21, 22, 23, 25, 27, 29, 30, 31, 32, 34, 35, 36, 37,
38, 39, 40, 41, 43, 44, 45, 57, 58, 59, 60, 68, 69, 70, 71, 74, 78,
79, 80, 81, 83, 84, 86, 87, 90, 95, 96, 98, 99, 103
Test sponsor 22, 25, 41, 46, 51, 54, 58, 67, 68, 72, 80, 81, 95
Think tim e 68, 70, 74, 75, 93, 99, 127
Throughput 6, 54, 59, 60, 61, 67, 68, 70, 71, 72, 73, 74, 75, 79,
82, 85, 93
Tim estam p 25, 70, 71, 103, 105, 109, 112, 113, 120, 121, 122
TPC Aud itor 58
TPC-C transactions 46, 47, 51, 58, 92, 103
tpm C 3, 6, 49, 58, 59, 61, 71, 72, 75, 78, 81, 83, 84, 85, 86, 93,
94, 97, 99, 127
Transaction m ix 7, 68, 69, 70, 71, 72, 74, 78, 84, 86, 88, 94, 127
Transaction m onitors 25, 26, 87
Transaction profiles 17, 21, 25, 56, 59, 97
Transaction RT 25, 68, 69, 71
Transparency 18, 26
P
Pacing 67
Partitioned d ata 18, 19, 89
Paym ent transaction 32, 33, 35, 46, 47, 50, 53, 68, 72, 73, 90,
94, 97, 98, 105
Perform ance m etrics 67, 93, 98
Phantom 50
Pow er supply 78
Precision 11, 18, 20, 62, 85
Priced configuration 83
Pricing 83, 84, 99
Prim ary key 14, 18, 32, 36, 90
U
Uninterruptible Pow er Supply 56, 57, 85
Unique 10, 11, 12, 13, 14, 15, 16, 18, 20, 29, 32, 36, 43, 62, 63,
64, 65, 66, 87
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 106 of 130
V
W
Vertical partitioning 17
Warehouse 11, 28, 33, 46, 47, 48, 59, 60, 63, 64, 90
Workstations 78, 80, 87, 88
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 107 of 130
Appendix A: SAMPLE PROGRAMS
The follow ing are exam p les of the TPC-C transactions and d atabase load p rogram in SQL em bed d ed in C. Only the
basic fu nctionality of the TPC-C transactions is su p p lied . All term inal I/ O Oop erations, and m iscellaneou s fu nctions
have been left ou t of these exam p les. The cod e p resented here is for d em onstration p u rp oses only, and is n ot m eant
to be an op tim al im p lem entation.
N ote: The exam p les in this ap p end ix, in som e areas, m ay not follow all the requ irem ents of the benchm ark. In case of
d iscrep ancy betw een the sp ecifications and the p rogram m ing exam p les, the sp ecifications p revail.
A.1
The N ew -Order Transaction
int new ord ()
{
EXEC SQL WH EN EVER NOT FOUN D GOTO sqlerr;
EXEC SQL WH EN EVER SQLERROR GOTO sqlerr;
gettim estam p (d atetim e);
EXEC SQL SELECT c_d iscount, c_last, c_cred it, w _tax
IN TO :c_d iscount, :c_last, :c_credit, :w _tax
FROM custom er, w arehouse
WH ERE w _id = :w _id AN D c_w _id = w _id AN D
c_d_id = :d _id AN D c_id = :c_id ;
EXEC SQL SELECT d _next_o_id , d _tax IN TO :d _next_o_id , :d_tax
FROM d istrict
WH ERE d _id = :d_id AN D d _w _id = :w _id ;
EXEC SQL UPDATE d istrict SET d _next_o_id = :d _next_o_id + 1
WH ERE d _id = :d_id AN D d _w _id = :w _id ;
o_id =d _next_o_id ;
EXEC SQL IN SERT IN TO ORDERS (o_id , o_d _id , o_w _id , o_c_id ,
o_entry_d , o_ol_cnt, o_all_local)
VALUES (:o_id , :d _id , :w _id , :c_id ,
:d atetim e, :o_ol_cnt, :o_all_local);
EXEC SQL IN SERT IN TO N EW_ORDER (no_o_id , no_d_id , no_w _id )
VALUES (:o_id , :d _id , :w _id );
for (ol_num ber=1; ol_num ber<=o_ol_cnt; ol_num ber++)
{
ol_supply_w _id =atol(supw are[ol_num ber -1]);
if (ol_supply_w _id != w _id) o_all_local=0;
ol_i_id =atol(item id [ol_num ber-1]);
ol_qu antity=atol(qty[ol_num ber-1]);
EXEC SQL WH EN EVER N OT FOUN D GOTO invalid item ;
EXEC SQL SELECT i_price, i_nam e , i_data
IN TO :i_price, :i_nam e, :i_data
FROM item
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 108 of 130
WH ERE i_id = :ol_i_id ;
price[ol_num ber-1] = i_price;
strncpy(inam e[ol_num ber-1],i_nam e,24);
EXEC SQL WH EN EVER N OT FOUN D GOTO sqlerr;
EXEC SQL SELECT s_quantity, s_d ata,
s_d ist_01, s_dist_02, s_d ist_03, s_d ist_04, s_d ist_05
s_d ist_06, s_dist_07, s_d ist_08, s_d ist_09, s_d ist_10
IN TO :s_quantity, :s_d ata,
:s_d ist_01, :s_d ist_02, :s_dist_03, :s_d ist_04, :s_d ist_05
:s_d ist_06, :s_d ist_07, :s_dist_08, :s_d ist_09, :s_d ist_10
FROM stock
WH ERE s_i_id = :ol_i_id AN D s_w _id = :ol_supply_w _id ;
pick_d ist_info(ol_d ist_info, ol_w _id ); / / pick correct s_dist_xx
stock[ol_num ber-1] = s_quantity;
if ( (strstr(i_data,"original") != N ULL) &&
(strstr(s_d ata,"original") != N ULL) )
bg[ol_num ber-1] = 'B';
else
bg[ol_num ber-1] = 'G';
if (s_quantity > ol_quantity)
s_quantity = s_quantity - ol_quantity;
else
s_quantity = s_quantity - ol_quantity + 91;
EXEC SQL UPDATE stock SET s_quantity = :s_quantity
WH ERE s_i_id = :ol_i_id
AN D s_w _id = :ol_supply_w _id ;
ol_am ount = ol_quantity * i_price * (1+w _tax+d_tax) * (1-c_d iscount);
am t[ol_num ber-1]=ol_am ount;
total += ol_am ount;
EXEC SQL IN SERT
IN TO ord er_line (ol_o_id , ol_d_id , ol_w _id , ol_num ber,
ol_i_id , ol_supply_w _id ,
ol_quantity, ol_am ount, ol_dist_info)
VALUES (:o_id , :d_id , :w _id , :ol_num ber,
:ol_i_id , :ol_supply_w _id ,
:ol_quantity, :ol_am ount, :ol_d ist_info);
} / *End Ord er Lines*/
EXEC SQL COMMIT WORK;
return(0);
invalid item :
EXEC SQL ROLLBACK WORK;
printf("Item num ber is not valid ");
return(0);
sqlerr:
error();
}
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 109 of 130
A.2
The Payment Transaction
int paym ent()
{
EXEC SQL WH EN EVER NOT FOUN D GOTO sqlerr;
EXEC SQL WH EN EVER SQLERROR GOTO sqlerr;
gettim estam p (d atetim e);
EXEC SQL UPDATE w arehouse SET w _ytd = w _ytd + :h_am ount
WH ERE w _id =:w _id ;
EXEC SQL SELECT w _street_1, w _street_2, w _city, w _state, w _zip, w _nam e
IN TO :w _street_1, :w _street_2, :w _city, :w _state, :w _zip, :w _nam e
FROM w arehouse
WH ERE w _id =:w _id ;
EXEC SQL UPDATE d istrict SET d _ytd = d_ytd + :h_am ount
WH ERE d _w _id =:w _id AN D d _id =:d _id ;
EXEC SQL SELECT d _street_1, d _street_2, d_city, d_state, d _zip, d _nam e
IN TO :d _street_1, :d _street_2, :d _city, :d _state, :d _zip , :d _nam e
FROM d istrict
WH ERE d _w _id =:w _id AN D d _id =:d _id ;
if (bynam e)
{
EXEC SQL SELECT count(c_id ) IN TO :nam ecnt
FROM custom er
WH ERE c_last=:c_last AN D c_d _id =:c_d _id AN D c_w _id =:c_w _id ;
EXEC SQL DECLARE c_bynam e CURSOR FOR
SELECT c_first, c_m idd le, c_id,
c_street_1, c_street_2, c_city, c_state, c_zip,
c_phone, c_cred it, c_cred it_lim ,
c_d iscount, c_balance, c_since
FROM custom er
WH ERE c_w _id =:c_w _id AN D c_d _id =:c_d _id AN D c_last=:c_last
ORDER BY c_first;
EXEC SQL OPEN c_byname;
if (nam ecnt%2) nam ecnt++; / / Locate m id point custom er;
for (n=0; n<nam ecnt/ 2; n++)
{
EXEC SQL FETCH c_bynam e
IN TO :c_first, :c_m id dle, :c_id,
:c_street_1, :c_street_2, :c_city, :c_state, :c_zip,
:c_phone, :c_cred it, :c_cred it_lim ,
:c_discount, :c_balance, :c_since;
}
EXEC SQL CLOSE c_bynam e;
}
else
{
EXEC SQL SELECT c_first, c_m id d le, c_last,
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 110 of 130
c_street_1, c_street_2, c_city, c_state, c_zip,
c_phone, c_cred it, c_cred it_lim ,
c_d iscount, c_balance, c_since
IN TO :c_first, :c_m id dle, :c_last,
:c_street_1, :c_street_2, :c_city, :c_state, :c_zip,
:c_phone, :c_cred it, :c_cred it_lim ,
:c_discount, :c_balance, :c_since
FROM custom er
WH ERE c_w _id =:c_w _id AN D c_d _id =:c_d _id AN D c_id =:c_id ;
}
c_balance += h_am ount;
c_credit[2]='\ 0';
if (strstr(c_cred it, "BC") )
{
EXEC SQL SELECT c_data IN TO :c_d ata
FROM custom er
WH ERE c_w _id =:c_w _id AN D c_d _id =:c_d _id AN D c_id =:c_id ;
sprintf(c_new _d ata,"| %4d %2d %4d %2d %4d $%7.2f %12c %24c",
c_id ,c_d_id ,c_w _id ,d_id ,w _id ,h_am ount
h_date, h_d ata);
strncat(c_new _data,c_data,500-strlen(c_new _d ata));
EXEC SQL UPDATE custom er
SET c_balance = :c_balance, c_d ata = :c_new _data
WH ERE c_w _id = :c_w _id AN D c_d _id = :c_d _id AN D
c_id = :c_id;
}
else
{
EXEC SQL UPDATE custom er SET c_balance = :c_balance
WH ERE c_w _id = :c_w _id AN D c_d _id = :c_d _id AN D
c_id = :c_id;
}
strncpy(h_data,w _nam e,10);
h_d ata[10]='\ 0';
strncat(h_data,d _nam e,10);
h_d ata[20]=' ';
h_d ata[21]=' ';
h_d ata[22]=' ';
h_d ata[23]=' ';
EXEC SQL IN SERT IN TO history (h_c_d _id , h_c_w _id, h_c_id , h_d _id ,
h_w _id , h_d ate, h_am ount, h_d ata)
VALUES (:c_d _id, :c_w _id, :c_id , :d_id ,
:w _id , :d atetim e, :h_am ount, :h_data);
EXEC SQL COMMIT WORK;
return(0);
sqlerr:
error();
}
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 111 of 130
A.3
The Order-Status Transaction
int ostat()
{
EXEC SQL WH EN EVER NOT FOUN D GOTO sqlerr;
EXEC SQL WH EN EVER SQLERROR GOTO sqlerr;
if (bynam e)
{
EXEC SQL SELECT count(c_id ) IN TO :nam ecnt
FROM custom er
WH ERE c_last=:c_last AN D c_d _id =:d _id AN D c_w _id =:w _id;
EXEC SQL DECLARE c_nam e CURSOR FOR
SELECT c_balance, c_first, c_m id d le, c_id
FROM custom er
WH ERE c_last=:c_last AN D c_d _id =:d _id AN D c_w _id =:w _id
ORDER BY c_first;
EXEC SQL OPEN c_nam e;
if (nam ecnt%2) nam ecnt++; / / Locate m id point custom er
for (n=0; n<nam ecnt/ 2; n++)
{
EXEC SQL FETCH c_name
IN TO :c_balance, :c_first, :c_m id dle, :c_id ;
}
EXEC SQL CLOSE c_nam e;
}
else {
EXEC SQL SELECT c_balance, c_first, c_m id d le, c_last
IN TO :c_balance, :c_first, :c_m id dle, :c_last
FROM custom er
WH ERE c_id =:c_id AN D c_d _id =:d _id AN D c_w _id =:w _id;
}
EXEC SQL SELECT o_id, o_carrier_id, o_entry_d
IN TO :o_id , :o_carrier_id , :entdate
FROM ord ers
ORDER BY o_id DESC;
EXEC SQL DECLARE c_line CURSOR FOR
SELECT ol_i_id , ol_supply_w _id , ol_quantity,
ol_am ount, ol_d elivery_d
FROM ord er_line
WH ERE ol_o_id =:o_id AN D ol_d _id =:d _id AN D ol_w _id =:w _id ;
EXEC SQL OPEN c_line;
EXEC SQL WH EN EVER NOT FOUN D CON TIN UE;
i=0;
w hile (sql_notfound (FALSE))
{
i++;
EXEC SQL FETCH c_line
IN TO :ol_i_id [i], :ol_supply_w _id [i], :ol_quantity[i],
:ol_am ount[i], :ol_d elivery_d [i];
}
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 112 of 130
EXEC SQL CLOSE c_line;
EXEC SQL COMMIT WORK;
return(0);
sqlerr:
error();
}
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 113 of 130
A.4
The D elivery Transaction
int d elivery()
{
EXEC SQL WH EN EVER SQLERROR GOTO sqlerr;
gettim estam p (d atetim e);
/ * For each district in w arehouse */
printf("W: %d \ n", w _id );
for (d _id =1; d_id <=DIST_PER_WARE; d _id ++)
{
EXEC SQL WH EN EVER N OT FOUN D GOTO sqlerr;
EXEC SQL DECLARE c_no CURSOR FOR
SELECT no_o_id
FROM new _ord er
WH ERE no_d_id = :d _id AN D no_w _id = :w _id
ORDER BY no_o_id ASC;
EXEC SQL OPEN c_no;
EXEC SQL WH EN EVER N OT FOUN D continue;
EXEC SQL FETCH c_no IN TO :no_o_id ;
EXEC SQL DELETE FROM new _ord er WH ERE CURREN T OF c_no;
EXEC SQL CLOSE c_no;
EXEC SQL SELECT o_c_id IN TO :c_id FROM ord ers
WH ERE o_id = :no_o_id AN D o_d_id = :d _id AN D
o_w _id = :w _id ;
EXEC SQL UPDATE ord ers SET o_carrier_id = :o_carrier_id
WH ERE o_id = :no_o_id AN D o_d_id = :d _id AN D
o_w _id = :w _id ;
EXEC SQL UPDATE ord er_line SET ol_d elivery_d = :datetim e
WH ERE ol_o_id = :no_o_id AN D ol_d_id = :d _id AN D
ol_w _id = :w _id;
EXEC SQL SELECT SUM(ol_am ount) IN TO :ol_total
FROM ord er_line
WH ERE ol_o_id = :no_o_id AN D ol_d_id = :d _id
AN D ol_w _id = :w _id;
EXEC SQL UPDATE custom er SET c_balance = c_balance + :ol_total
WH ERE c_id = :c_id AN D c_d _id = :d_id AN D
c_w _id = :w _id ;
EXEC SQL COMMIT WORK;
printf("D: %d , O: %d , tim e: %d \ n", d_id , o_id , tad );
}
EXEC SQL COMMIT WORK;
return(0);
sqlerr:
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 114 of 130
error();
}
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 115 of 130
A.5
The Stock-Level Transaction
int slev()
{
EXEC SQL WH EN EVER NOT FOUN D GOTO sqlerr;
EXEC SQL WH EN EVER SQLERROR GOTO sqlerr;
EXEC SQL SELECT d _next_o_id IN TO :o_id
FROM d istrict
WH ERE d _w _id =:w _id AN D d _id =:d _id ;
EXEC SQL SELECT COUNT(DISTIN CT (s_i_id )) IN TO :stock_count
FROM ord er_line, stock
WH ERE ol_w _id =:w _id AN D
ol_d _id =:d _id AN D ol_o_id <:o_id AN D
ol_o_id >=:o_id -20 AN D s_w _id =:w _id AN D
s_i_id =ol_i_id AND s_quantity < :threshold;
EXEC SQL COMMIT WORK;
return(0);
sqlerr:
error();
}
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 116 of 130
A.6
Sample Load Program
/ *==================================================================+
| Load TPCC tables
+==================================================================*/
#d efine MAXITEMS 100000
#d efine CUST_PER_DIST 3000
#d efine DIST_PER_WARE 10
#d efine ORD_PER_DIST 3000
extern long count_w are;
/ * Functions */
long
void
void
void
void
void
void
void
void
void
void
void
void
void
N URand ();
Load Item s();
Load Ware();
Load Cust();
Load Ord ();
Load N ew Ord ();
Stock();
District();
Custom er();
Ord ers();
N ew _Ord ers();
MakeAd d ress();
Error();
Lastnam e();
/ * Global SQL Variables */
EXEC SQL BEGIN DECLARE SECTION ;
char
tim estam p [20];
long
count_w are;
EXEC SQL EN D DECLARE SECTION ;
/ * Global Variables */
int
i;
int
option_d ebug = 0;
/ * 1 if generating debug output
*/
/ *================================================= =================+
|
main()
| ARGUMEN TS
|
Warehouses n [Debug] [H elp]
+==================================================================*/
void m ain( argc, argv )
int
argc;
char *
argv[];
{
char
arg[2];
EXEC SQL WH EN EVER SQLERROR GOTO Error_SqlCall;
count_w are=0;
for (i=1; i<argc; i++)
{
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 117 of 130
strncpy(arg,argv[i],2);
arg[0] = toupper(arg[0]);
sw itch (arg[0]) {
case 'W': / * Warehouses */
if (count_w are)
{
printf("Error - Warehouses specified m ore than once.\ n");
exit(-1);
}
if (argc-1>i)
{
i++;
count_w are=atoi(argv[i]);
if (count_w are<=0)
{
printf("Invalid Warehouse Count.\ n");
exit(-1);
}
}
else
{
printf("Error - Warehouse count m ust follow Warehouse keyw ord \ n");
exit(-1);
}
break;
/ ******* Generic Args *********************/
case 'D': / * Debug Option */
if (option_d ebug)
{
printf("Error - Debug option specified m ore than once\ n");
exit(-1);
}
option_d ebug=1;
break;
case 'H ': / * List Args */
printf("Usage - Warehouses n [Debug] [H elp]\ n");
exit(0);
break;
d efault : printf("Error - Unknow n Argum ent (%s)\ n",arg);
printf("Usage - Warehouses n [Debug] [H elp]\ n");
exit(-1);
}
}
if (!(count_w are)) {
printf("N ot enough argum ents.\ n");
printf("Usage - Warehouses n ");
printf(" [Debug] [H elp]\ n");
exit(-1);
}
SetSeed ( tim e( 0 ) );
/ * Initialize tim estam p (for d ate colum ns) */
gettim estam p (tim estam p);
printf( "TPCC Data Load Started ...\ n" );
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 118 of 130
Load Item s();
Load Ware();
Load Cust();
Load Ord ();
EXEC SQL COMMIT WORK RELEASE;
printf( "\ n...DATA LOADIN G COMPLETED SUCCESSFULLY.\ n" );
exit( 0 );
Error_SqlCall:
Error();
}
/ *==================================================================+
| ROUTIN E N AME
|
Load Item s
| DESCRIPTION
|
Load s the Item table
| ARGUMEN TS
|
none
+==================================================================*/
void Load Item s()
{
EXEC SQL BEGIN DECLARE SECTION ;
long i_id ;
char i_nam e[24];
float i_price;
char i_d ata[50];
EXEC SQL EN D DECLARE SECTION ;
int idatasiz;
int orig[MAXITEMS];
long pos;
int i;
EXEC SQL WH EN EVER SQLERROR GOTO sqlerr;
printf("Load ing Item \ n");
for (i=0; i<MAXITEMS/ 10; i++) orig[i]=0;
for (i=0; i<MAXITEMS/ 10; i++)
{
do
{
pos = Rand om N um ber(0L,MAXITEMS);
} w hile (orig[pos]);
orig[pos] = 1;
}
for (i_id =1; i_id <=MAXITEMS; i_id ++) {
/ * Generate Item Data */
MakeAlphaString( 14, 24, i_nam e);
i_price=((float) Rand om N um ber(100L,10000L))/ 100.0;
id atasiz=MakeAlphaString(26,50,i_data);
if (orig[i_id ])
{
pos = Rand om N um ber(0L,id atasiz-8);
i_d ata[pos]='o';
i_d ata[pos+1]='r';
i_d ata[pos+2]='i';
i_d ata[pos+3]='g';
i_d ata[pos+4]='i';
i_d ata[pos+5]='n';
i_d ata[pos+6]='a';
i_d ata[pos+7]='l';
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 119 of 130
}
if ( option_d ebug )
printf( "IID = %ld , N am e= %16s, Price = %5.2f\ n",
i_id , i_nam e, i_price );
EXEC SQL IN SERT IN TO
item (i_id , i_nam e, i_price, i_data)
values (:i_id , :i_nam e, :i_price, :i_d ata);
if ( !(i_id % 100) ) {
printf(".");
EXEC SQL COMMIT WORK;
if ( !(i_id % 5000) ) printf(" %ld \ n",i_id );
}
}
EXEC SQL COMMIT WORK;
printf("Item Done. \ n");
return;
sqlerr:
Error();
}
/ *==================================================================+
| ROUTIN E N AME
|
Load Ware
| DESCRIPTION
|
Load s the Warehouse table
|
Load s Stock, District as Warehouses are created
| ARGUMEN TS
|
none
+================================================================== */
void Load Ware()
{
EXEC SQL BEGIN DECLARE SECTION ;
long w _id ;
char w _nam e[10];
char w _street_1[20];
char w _street_2[20];
char w _city[20];
char w _state[2];
char w _zip[9];
float w _tax;
float w _ytd ;
EXEC SQL EN D DECLARE SECTION ;
EXEC SQL WH EN EVER SQLERROR GOTO sqlerr;
printf("Load ing Warehouse \ n");
for (w _id =1L; w _id <=count_w are; w _id ++) {
/ * Generate Warehouse Data */
MakeAlp haString( 6, 10, w _nam e);
MakeAd dress( w _street_1, w _street_2, w _city, w _state, w _zip );
w _tax=((float)Rand om N um ber(10L,20L))/ 100.0;
w _ytd =3000000.00;
if ( option_d ebug )
printf( "WID = %ld , Nam e= %16s, Tax = %5.2f\ n",
w _id, w _nam e, w _tax );
EXEC SQL IN SERT IN TO
w arehouse (w _id , w _name,
w _street_1, w _street_2, w _city, w _state, w _zip,
w _tax, w _ytd )
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 120 of 130
values (:w _id , :w _nam e,
:w _street_1, :w _street_2, :w _city, :w _state,
:w _zip, :w _tax, :w _ytd );
/ ** Make Row s associated w ith Warehouse **/
Stock(w _id );
District(w _id );
EXEC SQL COMMIT WORK;
}
return;
sqlerr:
Error();
}
/ *==================================================================+
| ROUTIN E N AME
|
Load Cust
| DESCRIPTION
|
Load s the Custom er Table
| ARGUMEN TS
|
none
+==================================================================*/
void Load Cust()
{
EXEC SQL BEGIN DECLARE SECTION ;
EXEC SQL EN D DECLARE SECTION ;
long w _id ;
long d _id;
EXEC SQL WH EN EVER SQLERROR GOTO sqlerr;
for (w _id =1L; w _id <=count_w are; w _id ++)
for (d_id =1L; d _id <=DIST_PER_WARE; d _id ++)
Cu stom er(d _id ,w _id );
EXEC SQL COMMIT WORK; / * Just in case */
return;
sqlerr:
Error();
}
/ *==================================================================+
| ROUTIN E N AME
|
Load Ord
| DESCRIPTION
|
Load s the Ord ers and Ord er_Line Tables
| ARGUMEN TS
|
none
+==================================================================*/
void Load Ord ()
{
EXEC SQL BEGIN DECLARE SECTION ;
long w _id ;
float w _tax;
long d _id;
float d _tax;
EXEC SQL EN D DECLARE SECTION ;
EXEC SQL WH EN EVER SQLERROR GOTO sqlerr;
for (w _id =1L; w _id <=count_w are; w _id ++)
for (d_id =1L; d _id <=DIST_PER_WARE; d _id ++)
Ord ers(d_id , w _id );
EXEC SQL COMMIT WORK; / * Just in case */
return;
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 121 of 130
sqlerr:
Error();
}
/ *==================================================================+
| ROUTIN E N AME
|
Stock
| DESCRIPTION
|
Load s the Stock table
| ARGUMEN TS
|
w _id - w arehouse id
+==================================================================*/
void Stock(w _id )
long w _id ;
{
EXEC SQL BEGIN DECLARE SECTION ;
long s_i_id;
long s_w _id ;
long s_quantity;
char s_d ist_01[24];
char s_d ist_02[24];
char s_d ist_03[24];
char s_d ist_04[24];
char s_d ist_05[24];
char s_d ist_06[24];
char s_d ist_07[24];
char s_d ist_08[24];
char s_d ist_09[24];
char s_d ist_10[24];
char s_d ata[50];
EXEC SQL EN D DECLARE SECTION ;
int sd atasiz;
long orig[MAXITEMS];
long pos;
int i;
EXEC SQL WH EN EVER SQLERROR GOTO sqlerr;
printf("Load ing Stock Wid =%ld \ n",w _id );
s_w _id =w _id ;
for (i=0; i<MAXITEMS/ 10; i++) orig[i]=0;
for (i=0; i<MAXITEMS/ 10; i++)
{
do
{
pos=Rand om N um ber(0L,MAXITEMS);
} w hile (orig[pos]);
orig[pos] = 1;
}
for (s_i_id =1; s_i_id <=MAXITEMS; s_i_id ++) {
/ * Generate Stock Data */
s_quantity=Rand om N um ber(10L,100L);
MakeAlphaString(24,24,s_d ist_01);
MakeAlphaString(24,24,s_d ist_02);
MakeAlphaString(24,24,s_d ist_03);
MakeAlphaString(24,24,s_d ist_04);
MakeAlphaString(24,24,s_d ist_05);
MakeAlphaString(24,24,s_d ist_06);
MakeAlphaString(24,24,s_d ist_07);
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 122 of 130
MakeAlphaString(24,24,s_d ist_08);
MakeAlphaString(24,24,s_d ist_09);
MakeAlphaString(24,24,s_d ist_10);
sd atasiz=MakeAlphaString(26,50,s_data);
if (orig[s_i_id ])
{
pos=Rand om N um ber(0L,sd atasiz-8);
s_d ata[pos]='o';
s_d ata[pos+1]='r';
s_d ata[pos+2]='i';
s_d ata[pos+3]='g';
s_d ata[pos+4]='i';
s_d ata[pos+5]='n';
s_d ata[pos+6]='a';
s_d ata[pos+7]='l';
}
EXEC SQL IN SERT IN TO
stock (s_i_id , s_w _id , s_quantity,
s_dist_01, s_d ist_02, s_d ist_03, s_d ist_04, s_d ist_05,
s_dist_06, s_d ist_07, s_d ist_08, s_d ist_09, s_d ist_10,
s_data, s_ytd , s_cnt_ord er, s_cnt_rem ote)
values (:s_i_id, :s_w _id , :s_quantity,
:s_d ist_01, :s_d ist_02, :s_d ist_03, :s_d ist_04, :s_d ist_05,
:s_d ist_06, :s_d ist_07, :s_d ist_08, :s_d ist_09, :s_d ist_10,
:s_d ata, 0, 0, 0);
if ( option_d ebug )
printf( "SID = %ld , WID = %ld , Quan = %ld \ n",
s_i_id , s_w _id , s_quantity );
if ( !(s_i_id % 100) ) {
EXEC SQL COMMIT WORK;
printf(".");
if ( !(s_i_id % 5000) ) printf(" %ld \ n",s_i_id );
}
}
EXEC SQL COMMIT WORK;
printf(" Stock Done.\ n");
return;
sqlerr:
Error();
}
/ *==================================================================+
| ROUTIN E N AME
|
District
| DESCRIPTION
|
Load s the District table
| ARGUMEN TS
|
w _id - w arehouse id
+==================================================================*/
void District(w _id )
long w _id ;
{
EXEC SQL BEGIN DECLARE SECTION ;
long d _id ;
long d _w _id ;
char d _nam e[10];
char d _street_1[20];
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 123 of 130
char d _street_2[20];
char d _city[20];
char d _state[2];
char d _zip[9];
float d_tax;
float d_ytd ;
long d _next_o_id ;
EXEC SQL EN D DECLARE SECTION ;
EXEC SQL WH EN EVER SQLERROR GOTO sqlerr;
printf("Load ing District\ n");
d_w _id =w _id ;
d_ytd =30000.0;
d_next_o_id =3001L;
for (d _id =1; d_id <=DIST_PER_WARE; d _id ++) {
/ * Generate District Data */
MakeAlphaString(6L,10L,d_nam e);
MakeAd dress( d _street_1, d _street_2, d _city, d _state, d _zip );
d _tax=((float)Rand om N um ber(10L,20L))/ 100.0;
EXEC SQL IN SERT IN TO
d istrict (d _id , d _w _id, d_nam e,
d_street_1, d_street_2, d_city, d _state, d _zip,
d_tax, d _ytd , d _next_o_id )
values (:d _id , :d _w _id, :d_nam e,
:d_street_1, :d_street_2, :d_city, :d_state, :d _zip,
:d_tax, :d _ytd , :d_next_o_id );
if ( option_d ebug )
printf( "DID = %ld , WID = %ld , N am e = %10s, Tax = %5.2f\ n",
d _id , d_w _id , d _name, d _tax );
}
EXEC SQL COMMIT WORK;
return;
sqlerr:
Error();
}
/ *==================================================================+
| ROUTIN E N AME
|
Custom er
| DESCRIPTION
|
Load s Custom er Table
|
Also inserts correspond ing history record
| ARGUMEN TS
|
id - custom er id
|
d_id - d istrict id
|
w _id - w arehouse id
+==================================================================*/
void Custom er( d _id , w _id )
long d_id ;
long w _id ;
{
EXEC SQL BEGIN DECLARE SECTION ;
long c_id ;
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 124 of 130
long c_d_id ;
long c_w _id ;
char c_first[16];
char c_m id d le[2];
char c_last[16];
char c_street_1[20];
char c_street_2[20];
char c_city[20];
char c_state[2];
char c_zip[9];
char c_phone[16];
char c_since[11];
char c_cred it[2];
long c_cred it_lim ;
float c_d iscount;
float c_balance;
char c_data[500];
float h_am ount;
char h_d ata[24];
EXEC SQL EN D DECLARE SECTION ;
EXEC SQL WH EN EVER SQLERROR GOTO sqlerr;
printf("Load ing Custom er for DID=%ld , WID=%ld \ n",d _id ,w _id );
for (c_id =1; c_id <=CUST_PER_DIST; c_id ++) {
/ * Generate Custom er Data */
c_d _id =d _id ;
c_w _id =w _id ;
MakeAlphaString( 8, 16, c_first );
c_m id d le[0]='O'; c_m id d le[1]='E';
if (c_id <= 1000)
Lastnam e(c_id -1,c_last);
else
Lastnam e(N URand (255,0,999),c_last);
MakeAd dress( c_street_1, c_street_2, c_city, c_state, c_zip );
MakeN um berString( 16, 16, c_phone );
if (Rand om N um ber(0L,1L))
c_credit[0]='G';
else
c_credit[0]='B';
c_cred it[1]='C';
c_cred it_lim =50000;
c_d iscount=((float)Rand om N um ber(0L,50L))/ 100.0;
c_balance= -10.0;
MakeAlphaString(300,500,c_d ata);
EXEC SQL IN SERT IN TO
custom er (c_id , c_d_id, c_w _id ,
c_first, c_m id d le, c_last,
c_street_1, c_street_2, c_city, c_state, c_zip,
c_phone, c_since, c_cred it,
c_cred it_lim , c_discount, c_balance, c_d ata,
c_ytd _paym ent, c_cnt_paym ent, c_cnt_d elivery)
values (:c_id , :c_d _id , :c_w _id,
:c_first, :c_m id d le, :c_last,
:c_street_1, :c_street_2, :c_city, :c_state, :c_zip,
:c_phone, :tim estam p , :c_cred it,
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 125 of 130
:c_cred it_lim , :c_d iscount, :c_balance, :c_data,
10.0, 1, 0) ;
h_am ount=10.0;
MakeAlphaString(12,24,h_d ata);
EXEC SQL IN SERT IN TO
history (h_c_id , h_c_d _id , h_c_w _id ,
h_w _id , h_d_id , h_d ate, h_am ount, h_d ata)
values (:c_id , :c_d _id , :c_w _id,
:c_w _id , :c_d_id , :tim estam p , :h_am ount, :h_d ata);
if ( option_d ebug )
printf( "CID = %ld , LST = %s, P# = %s\ n",
c_id , c_last, c_phone );
if ( !(c_id % 100) ) {
EXEC SQL COMMIT WORK;
printf(".");
if ( !(c_id % 1000) ) printf(" %ld \ n",c_id );
}
}
printf("Custom er Done.\ n");
return;
sqlerr:
Error();
}
/ *==================================================================+
| ROUTIN E N AME
|
Ord ers
| DESCRIPTION
|
Load s the Ord ers table
|
Also loads the Ord er_Line table on the fly
| ARGUMEN TS
|
w _id - w arehouse id
+================================================ ==================*/
void Ord ers(d _id, w _id )
long d _id , w _id ;
{
EXEC SQL BEGIN DECLARE SECTION ;
long o_id ;
long o_c_id ;
long o_d_id ;
long o_w _id ;
long o_carrier_id ;
long o_ol_cnt;
long ol;
long ol_i_id;
long ol_supply_w _id;
long ol_quantity;
long ol_am ount;
char ol_d ist_info[24];
float i_price;
float c_d iscount;
EXEC SQL EN D DECLARE SECTION ;
EXEC SQL WH EN EVER SQLERROR GOTO sqlerr;
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 126 of 130
printf("Load ing Ord ers for D=%ld , W= %ld \ n", d_id , w _id );
o_d _id =d_id ;
o_w _id =w _id ;
InitPerm utation();
/ * initialize perm utation of custom er num bers */
for (o_id =1; o_id <=ORD_PER_DIST; o_id ++) {
/ * Generate Order Data */
o_c_id =GetPerm utation();
o_carrier_id =Rand om N um ber(1L,10L);
o_ol_cnt=Rand om N um ber(5L,15L);
if (o_id > 2100)
/ * the last 900 ord ers have not been delivered ) */
{
EXEC SQL IN SERT IN TO
ord ers (o_id , o_c_id, o_d_id , o_w _id ,
o_entry_d , o_carrier_id , o_ol_cnt, o_all_local)
values (:o_id , :o_c_id , :o_d _id , :o_w _id ,
:tim estam p , N ULL, :o_ol_cnt, 1);
EXEC SQL IN SERT IN TO
new _ord er (no_o_id , no_d _id , no_w _id )
values (:o_id , :o_d _id, :o_w _id );
}
else
EXEC SQL IN SERT IN TO
ord ers (o_id , o_c_id, o_d_id , o_w _id ,
o_entry_d , o_carrier_id , o_ol_cnt, o_all_local)
values (:o_id , :o_c_id , :o_d _id , :o_w _id ,
:tim estam p , :o_carrier_id , :o_ol_cnt, 1);
if ( option_d ebug )
printf( "OID = %ld , CID = %ld , DID = %ld , WID = %ld \ n",
o_id , o_c_id, o_d_id, o_w _id );
for (ol=1; ol<=o_ol_cnt; ol++) {
/ * Generate Order Line Data */
ol_i_id =Rand om N um ber(1L,MAXITEMS);
ol_supply_w _id =o_w _id ;
ol_quantity=5;
ol_am ount=0.0;
MakeAlphaString(24,24,ol_d ist_info);
if (o_id > 2100)
EXEC SQL IN SERT IN TO
order_line (ol_o_id , ol_d _id , ol_w _id, ol_num ber,
ol_i_id, ol_supply_w _id , ol_quantity, ol_am ount,
ol_d ist_info, ol_d elivery_d )
values (:o_id , :o_d _id , :o_w _id , :ol,
:ol_i_id , :ol_supply_w _id , :ol_quantity, :ol_am ount,
:ol_d ist_info, N ULL);
else
EXEC SQL IN SERT IN TO
order_line (ol_o_id , ol_d _id , ol_w _id, ol_num ber,
ol_i_id, ol_supply_w _id , ol_quantity,
((float)(Rand omN um ber(10L, 10000L))/ 100.0,
ol_d ist_info, ol_d elivery_d )
values (:o_id , :o_d _id , :o_w _id , :ol,
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 127 of 130
:ol_i_id , :ol_supply_w _id , :ol_quantity,
:ol_am ount,
:ol_d ist_info, d atetim e);
if ( option_d ebug )
printf( "OL = %ld , IID = %ld , QUAN = %ld , AMT = %8.2f\ n",
ol, ol_i_id , ol_quantity, ol_am ount);
}
if ( !(o_id % 100) ) {
printf(".");
EXEC SQL COMMIT WORK;
if ( !(o_id % 1000) ) printf(" %ld \ n",o_id );
}
}
EXEC SQL COMMIT WORK;
printf("Ord ers Done.\ n");
return;
sqlerr:
Error();
}
/ *==================================================================+
| ROUTIN E N AME
|
MakeAd d ress()
| DESCRIPTION
|
Build an Ad d ress
| ARGUMEN TS
+==================================================================*/
void MakeAd d ress(str1,str2,city,state,zip)
char *str1;
char *str2;
char *city;
char *state;
char *zip;
{
MakeAlphaString(10,20,str1); / * Street 1*/
MakeAlphaString(10,20,str2); / * Street 2*/
MakeAlphaString(10,20,city); / * City */
MakeAlphaString(2,2,state); / * State */
MakeN um berString(9,9,zip); / * Zip */
}
/ *==================================================================+
| ROUTIN E N AME
|
Error()
| DESCRIPTION
|
H and les an error from a SQL call.
| ARGUMEN TS
+==================================================================*/
void Error()
{
printf( "SQL Error %d \ n", sqlca.sqlcod e);
EXEC SQL WH EN EVER SQLERROR CON TIN UE;
EXEC SQL ROLLBACK WORK RELEASE;
exit( -1 );
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 128 of 130
}
/ *==================================================================+
| ROUTIN E N AME
|
Lastnam e
| DESCRIPTION
|
TPC-C Lastnam e Function.
| ARGUMEN TS
|
num - non-uniform random num ber
|
nam e - last nam e string
+==================================================================*/
void Lastnam e(num , nam e)
int num ;
char *nam e;
{
int i;
static char *n[] =
{"BAR", "OUGH T", "ABLE", "PRI", "PRES",
"ESE", "AN TI", "CALLY", "ATION ", "EIN G"};
strcpy(nam e,n[num / 100]);
strcat(nam e,n[(num / 10)%10]);
strcat(nam e,n[num %10]);
return;
}
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 129 of 130
Appendix B: EXECUTIVE SUMMARY STATEMEN T
The tables on the follow ing p age illu strate the form at of the TPC Execu tive Su m m ary Statem ent that m u st be u sed to
rep ort the su m m ary benchm ark resu lts. The latest version of the requ ired form at is ava ilable u p on requ est from the
TPC ad m inistrator (see cover p age).
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 130 of 130
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 131 of 130
Appendix C: N UMERICAL QUAN TITIES SUMMARY
The follow ing table p artially illu strates how to su m m arize all the nu m erical qu antities re qu ired in the Full
Disclosu re Rep ort:
MQTh, com p u ted Maxim u m Qu alified Throu ghp u t
105 tp m C
Response Times (90th percentile/ Average/ m axim um ) in second s
-
N ew -Ord er
Paym ent
Ord er-Statu s
Delivery (interactive p ortion)
Delivery (d eferred p ortion)
Stock-Level
Menu
4.9
2.1
3.5
0.5
15.2
17.8
0.2
-
Resp onse tim e d elay ad d ed for em u lated com p onen ts
/
/
/
/
/
/
/
2.8
1.0
1.7
0.2
8.1
9.5
0.1
/
/
/
/
/
/
/
28.0
12.8
9.4
0.9
45.5
29.4
0.9
0.35 second s
Transaction Mix, in percent of total transactions
-
N ew -Ord er
Paym ent
Ord er-Statu s
Delivery
Stock-Level
Keying/Think Times (in second s),
-
N ew -Ord er
Paym ent
Ord er-Statu s
Delivery
Stock-Level
44.5 %
43.1 %
4.1 %
4.2 %
4.1 %
Min.
9.2 /
1.6 /
1.1 /
1.1 /
1.0 /
6.1
6.1
5.1
2.8
2.7
Average
18.5 / 12.2
3.1 / 12.2
2.1 / 10.2
2.1 / 5.1
2.1 / 5.1
Max.
37.1 /
6.2 /
4.2 /
4.3 /
4.3 /
25.2
24.7
21.2
10.3
10.2
Test D uration
-
Ram p -u p tim e
Measu rem ent interval
N u m ber of checkp oints
Checkp oint interval
N u m ber of transactions (all typ es)
com p leted in m easu rem ent interval
20 m inu tes
120 m inu tes
4
30 m inu tes
(and all other nu m erical quantities requ ired in the Full Disclosu re Rep ort )
TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 132 of 130
28,463