TPC-DS标准规范(7)

TPC-DS是一套决策支持系统测试基准，主要针对零售行业。提供99个SQL查询（SQL99或2003），分析数据量大，测试数据与实际商业数据高度相似，同时具有各种业务模型（分析报告型，数据挖掘型等等）。国内目前相关的翻译文章较少。本文尝试对官网的TPC BENCHMARK DS Standard Specification（下称“原文”）进行翻译。翻译主要参照的是2017年发布的2.6.0版本。

由于原文一共137页，本文在翻译的时候会进行一定的压缩，突出较为关键的信息。本文章节名称，序号，小标题等均严格按照原文翻译排序。

8 SUT与驱动实现

本节定义了SUT和基准驱动。

8.1 测试配置模型

8.1.1 被测配置其实就是一个驱动和一个SUT。驱动向SUT发查询，SUT执行，之后把结果返回给驱动。从硬件和软件角度来说，驱动是安装在SUT的硬件和软件里面的。

8.1.2 图8-1描绘了驱动程序/SUT配置的示例。阴影区域代表驱动，该图还描绘了测量时间间隔的驱动器/SUT边界（见第7.1.16节和第7.4节）。

8.2 被测系统(SUT)定义

8.2.1 SUT由以下几部分组成：

a) 主机系统或服务器，包括支持访问数据库（指的是性能测试用的数据库）的硬件和软件。

b) 用于执行查询的任何客户端处理单元（例如，前端处理器，工作站等）。

c) 与用户界面设备通信所需的硬件和软件组件。

d) 连接和支持SUT组件所需的所有网络的硬件和软件组件。

e) 满足第3节中的缩放规则，第1.6节中的数据访问属性，以及第7.5节中描述的数据的要求的数据存储介质。

8.2.2 所有SUT组件，如第8.2.1节所述，应为市售的软件或硬件产品。

8.2.3 可以在SUT上实现特定层，该层应逻辑上位于驱动程序和SUT之间，如图8-2所示。

8.2.4 如果特定层在SUT上，则层应该是通用的（即不限于TPC-DS查询使用）。特定层的源代码必须披露，其功能应严格限于以下内容：

a) 在每条查询执行前或执行完的时间段里，进行数据库的交易控制。

b) EQT的游标控制及操作。

c) 处理动态SQL所需的过程和数据结构的定义，包括EQT与SUT的层（这些层需要是市面上可以购买到的层）的通信，以及查询输出数据的接收。

d) 与SUT的层（这些层需要是市面上可以购买到的层）的通信

e) 缓冲查询输出数据。

f) Communication with the drivere it

以下是实现特定层不能执行的功能的示例：

a) 对可执行文件的任何修改。

b) 任何使用存储过程来执行查询。

c) 查询输出数据的任何排序或翻译。

d) 7.2.8.1节禁止的任何功能。

8.3 驱动定义

8.3.1 驱动是指一个可以由一个或多个程序，进程，或系统实现的逻辑实体，它负责向SUT提交工作负载。驱动的功能只能是以下几种：

a) 生成唯一的流ID，每个查询流都是从1开始。

b) 按照查询顺序执行查询。

c) 激活，调度和/或同步数据维护功能的执行。

d) 生成每个查询的EQT。

e) 生成每个查询的替换参数的值。

f) 将生成的替换参数值替换进去，如果有需要也可以把相应的文本的流ID替换。

g) 将每个完整的EQT发给SUT供其执行，如果每个查询对SUT返回结果的行数有要求，驱动也要告知SUT。

h) 将每个数据维护方法发给SUT供其执行。

i) 接受SUT返回的查询执行结果数据集。

j) 测量查询和数据维护方法的执行时间并进行统计。

k) 维护查询文本以及输出结果集的工作日志。

8.3.2 用于发给SUT执行的EQT，其生成过程不应该发生在SUT上，生成耗时也不应计入任何测试时间。

8.3.3 驱动不应该有8.3.1节以外的任何功能，比如：

a) 驱动不应该有8.3.1节以外的任何表现，行为，同步，或操作。

b) 对两个查询执行之间加入任何在8.3.1中不必要的延迟。如果有加入延迟的需要，延迟只能加在同一个流内相邻两个查询间，时长不能超过半秒。加入延迟必须在报告中注明。

c) 在发给SUT之前修改了EQT的兼容性。

d) 将查询文本嵌入执行计划或者程序中。

e) 向SUT提交一个查询替换参数的值，该值并不包括在这个查询的原文本中。

f) 向SUT提交，用于数据维护功能/兼容EQT/要求的结果集返回行数，以外的任何数据。

g) 人为延长任何查询的执行时间。

8.3.4 驱动价格不计入总价。