1．引言
目前，电子信息化系统朝着大数据量、大用户访问量和复杂分析业务的方向发展。传统的数据库使用方式已经不能满足企业用户的需求。只有实时采集数据，才能正确的处理决策支持，降低了信息处理和传输延迟，才能保证快速的业务响应，只有合理的分担用户的访问压力，才能提升系统的反映速度，带来更好的用户体验。
随着十二五规划国家重大专项的制定发布，将国产数据库的发展列入国家基础软件重点支持对象之一。同时，国产数据库的应用也变得越来越广泛，目前需要对国产数据库的质量与国外数据库质量进行对比的需要日益迫切，而重点又围绕着数据库处理的效率问题。然而，对于所有数据库而言，处理记录正确的处理结果之外，也面临着一系列的挑战：高速的处理速度，数据的高可用性、数据的安全性和数据集可扩展性等。一种有效的数据库集群的功能和效率的验证方法对国产数据库研发质量评估提着重要作用。本文提出了一种数据库集群的功能和效率的验证方法，在项目实践中证明行之有效。
2．相关技术
2.1 数据库集群
数据库集群，一组完整的自治的计算处理单元，每台都运行一个完整数据库实例，通过高速专用网络或商业通用网络互联，彼此协同计算，作为一个统一的数据库系统提供外围服务。数据库集群有若干中体系结构，其中最重要的是共享磁盘结构（Share Disk）和无共享结构（Share Nothing） [1] 。
共享结构的数据库集群，所有节点共享同一个磁盘存储系统，或者通过操作系统层提供一个全部磁盘系统的统一视图。当前流行的Oracle RAC就是一种共享存储的体系结构，并且集成了高速缓存融合技术 [2] 。
非共享结构的数据库集群，每个节点都有自己的磁盘存储系统和内存系统，数据库中的数据依据数据模型和应用特点划分到各个站点上，也可在站点上复制某些数据形成冗余数据，提供数据可靠性和高可用性。IBM公司的DB2的UDB（Universal DataBase，UDB）就是一种典型的无共享结构的并行数据库集群 [3] 。
2.2 TPC-C
TPC-C测试标准是TPC（Transaction Processing Performance Council）委员会于1992年公布的一个用于衡量在线事务处理性能和性能价格比（performance/cost）的测试基准 [4] 。TPC-C测试标准的主要设计目标是：1）模拟包括更新操作和只读操作的多类型事务；2）模拟不同特征的事务处理，包括在线式（对响应时间有严格要求）和延时式（对响应时间的要求比较宽松）；3）所有事务必须严格符合ACID特性;4）拥有复杂的数据结构和联系；5）采用多样的数据访问方式；6）模拟重负载下达数据库上的多用户并发操作。 [5]
该模型一共设计了九张表，反映了OLTP应用环境：一个大型商品批发商，它拥有若干个分布在不同区域的商品库和销售点，每个仓库负责10个销售点供货，每个销售点为3000个客户提供服务，每个客户平均一个订单有10项产品，所有订单中约1%的产品在其直接所属的仓库中没有存货，需要由其他区域的仓库来供货。该系统处理5种事务：New-Order（客户端输入一笔新订货交易）；Payment（更新客户账户余额）；Delivery（发货，模拟批处理交易）；Order-Status（查询客户最近交易的状态）；Stock-Level（查询仓库库存状态）。TPC-C的主要性能指标有：tpmC，每分钟处理的事务数；性价比，Price/tpmC。
2.3 TPC-H
TPC-H是TPC委员会于1999年公布的衡量硬件和软件对DSS（decision support system,决策支持系统）支持能力的性能基准 [6] 。TPC-H包含了一组面向商业的随机查询和数据更新，查询操作和用于数据更新的数据都适用于商业环境，同时查询和更新并发进行 [7] 。
TPC-H性能测试基准是以零件的采购和订购为模型，业务表示零件采购和订购行为中不同角色或不同的过程，如图所示，其中TPC-H基准还定义了22个复杂查询语句和2个更新数据语句，用这些复杂查询来考察被测试数据库的联机分析性能。
3．测试方法
3.1 功能验证
功能验证测试主要集中在数据库的负载分担能力和故障透明切换能力两个方面。负载分担能力主要体现在当用户访问数据库时，其中有某个数据库节点出现故障，系统可以将访问到这个故障节点的应用透明的转移到其他正常节点上。负载分摊能力主要体现在当有多个用户同时访问数据库时，数据库可以将用户均等的分摊到多个数据库节点上。验证方法的思想通过单用户访问测试来验证系统的故障透明转换能力，单用户访问集群后，查询数据库的动态视图查询目前会话所在的节点，将其关闭，然后查询此会话是否已经切换到另外的节点上；通过多用户访问测试来验证系统的负载分摊能力，多个用户访问系统后，查询数据库的动态视图查询多个节点上会话的分配情况来验证其能力。
下面以OracleRAC集群为例进行功能验证测试，测试前先配置好Oracle的RAC集群方式，这里不详细介绍，主要集中介绍功能能验证的测试方法。
（1）透明切换功能验证
第一步：在OCI客户端修改tnsname文件中配置，使OCI客户端可以连入Oracle RAC集群；
第二步：通过sqlplus连接到数据库中，并通过SQL语句查看系统动态视图查看目前所连接的节点名字，语句如下” select instance_name from v$instance;”， 并记录显示的节点名；
第三步：将第二步显示的节点名所在的机器关闭，然后再使用” select instance_name from v$instance;”语句查询所连接的节点，并记录显示的节点名字；名字发生变化，OCI客户端可以正常使用；
第四步：给出结论，节点名字发生变化发生，证明故障节点的自动透明切换功能运行正常。
（2）负载分摊功能验证
第一步：在OCI客户端修改tnsname文件中配置，使OCI客户端可以连入Oracle RAC集群；
第二步：在OCI客户端启动多个会话；
第三步：分别在数据库集群的节点上通过”select count( * ),machine from v$session group by machine;”查看会话个数；
第四步：给出结论，节点上存在的会话数几乎均等，证明系统负载分摊功能正常运行。
3.2 TPC-C效率测试
TPC-C效率测试主要集中在针对OLTP的数据库模型对数据库集群进行效率验证，主要考察在集群情况下系统的TPC-C的吞吐量（即在一定仓库和并发用户数的前提下，5中事务混合情况下每分钟还可以接受新订单的个数）和系统处理过程中的资源特性。
本文的TPC-C的效率测试主要采用开源工具orabm搭建具有TPC-C的物流模型，在模拟大量并发用户的同时，利用开源工具hammerora生成事务请求，然后与数据库集群系统进行交互，同时通过监控待测数据库集群系统的性能，进而收集测试的结果并分析。
测试方法如下：
第一步，采用orabm构建TPC-C的标准测试环境。建立TPC-C模型的数据表，加载指定仓库数的数据，创建索引，分析表和索引，创建压力测试PL/SQL过程，表和索引数据都缓冲到内存中提供数据的访问效率；
第二步，采用hammerora内置的脚本来驱动并运行基准测试，同时实现对数据库的多个并发线程的连接。
第三步，收集数据库的性能指标，包括测试过程中获取的某时刻的TPS值和每秒钟逻辑读写的事务数。
第四步，通过上述步骤针对单机的数据库与集群的数据库系统进行同等参数设置下的TPC-C基准测试，对比其测试结果以验证集群环境下的数据库性能。
3.3 TPC-H效率测试
TPC-H效率测试主要集中在针对OLAP的数据库模型对数据集群进行效率验证，主要考察两类事务，一类是查询事务，包括22条复杂查询语句，一类是更新事务，包括2条更新数据。在此测试中，主要考察数据库的Power测试和Throughput测试。Power测试模拟单个查询流和更新流；Throughput测试模拟多个并发用户，即多个查询流和多个更新流。在这里，我们简化TPC-H的计算方式，而统计22条查询语句和2条更新语句（插入数据和删除数据语句）在单流和多并发下的不同规模的数据情况下的响应时间来评估集群数据库的在线分析系统的效率。具体的SQL语句形式可参见TPC-H模型的说明书，这里不加熬述。
TPC-H的测试方法思想如下：在Power测试中，构建单执行的SQL语句流，时序形式是先插入数据语句，再执行22条查询语句，然后执行删除语句；在Throughput测试测试多个查询流（即22条查询语句）和插入删除语句并发执行。在测试过程中，选用商业化的测试工具LoadRunner的ODBC方式来执行上述两类测试，具体的步骤如下：
第一步，通过TPC-H网站的数据生成工具DBGEN生成待测试的数据量，大小由测试人员和数据库使用者决定，并将生成的数据导入到待测试的数据库中；
第二步，通过TPC-H网站查询语句生成工具的QGEN产生相应的待测试SQL语句；
第三步，采用LoadRunner的ODBC脚本编辑第二步产生的SQL语句形成Power测试单用户脚本和Throughput测试多用户并发脚本；同时设置好单个SQL语句的事务点，用于统计响应时间；
第四步，配置单用户和多用户并发场景，执行Power和Throughput测试，同时收集数据库服务器端的性能数据，包括CPU，内存，磁盘和网络等资源占用情况；
第五步，上述步骤应用于单数据库和集群数据库下，对比其测试结果，验证集群环境下数据库运行在OLAP模型下的效率。
4． 结束语
本文提出了验证集群数据库功能和效率的验证测试方法，主要针对集群数据库的故障转移能力、负载分摊能力和数据库运行在OLTP和OLAP环境下效率验证。同时提出详细的实施方法和步骤，在核高基国产基础软件评估课题中加以验证，结果客观具有代表性，保证了国产数据库的研发质量。
