TPC BENCHMARK (TM) H (779138), страница 24
Текст из файла (страница 24)
All listings must be reported in the supporting files archive.8.3.3.2 The physical organization of tables and indices within the test and qualification databases must be disclosed. If thecolumn ordering of any table is different from that specified in Clause 1.4, it must be noted. The physicalorganization of tables must be reported in the supporting files archive.Comment: The concept of physical organization includes, but is not limited to: record clustering (i.e., rows fromdifferent logical tables are co-located on the same physical data page), index clustering (i.e., rows and leaf nodes ofan index to these rows are co-located on the same physical data page), and partial fill-factors (i.e., physical datapages are left partially empty even though additional rows are available to fill them).8.3.3.3 Horizontal partitioning of tables and rows in the test and qualification databases (see Clause 1.5.4) must bedisclosed.
Scripts to perform horizontal partitioning must be reported in the supporting files archive.8.3.3.4 Any replication of physical objects must be disclosed and must conform to the requirements of Clause 1.5.7. Scriptsto perform any replication must be reported in the supporting files archive.TPC BenchmarkTM H Standard Specification Revision 2.17.1Page 1108.3.3.5 Script or text for all hardware and software tunable parameters must be reported in the supporting files archive.8.3.4Clause 2 - Query and Refresh function-Related Items8.3.4.1 The query language used to implement the queries must be identified (e.g., “RALF/SQL-Plus”).8.3.4.2 The version number, release number, modification number, and patch level of QGen must be disclosed.
Anymodifications to the QGen (see Clause 2.1.4) source code (see Appendix D) must be reported in the supporting filesarchive8.3.4.3 The executable query text used for query validation must be reported in the supporting files archive along with thecorresponding output data generated during the execution of the query text against the qualification database. Ifminor modifications (see Clause 2.2.3) have been applied to any functional query definitions or approved variants inorder to obtain executable query text, these modifications must be disclosed and justified.
The justification for aparticular minor query modification can apply collectively to all queries for which it has been used.8.3.4.4 All the query substitution parameters used during the performance test must be disclosed in tabular format, alongwith the seeds used to generate these parameters.8.3.4.5 The isolation level used to run the queries must be disclosed. If the isolation level does not map closely to one of theisolation levels defined in Clause 3.4, additional descriptive detail must be provided.8.3.4.6 The details of how the refresh functions were implemented must be reported in the supporting filesarchive(including source code of any non-commercial program used).8.3.5Clause 3 - Database System Properties Related Items8.3.5.1 The results of the ACID tests must be disclosed along with a description of how the ACID requirements were met.All code (including queries, stored procedures etc.) used to test the ACID requirements and their entire output mustbe reported in the supporting files archive.8.3.6Clause 4 - Scaling and Database Population Related Items8.3.6.1 The cardinality (e.g., the number of rows) of each table of the test database, as it existed at the completion of thedatabase load (see Clause 4.2.5), must be disclosed.8.3.6.2 The distribution of tables and logs across all media must be explicitly described using a format similar to that shownin the following example for both the tested and priced systems.Comment: Detailed diagrams for layout of database tables on disks can widely vary, and it is difficult to provideexact guidelines suitable for all implementations.
The intent is to provide sufficient detail to allow independentreconstruction of the test database. The table below is an example of database layout descriptions and is not intendedto describe any optimal layout for the TPC-H database.Table 12: Sample Database Layout DescriptionControllerDisk DriveDescription of Content40A0Operating system, root1System page and swap2Physical log3100% of PART and SUPPLIER tables033% of CUSTOMER, ORDERS and LINEITEM tables40BTPC BenchmarkTM H Standard Specification Revision 2.17.1Page 111133% of CUSTOMER, ORDERS and LINEITEM tables234% of CUSTOMER, ORDERS and LINEITEM tables3100% of PARTSUPP, NATION and REGION tables8.3.6.3 The mapping of database partitions/replications must be explicitly described.Comment: The intent is to provide sufficient detail about partitioning and replication to allow independent reconstruction of the test database.8.3.6.4 Implementations may use data redundancy mechanism(s).
The type of data redundancy mechanism(s) and anyconfiguration parameters (e.g., RAID level used must be disclosed for each device). If data redundancymechanism(s) are used in an implementation, the logical intent of their use must be disclosed. Four levels of usageare defined in clause 8.3.5.4.1:- Base Tables- Auxiliary Data Structures- DBMS Temporary Space- OS and DBMS Software (binaries and configuration files)8.3.6.4.1 Storage Redundancy−Storage Redundancy Level Zero (No Redundancy): Does not guarantee access to any data on DurableMedia when a single Durable Media failure occurs.−Storage Redundancy Level One (Durable Media Redundancy): Guarantees access to the data on DurableMedia when a single Durable Media failure occurs.−Storage Redundancy Level Two (Durable Media Controller Redundancy): Includes Redundancy Level Oneand guarantees access to the data on Durable Media when a single failure occurs in the storage controllerused to satisfy the redundancy level or in the communication media between the storage controller and theDurable Media.Storage Redundancy Level Three (Full Redundancy): Includes Redundancy Level Two and guaranteesaccess to the data on Durable Media when a single failure occurs within the Durable Media system,including communications between database host system(s)/server(s) and the Durable Media system8.3.6.5 The version number, release number, modification number, and patch level of DBGen must be disclosed.
Anymodifications to the DBGen (see Clause 4.2.1) source code (see Appendix D) must be reported in the supportingfiles archive.8.3.6.6 The database load time for the test database (see Clause 4.3) must be disclosed.8.3.6.7 The data storage ratio must be disclosed. It is computed by dividing the total data storage of the priced configuration(expressed in GB) by the size chosen for the test database as defined in Clause 4.1.3.1.
Let r be the ratio. Thereported value for r must be rounded to the nearest 0.01. That is, reported value=round(r,2). For example, a systemconfigured with 96 disks of 2.1 GB capacity for a 100GB test database has a data storage ratio of 2.02.Comment: For the reporting of configured disk capacity, gigabyte (GB) is defined to be 2^30 bytes. Since diskmanufacturers typically report disk size using base ten (i.e., GB = 10^9), it may be necessary to convert the advertised size from base ten to base two.8.3.6.8 The details of the database load must be reported in the supporting files archive .
Disclosure of the load procedureincludes all steps, scripts, input and configuration files required to completely reproduce the test and qualificationdatabases. A block diagram illustrating the overall process must be disclosed.8.3.6.9 Any differences between the configuration of the qualification database and the test database must be disclosed.8.3.6.10 The memory to database size percentage must be disclosed. It is computed by multiplying by 100 the total memorysize priced on the SUT (see clause 6.2.1 ) and dividing this number by the size chosen for the test database asTPC BenchmarkTM H Standard Specification Revision 2.17.1Page 112defined in Clause 4.1.3.1.
Let r be this ratio. The reported ratio must be rounded to the nearest 0.1. That is, reportedvalue=round(r,1). For example, a system configured with 256GB of memory for a 1000GB test database has amemory/database size percentage of 25.6.8.3.7Clause 5 - Performance Metrics and Execution Rules Related Items8.3.7.1 Any system activity on the SUT that takes place between the conclusion of the load test and the beginning of theperformance test must be fully reported in the supporting files archive including listings of scripts, command logsand system activity.8.3.7.2 The details of the steps followed to implement the power test (e.g., system boot, database restart, etc.) must bereported in the supporting files archive.8.3.7.3 The timing intervals (see Clause 5.3.7) for each query and for both refresh functions must be reportedfor the powertest.
The output for each query and for both refresh functions must be reported in the supporting files archive.8.3.7.4 The number of query streams used for the throughput test must be disclosed.8.3.7.5 The start time and finish time for each query stream for the throughput test must be disclosed. The output for eachquery stream for the throughput test must be reported in the supporting files archive.8.3.7.6 The total elapsed time of the measurement interval (see Clause 5.3.6) must be disclosed for the throughput test.8.3.7.7 The start time and, finish time for each refresh function in the refresh stream for the throughput test must bedisclosed.
The output of each refresh function in the refresh stream for the throughput test must be reported in thesupporting files archive.8.3.7.8 This clause is left blank.8.3.7.9 The computed performance metric, related numerical quantities and the price/performance metric must be disclosed.8.3.7.10 The performance metric (QphH@Size) and the numerical quantities (TPC-H Power@Size and TPC-H Throughput@Size) from both of the runs must be disclosed (see Clause 5.4).8.3.7.11 Any activity on the SUT that takes place between the conclusion of Run1 and the beginning of Run2 must be fullydisclosed including system activity, listings of scripts or command logs along with any system reboots or databaserestarts.8.3.7.12 All documentation necessary to satisfy Clause 5.2.7 must be made available upon request.8.3.7.13 The output of the Query Output Validation Test must reported in the supporting files archive.8.3.8Clause 6 - SUT and Driver Implementation Related Items8.3.8.1 A detailed textual description of how the driver performs its functions, how its various components interact and anyproduct functionalities or environmental settings on which it relies and all related source code, scripts andconfiguration files must be reported in the supporting files archive.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
