TPC BENCHMARK (TM) H (779138), страница 13

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 13)

For RF1 andRF2 only, the implementation is permitted to:Use any language to write the code for the refresh functions;Pre-process, compile and link the executable code on the SUT at any time prior to or during themeasurement interval;Provide the SUT with the data to be inserted by RF1 or the set of keys for the rows to be deleted by RF2prior to the execution of the benchmark (this specifically does not allow pre-execution of the refreshfunctions).Comment: The intent is to separate the resources required to generate the data to be inserted (or the set of key forthe rows to be deleted) from the resources required to execute insert and delete operations against the database.Group the individual refresh functions into transactions and organize their execution serially or in parallel.This grouping may be different in the power test and in the throughput test.2.5.3.2 The refresh functions do not produce any output other than a message of successful completion.2.5.3.3 The proper implementation of the refresh functions must be validated by the independent auditor who may requestadditional tests to ascertain that the refresh functions execute in accordance with the benchmark requirements.2.6New Sales Refresh Function (RF1)This refresh function adds new sales information to the database.2.6.1Business RationaleThe New Sales refresh function inserts new rows into the ORDERS and LINEITEM tables in the database followingthe scaling and data generation methods used to populate the database.2.6.2Refresh Function DefinitionLOOP (SF * 1500) TIMESTPC BenchmarkTM H Standard Specification Revision 2.17.1Page 68INSERT a new row into the ORDERS tableLOOP RANDOM(1, 7) TIMESINSERT a new row into the LINEITEM tableEND LOOPEND LOOPComment: The refresh functions can be implemented with much greater flexibility than the queries (see Clause2.5.3).

The definition provided here is an example only. Test sponsors may wish to explore other implementations.2.6.3Refresh Data SetThe set of rows to be inserted must be produced by DBGen using the -U option. This option will produce as manysets of rows as required for use in multi-stream tests.2.7Old Sales Refresh Function (RF2)This refresh function removes old sales information from the database.2.7.1Business RationaleThe Old Sales refresh function removes rows from the ORDERS and LINEITEM tables in the database to emulatethe removal of stale or obsolete information.2.7.2Refresh Function DefinitionLOOP (SF * 1500) TIMESDELETE FROM ORDERS WHERE O_ORDERKEY = [value]DELETE FROM LINEITEM WHERE L_ORDERKEY = [value]END LOOPComment: The refresh functions can be implemented with much greater flexibility than the queries (see Clause2.5.3).

The definition provided here is an example only. Test sponsors may wish to explore other implementation2.7.3Refresh Data SetThe ’Primary Key’ values for the set of rows to be deleted must be produced by DBGen using the -U option. Thisoption will produce as many sets of ’Primary Keys’ as required for use in multi-stream throughput tests. The rowsbeing deleted begin with the first row of each of the two targeted tables.2.8Database Evolution ProcessThe test sponsor must assure the correctness of the database for each run within the performance test.This is accomplished by ”evolving” the test database, keeping track of which set of inserted and deleted rows shouldbe used by RF1 and RF2 for each run (see Clause 5.1.1.4).Comment: It is explicitly not permitted to rebuild or reload the test database during the performance test (see Clause5.1.1.3).2.8.1The test database may be endlessly reused if the test sponsor keeps careful track of how many pairs of refresh functions RF1/RF2 have been executed and completed successfully.

For example, a test sponsor running five streamswould execute one RF1/RF2 pair during the power test using the first set of insert/delete rows produced by DBGEN(see Clause 4.2.1). The throughput test would then execute the next five RF1/RF2 pairs using the second through thesixth sets of inset/delete rows produced by DBGEN.

The next run would use the sets of insert/delete rows producedby DBGEN for the seventh RF1/RF2 pair, and continue from there.TPC BenchmarkTM H Standard Specification Revision 2.17.1Page 693: THE ACID PROPERTIES3.1.1The ACID (Atomicity, Consistency, Isolation, and Durability) properties of transaction processing systems must besupported by the system under test during the timed portion of this benchmark. Since TPC-H is not a transactionprocessing benchmark, the ACID properties must be evaluated outside the timed portion of the test. It is the intent ofthis section to informally define the ACID properties and to specify a series of tests that can be performed todemonstrate that these properties are met.3.1.2While it is required for the system under test (SUT) to support the ACID properties defined in this Clause, the execution of the corresponding ACID tests is only required in lieu of supplying other sufficient evidence of the SUT'ssupport for these ACID properties.

The existence of another published TPC-H benchmark for which support for theACID properties have been demonstrated using the tests defined in this Clause may be sufficient evidence that thenew SUT supports some or all of the required ACID properties. The determination of whether previously publishedTPC-H test results are sufficient evidence of the above is left to the discretion of the auditor.Comment 1: No finite series of tests can prove that the ACID properties are fully supported.

Being able to pass thespecified tests is a necessary, but not sufficient, condition for meeting the ACID requirements.Comment 2: The ACID tests are intended to demonstrate that the ACID properties are supported by the SUT andenabled during the performance measurements. They are not intended to be an exhaustive quality assurance test.3.1.3The ACID tests must be performed against the qualification database. The same set of mechanisms used to ensurefull ACID properties of the qualification database during the ACID tests must be used/enabled for the test databaseduring the performance test. This applies both to attributes of the database and to attributes of the database session(s)used to execute the ACID and performance tests.

The attributes of the session executing the ACID Query (seeClause 3.1.6.3) must be the same as those used in the performance test query stream(s) (see Clause 5.1.2.3), and theattributes of the session executing the ACID transaction (see Clause 3.1.6.2) must be the same as those used in theperformance test refresh stream (see Clause 5.1.2.4).3.1.4The mechanisms used to ensure durability of the qualification database must be enabled for the test database.

Forexample:a)If the qualification database relies on undo logs to ensure atomicity, then such logging must also be enabledfor the test database during the performance test, even though no transactions are aborted.b)If the qualification database relies on a database backup to meet the durability requirement (see Clause 3.5), abackup must be taken of the test database.c)If the qualification database relies on data redundancy mechanisms to meet the durability requirement (seeClause 3.5), these mechanisms must be active during the execution of the performance test.3.1.5The test sponsor must attest that the reported configuration would also pass the ACID tests with the test database.3.1.6The ACID Transaction and The ACID QuerySince this benchmark does not contain any OLTP transaction, a special ACID Transaction is defined for use insome of the ACID tests.

In addition, to simplify the demonstration that ACID properties are enabled while read-onlyqueries are executing concurrently with other activities, a special ACID Query is defined.3.1.6.1 Both the ACID transaction and the ACID Query utilize a truncation function to guarantee arithmetic function portability and consistency of results. Define trunc(n,p) asTrunk(n, p) = n * 10p  10pwhich truncates n to the pth decimal place (e.g., trunc(1.357,2) = 1.35).Comment: The intent of this clause is to specify the required functionality without dictating a particular implementation.3.1.6.2 The ACID Transaction must be implemented to conform to the following transaction profile:TPC BenchmarkTM H Standard Specification Revision 2.17.1Page 70Given the set of input data (O_KEY, L_KEY, [delta]), withO_KEY selected at random from the same distribution as that used to populate L_ORDERKEY in thequalification database (see Clause 4.2.3),L_KEY selected at random from [1 ..

M] whereM = SELECT MAX(L_LINENUMBER) FROM LINEITEM WHERE L_ORDERKEY = O_KEYusing the qualification database, and [delta] selected at random within [1 .. 100]:BEGIN TRANSACTIONRead O_TOTALPRICE from ORDERS into [ototal] where O_ORDERKEY = [o_key]Read L_QUANTITY, L_EXTENDEDPRICE, L_PARTKEY, L_SUPPKEY, L_TAX, L_DISCOUNT into[quantity], [extprice], [pkey], [skey], [tax], [disc]where L_ORDERKEY = [o_key] and L_LINENUMBER = [l_key]Set [ototal] = [ototal] trunc( trunc([extprice] * (1 - [disc]), 2) * (1 + [tax]), 2)Set [rprice] = trunc([extprice]/[quantity], 2)Set [cost] = trunc([rprice] * [delta], 2)Set [new_extprice] = [extprice] + [cost]Set [new_ototal] = trunc([new_extprice] * (1.0 - [disc]), 2)Set [new_ototal] = trunc([new_ototal] * (1.0 + [tax]), 2)Set [new_ototal] = [ototal] + [new_ototal]Update LINEITEMwhere L_ORDERKEY = [o_key] and L_LINENUMBER = [l_key]Set L_EXTENDEDPRICE = [new_extprice]Set L_QUANTITY = [quantity] + [delta]Write L_EXTENDEDPRICE, L_QUANTITY to LINEITEMUpdate ORDERS where O_ORDERKEY = [o_key]Set O_TOTALPRICE = [new_ototal]Write O_TOTALPRICE to ORDERSInsert Into HISTORYValues ([pkey], [skey], [o_key], [l_key], [delta], [current_date_time])COMMIT TRANSACTIONReturn [rprice], [quantity], [tax], [disc], [extprice], [ototal] to driverWhere HISTORY is a table required only for the ACID tests and defined as follows:TPC BenchmarkTM H Standard Specification Revision 2.17.1Page 71Column NameDatatype RequirementsH_P_KEYidentifierForeign reference to P_PARTKEYH_S_KEYidentifierForeign reference to S_SUH_O_KEYidentifierForeign reference toO_ORDERKEYH_L_KEYintegerH_DELTAintegerH_DATE_Tdate and time to secondComment: The values returned by the ACID Transaction are the old values, as read before the updates.3.1.6.3 The ACID Query must be implemented to conform to the following functional query definition:Given the input data:O_KEY, selected within the same distributions as those used for the population of L_ORDERKEY in thequalification database:SELECT SUM(trunc(trunc(L_EXTENDEDPRICE * (1 - L_DISCOUNT),2) * (1 + L_TAX),2))FROM LINEITEMWHERE L_ORDERKEY = [o_key]3.1.6.4 The ACID Transaction and the ACID Query must be used to demonstrate that the ACID properties are fully supported by the system under test.3.1.6.5 Although the ACID Transaction and the ACID Query do not involve all the tables of the TPC-H database, the ACIDproperties must be supported for all tables of the TPC-H database.3.2Atomicity Requirements3.2.1Atomicity Property DefinitionThe system under test must guarantee that transactions are atomic; the system will either perform all individualoperations on the data, or will assure that no partially-completed operations leave any effects on the data.3.2.2Atomicity Tests3.2.2.1 Perform the ACID Transaction (see Clause 3.1.5) for a randomly selected set of input data and verify that the appropriate rows have been changed in the ORDERS, LINEITEM, and HISTORY tables.3.2.2.2 Perform the ACID Transaction for a randomly selected set of input data, substituting a ROLLBACK of the transaction for the COMMIT of the transaction.

Характеристики

Список файлов книги