TPC BENCHMARK (TM) H (779138), страница 18
Текст из файла (страница 18)
The generated records may be passed through a communication channel, stored in memory, or stored infiles on storage media.2.Loading Phase: the process of loading the generated records into the database tables.Generation and loading of the records can be accomplished in one of two ways:1.Load from stored records: The records generated by DBGen are first stored (in memory or on storage media).The stored records may optionally be sorted, partitioned or relocated to the SUT.
After table creation on theSUT, the stored records are loaded into the database tables. In this case only the loading phase contributes tothe database load time.2.In-line load: The records generated by DBGen are passed through a communication channel and directlyloaded into the database tables. In this case generation phase and loading phase occur concurrently and bothcontribute to the database load time.TPC BenchmarkTM H Standard Specification Revision 2.17.1Page 894.3.4The database load time must be measured on the system under test (SUT).4.3.5The timing of the database load time begins with the creation of the tables defined in Clause 1.4.4.3.6There are five classes of operations which may be excluded from database load time:Any operation that does not affect the state of the DBMS (e.g., generation of records by DBGen, storage ofgenerated records, relocation of stored records to the SUT, sorting or partitioning of stored records,operating-system-level disk partitioning or configuration);Any modification to the state of the DBMS that is not specific to the TPC-H workload (e.g.
logicaltablespace creation or database block formatting);The time required to install or remove physical resources (e.g. processors/cores/threads, memory or diskdrives) on the SUT that are not priced (see Clause 4.3.9);An optional backup of the test database performed at the test sponsor’s discretion. However, if a backup isrequired to ensure that the ACID properties can be met it must be included in the load time;Operations that create devices used to implement data redundancy mechanisms.Comment: The time required to perform any necessary software reconfiguration (such as DBMS or operatingsystem parameters) must be included in the database load time.4.3.7The timing of the database load ends when the database is fully populated and the SUT is configured as it will beduring the performance test.Comment 1: The intent of this Clause is that when the timing ends the system under test be capable of executing theperformance test without any further change.
The database load may be decomposed into several phases. Databaseload time is the sum of the elapsed times of all phases during which activity other than that detailed in Clause 4.3.6occurred on the SUT. The timing of a load phase completes only when any change to the test database has beenwritten to durable media (see Clause 3.5.1).Comment 2: Since the time of the end of the database load is used to seed the random number generator for thesubstitution parameter, that time cannot be delayed in any way that would make it predictable to the test sponsor.4.3.84.3.9The resources used to generate DBGen records, sort or partition the records, store the records or relocate the recordsto the SUT may optionally be distinct from those used to run the actual benchmark.
For example:For load from stored records, a separate system or a distinct storage subsystem may be used to generate,store, sort, partition or relocate the DBGen records to be delivered to the DBMS load facility.Fo rin-line load, separate and distinct processing elements may be used to generate the DBGen recordspassed to the DBMS load facility.Resources used only in the generation phase of the population of the test database must be treated as follows:For load from stored records,Any processing element (e.g., processor/core/thread or memory) used exclusively to generate and store,sort, or partition DBGen records or relocate the records to the SUT prior to the loading phase shall not beincluded in the total priced system (see Clause 7.1) and must be physically removed from or madeinaccessible to the SUT prior to the start of the loading phase;Any storage facility (e.g., disk drive, tape drive or peripheral controller) used exclusively to generate anddeliver DBGen records to the SUT during the loading phase shall not be included in the total pricedsystem.
The test sponsor must demonstrate to the satisfaction of the auditor that this facility is not beingused in the performance test.For in-line load,Any processing element (e.g., processor/core/thread or memory) or storage facility (e.g., disk drive, tapedrive or peripheral controller) used exclusively to generate and deliver DBGen records to the SUT duringthe loading phase shall not be included in the total priced system and must be physically removed from ormade inaccessible to the SUT prior to the start of the performance test.Comment: The intent is to isolate the cost of resources required to generate records from those required to loadrecords into the database tables.TPC BenchmarkTM H Standard Specification Revision 2.17.1Page 904.3.104.3.11An implementation may require additional programs to transfer DBGen records into the database tables (for eitherload from stored records or in-line load).
If non-commercial programs are used for this purpose, their source codemust be disclosed. If commercially available programs are used for this purpose, their invocation and configurationmust be disclosed. Whether or not the software is commercially available, use of the software's functionality's mustbe limited to:1.Storing, sorting, or partitioning of the records generated by DBGen ;2.Delivery of the records generated by DBGen to the DBMS load facility.The database load must be implemented using commercially available utilities (invoked at the command level orthrough an API) or an SQL programming interface (such as embedded SQL or ODBC).TPC BenchmarkTM H Standard Specification Revision 2.17.1Page 915: PERFORMANCE METRICS AND EXECUTION RULES5.1Definition of Terms5.1.1Components of the Benchmark5.1.1.1 The benchmark is defined as the execution of the load test followed by the performance test.5.1.1.2 The load test begins with the creation of the database tables and includes all activity required to bring the systemunder test to the configuration that immediately precedes the beginning of the performance test (see Clause 5.1.1.3).The load test may not include the execution of any of the queries in the performance test (see Clause 5.1.2.1) or anysimilar query.5.1.1.3 The performance test consists of two runs.5.1.1.4 A run consists of one execution of the Power test described in Clause 5.3.3 followed by one execution of theThroughput test described in Clause 5.3.4.5.1.1.5 Run 1 is the first run following the load test (see Clause 5.3.1.4).
Run 2 is the run following Run 1.5.1.1.6 A failed run is defined as a run that did not complete successfully due to unforeseen system failures.5.1.2Components of a Run5.1.2.1 A query is defined as any one of the 22 TPC-H queries specified in Clause 2: .The symbol "Qi ", with i in lowercase and from 1 to 22, represents a given query.5.1.2.2 A query set is defined as the sequential execution of each and every one of the queries.5.1.2.3 A query stream is defined as the sequential execution of a single query set submitted by a single emulated user.The symbol "S", in uppercase, is used to represent the number of query streams used during the throughputtest;The symbol "s", in lowercase and from 1 to S, is used to represent a given query stream.5.1.2.4 A refresh stream is defined as the sequential execution of an integral number of pairs of refresh functions submitted from within a batch program.5.1.2.5 A pair of refresh functions is defined as one of each of the two TPC-H refresh functions specified in Clause 2: .The symbol "RFj ", with j in lowercase and from 1 to 2, represents a given refresh function.A session is defined as the process context capable of supporting the execution of either a query stream or a refreshstream.5.2Configuration Rules5.2.1The mechanism used to submit queries and refresh functions to the system under test (SUT) and measure their execution time is called a driver.
The driver is a logical entity that can be implemented using one or more physical programs, processes, or systems (see Clause 6.3).5.2.2The communication between the driver and the SUT must be limited to one session per query stream or per refreshstream. These sessions are prohibited from communicating with one another except for the purpose of schedulingrefresh functions (see Clause 5.3.7.8).5.2.3All sessions supporting the execution of a query stream must be initialized in exactly the same way.
The initialization of the session supporting the execution of the refresh stream may be different than that of the query streams. Allsession initialization parameters, settings and commands must be disclosed.TPC BenchmarkTM H Standard Specification Revision 2.17.1Page 92Comment 1: The attributes of the session used in the query stream(s) (see Clause 5.1.2.3) must be the same as theattributes of the session used by the ACID Query (see Clause 3.1.6.3). Similarly, the attributes of the session used inthe refresh stream (see Clause 5.1.2.4) must be the same as the attributes of the session used by the ACID Transaction (see Clause 3.1.6.3)Comment 2: The intent of this Clause is to provide the information needed to precisely recreate the execution environment of any given stream prior to the submission of the first query or refresh function.5.2.4The driver submits each TPC-H query for execution by the SUT via the session associated with the correspondingquery stream.5.2.5In the case of the two refresh functions (RF1 and RF2), the driver is only required to submit the commands necessary to cause the execution of each refresh function.5.2.6The driver's submittal to the SUT of the queries in the performance test (see Clause 5.1.2.1) is constrained by thefollowing restrictions:It must comply with the query compliance requirements of Clause 2.2;No part of the interaction between the driver and the SUT can have the purpose of indicating to the DBMSor operating system an execution strategy or priority that is time dependent or query specific;Comment: Automatic priority adjustment performed by the operating system is not prohibited, but specifying avarying priority to the operating system on a query by query basis is prohibited.5.2.7The settings of the SUT's components, such as DBMS (including tables and tablespaces) and operating system, are not to be modified on a query by query basis.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
