基于TPCC基准数据库系统性能测试的实现计算机系毕业论文(DOC 45页).doc

1、本 科 生 毕 业 论 文（设 计）中文题目：基于TPC_C基准数据库系统性能测试的实现外文题目：The Implementation of Database System Performance Testing Based on TPC_C Benchmark41 / 45基于TPC_C基准数据库系统性能测试的实现摘 要数据库系统是目前web系统普遍使用的系统，当前有很多流行的数据库，比如DB2,Oracle、SQL等大型数据库，数据库系统的性能决定着系统的总体性能，数据库的性能如何评价，评价的指标都包含哪些容等问题都是对数据库进行整体评价必须做出回答的。基于以上的问题，本文主要介绍了数据库

2、性能的评价指标、测试方法、容，以SQL数据库为测试对象，实现了基于TPC_C（TPC BnechmarkTM C）测试基准的测试事务模型，并采用当前流行的数据库测试软件LoadRunner通过脚本的录入、不同场景设置等对该系统进行测试，找出系统的瓶颈并进一步提出该进方案。关键词：数据库SQL Sever LoadRunner 性能测试The Implementation of Database System Performance Testing Based on TPC_C BenchmarkAbstractDatabase system is a system commonly used

3、in web systems, currently there are many popular databases such as DB2, Oracle, SQL Sever etc. The database systems performance determines the overall system performance. How to make an overall evaluation of the performance of the database? What evaluation indicators should be included? All these is

4、sues about the overall evaluation of the database must be made to answer. Accounting for the above issues, this paper describes the performance evaluation of database, test methods.Content to SQL database as the test object, this paper achieves the TPC_C (TPC BnechmarkTM C) benchmark tests based on

5、transaction model and uses the popular database test softwareLoadRunner to make test on the system by script entry and different scene settings to identify system bottlenecks and further into the scheme of the improvement.Key Words:Database SQL SeverLoadRunnerPerformance Testing目 录摘要IABSTRACTII目录III

6、1绪论11.1 课题研究背景与意义11.2 国外数据库性能测试的研究状况11.3 本文的主要工作41.4 本文组织结构42数据库性能测试52.1数据库性能测试方法与容52.1.1 性能测试分类52.1.2 性能测试指标62.2 性能测试工具LoadRunner介绍72.2.1 LoadRunner的特点72.2.2 LoadRunner功能描述82.2.3 LoadRunner测试步骤83. 基于TPC_C基准事务的实现93.1 TPC_C基准总述93.1.1 TPC_C 简介93.1.2 TPC_C测试指标103.2 基于TPC_C基准数据库设计123.2.1 SQL Server 2000

7、 中表的设计123.2.2 表的结构关系143.2.3 TPC_C基准数据录入153.3 基于TPC_C基准事务模型的实现173.3.1 NEW ORDER（新订单）事务的实现173.3.2 PAYMENT（支付）事务的实现193.3.3 DELIVERY（发货）事务的实现213.3.4 STOCK LEVEL（库存状况查询）事务实现223.3.5 ORDER STATUS（订单状况查询）事务的实现224. 测试方案与结果分析244.1 测试方案244.2 测试场景设置294.3 测试结果分析324.4 系统瓶颈分析385. 全文总结和展望405.1全文总结405.2 展望40参考文献41致4

8、21绪 论1.1 课题研究背景与意义随着软件业的迅猛发展，系统开发的结构层次在不断地加深，数据库从以前一个默默无闻的后台仓库，逐渐演变为今天的数据库系统，他在很多系统的设计中起着举足轻重的作用，对于其性能的要求也越来越高，数据库测试开发也逐渐演变出一些适合其特点的测试方法和工具7。数据库的测试同其他软件测试一样，包含性能测试和功能测试两种。其中功能测试的目的是验证系统是否实现了用户要求的所有功能要求；而性能测试的目的是验证软件系统是否能够达到用户提出的性能指标发现软件系统中存在的性能瓶颈，最后起到优化系统的目的。评价一个数据库仅仅通过其功能是否实现是远远不够的，性能的好坏与否也是一个非常重要的

9、指标。目前，有各种各样的功能强大的数据库测试工具，但是能正确的使用工具开发合适的脚本、创建测试场景和正确的根据自己需要的测试参数选择合适的测试工具是需要丰富的经验与技巧的。基于前人的经验，本文具体分析和实现了基于TPC_C基准的数据库性能测试。1.2 国外数据库性能测试的研究状况随着数据库性能测试的不断升温，对数据库的测试方法和容也是层出不穷。清华大学就曾对通用海量数据库性能的测试和实现6进行了研究。在这篇论文中作者为了能够反映出数据库实际的运行性能，其设计了一种可配置数据库性能的测试基准，这种基准能够针对具体的应用数据库系统，建立吸纳供应的控制模型。这个基准包含了几种模型，包括控制模型、数据

10、模型和事务处理模型，其中控制模型主要是描述了数据库的运行模式，而数据模型则描述的是用户访问数据库的数据集合，事务处理模型主要是描述用户访问数据库的行为模式。控制模型同事务处理模型和数据库模型组装动态SQL语句，然后产生多个并发进程模拟大量实际用户访问数据库，以测试数据库的运行状况和性能。这个测试标准，与目前国际上通用的固定模型测试标准如TPC_C等相比，更能够客观反映数据库实际运行性能。这说明，在国我们也开始慢慢寻找出更加符合实际的标准来对数据库进行测试。但是这一项目仅对数据库的正确性和可用性进行了相关设计和实现，如果要想形成像TPC_C那样通用的且能对数据库的各方面性能都能进行测试的方案，还

11、需要进一步的研究。东北大学就曾对TPC_C测试标准与其在面向对象数据库14上的设计与实现一文中也指出，数据库测试标准主要用途是数据库的开发者通过对其系统的性能测试和评价，而对系统进行改进和完善，用户根据不同系统的测试数据，而选择性能优良的系统。作为新生代的面向对象数据库系统，OO数据库系统可在具有复杂数据结构的场合得到应用，并且其也可能广泛地应用于在线事务处理中。但是为我们所熟知的TPC-C基准仅给出了数据模型、事务处理和测试指标的定义，研究数据库测试技术以与TPC-C基准在面向对象数据库中的使用也是大有裨益。由以上两个方面的例子可以说明，在国，不管是研究新的测试标准研究在现有标准上增加新的应

12、用等方面都开展了许多工作，相信在不久的将来，国将会出现一套完整的数据库测试方法。数据库系统测试作为软件测试的一个重要分支，在详细阐述其之前，我们有必要对软件测试进行一个概述。鉴于目前国对软件测试的重视程度在不断地提高，许多软件测试方面的材料和研究也在不断地推进，以前的那种对软件测试“可有可无”的态度得到了很大的改善，他已变成了软件开发的一个必不可少的一个环节，很多软件开发公司都有自己的软件测试小组。所谓的软件测试一般看来就是根据软件开发各阶段的制约和软件的部结构，精心设计很多的测试用例，包括一些极端的测试用例，这些用例的容包括输入数据以与预期的输出结果，应用这些测试用例来不断地运行程序，发现其

13、中不符合质量的特性要求，亦即软件的缺陷和错误。另一方面，软件的测试是贯穿整个软件开发的生命周期中，所以软件的需求设计、规格说明书以与程序等都要包含测试的相关容。至于数据库测试种类，从测试过程的角度可以分为系统测试、集成测试和单元测试。接下来对这几种测试进行简要介绍。一、系统测试系统测试包括了不同的测试组成部分，其主要目的就是充分地运行系统，并进一步验证系统各部件是否都能够正常地完成所赋予的任务，所以当产品需求和系统设计的文档完成以后，系统测试的小组成员就应该提前开始制定出相应的测试计划和设计几个不同的测试用例，不必等到“实现与测试”阶段完成以后在进行。这样做的一个主要目的就是可以大幅提高系统测

14、试的效率。其测试工具有主要用于评估测试各种不同系统参数下的数据库负载情况的模块化、跨平台、多线程基准测试工具sysbench。这一阶段的测试主要是通过数据库设计评审来实现。二、集成测试集成测试主要是对接口进行的测试工作。其主要考虑的是容包括数据项的修改操作、数据项的增加操作、数据项的删除操作、数据表空、数据表满、删除空表中的记录、数据表的并发操作、针对存储过程的接口测试、结合业务逻辑做关联表的接口测试。等价类、边界值、错误猜测等是其采用的主要方法。三、单元测试对于一个软件，要确保其功能是按照最先设计实现，我们可以创建一组测试并在开发过程中使用，这就是所谓的但也测试。单元测试主要侧重的是逻辑覆盖

15、，其可以通过语句覆盖和走读的方式完成。数据库单元测试是测试应用程序不同组成部分间所使用的数据。比如当一个应用程序升级或是重新开发，用户便可设置单元测试用例，验证这个应用程序的数据输出在不同的版本间是否是一致的10。随着数据库测试的不断发展，现在在数据库功能的测试领域中有许多的工具，例如DBunit、QTP、DataFacory等，其中DBunit是一款开源的数据库功能测试框架，其可以使用类似于Junit的方式对数据库的基本操作进行白盒单元测试，对输入输出进行校验。QTP是一款自动测试工具，其通过对对象的捕捉和识别，模拟用户的操作流程，并通过校验方法或结合数据库后台的监控对整个数据库的数据进行测

16、试。DataFactory是数据自动生成工具，通过它可以生成任意的结构数据库，并实现对数据库的填充，可以根据需要产生大量的数据以帮助验证数据库中的各种功能是否正确。1.3 本文的主要工作鉴于目前专门对数据库性能测试的研究还有待深入研究，现有的测试方法缺少了对数据库性能的详细评测，本文研究的创新点和主要容如下：1、对数据库测试的容、指标进行更加深入详细的归纳总结。2、对TPC_C基准数据库的设计与事务模型的实现进行详细的描述。3、本文的实践是基于数据库性能测试标准和数据库负载测试工具Loadrunner，详细介绍了从脚本录制修、测试场景设计到最后测试结果分析的整个过程，为以后对Loadrunne

17、r工具的使用提供参考。1.4 本文组织结构第一章介绍课题背景、国外数据库性能评测基准领域的研究状况以项目的主要工作等。第二章介绍数据库性能测试的主要方法、容、主要测试工具LoadRunner，为课题的设计和实现奠定基础。第三章对TPC_C做了介绍，并详细分析和实现了基于TPC_C基准的事务模型。第四章提出测试方案，并对测试的结果进行分析，与TPC_C提供的标准进行对比，找出系统的瓶颈。第五章对全文进行总结和展望，指出项目的不足和改进的空间。2数据库性能测试2.1数据库性能测试方法与容数据库测试属于软件测试测试中的一类，一般从以下三个方面进行分类：从透明度分为黑盒测试和白盒测试；从开发过程可分为

18、单元测试、集成测试、系统测试等；专门性的测试还包括安全性测试、性能测试和存测试等。由于本文主要针对的是数据库的性能测试，接下来对性能测试的容和指标进行介绍：2.1.1性能测试分类广义的性能测试通常包括压力测试、负载测试、疲劳强度测试、并发（用户）测试、大数据量测试、配置测试、可靠性测试、安全性测试等和性能相关的测试10。通常一次测试也是包括这几种测试中的多种的。以下简要对这几种测试的概念进行具体介绍。（一）负载测试负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、存）

19、等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、存泄漏、不能实时同步等问题。1、负载测试是站在用户的角度去观察在一定条件下，软件系统的性能表现。2、负载测试的预期结果是用户的性能需求得到满足。这些需求指标一般体现为响应时间、交易容量、并发容量、资源使用率等。（二）、压力测试压力测试是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下表现状况，从而有效地发现系统的一些功能隐患、系统的容错能力和可恢复能力是否良好等等。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。一般来说，压力测试就是让系统在极端的条件

20、下工作，查看系统的表现，并且这种极端条件是高于系统用户的需求的。（三）、并发测试并发测试是性能测试的最主要部分，其重点关注的是多个用户同时访问同一个应用模块或者是数据是否存在性能问题。它是通过一个包含了负载测试和压力测试的过程，分析各种交易执行指标和资源监控指标来确定系统并发性能的过程。（四）、可靠性测试可靠性测试指通过给系统加载一定的业务压力的情况下，让系统在尽量真实环境下或者仿真的使用环境下运行一段时间，测试系统在这种条件下能否稳定运行。可靠性测试可以有效的暴露在实际使用过程中影响可靠性要求的缺陷。它介于功能测试和性能测试之间，是在功能实现的基础上更接近模拟现实环境下的测试。2.1.2 性

21、能测试指标要进行软件性能测试，首先需要知道软件测试中有哪些性能指标，否则软件的性能测试就无从做起。常见的性能测试指标主要包含以下容：（一）、吞吐量/处理能力处理能力又叫吞吐量，指的是单位时间处理的客户端请求数量。通常，吞吐量用请求数/秒或页面数/秒来衡量。（二）、负载负载分为客户端负载和服务器端负载，客户端负载的简单说就是有多少个用户在同时使用软件，服务器端负载的就是有多少个请求同时到达了服务器端，要求服务器进行处理。（三）、响应时间响应时间是可以判断一个被测应用系统是否存在性能瓶颈的最直观的要素。响应时间一般分为最大响应时间、最小响应时间和平均响应时间。（四）、同时在线用户数量同时在想用户对

22、本系统来说就是在同一时刻，执行各个事务的用户数量总和。（五）、TPS (Transactions Per Second)是应用系统每秒钟完成交易的数量，是估算应用系统性能的重要依据。系统整体处理能力取决于处理能力最低模块的TPS值。2.2 性能测试工具LoadRunner介绍现在软件测试行业里有很多的软件测试软件，但是LoadRunner得到了广泛的应用，综合起来，LoadRunner适用围很广，它可以适用于各种体系架构，其还是自动负载测试工具。它能够模拟上成千上万个并发用户，同时向服务器发送请求，并记录和分析测试结果，最终帮助企业快速、有效的查找和发现问题，通过使用LoadRunner，企业

23、能最大限度地缩短测试时间、优化性能和加速应用系统的发布周期。此外，LoadRunner能支持广的协议和技术，为一些特殊环境提供特殊的解决方案23。2.2.1 LoadRunner的特点LoadRunner的具体特点表现为如下两点：1、轻松创建虚拟用户采用LoadRunner的Virtual User Generator，可以录入我们需要测试脚本并进行修改，进一步可以很简便地创立起系统负载。录入脚本的过程其实就是其记录业务操作流程，但是这个仅是流程的某一个分支，如果需要完整地运行程序，代码的修改是必不可少的。通过这个虚拟用户产生器，可以虚拟用户并模拟真实用户的业务操作行为。利用虚拟用户，可以在W

24、indows上同时产生成千上万个用户访问。所以LoadRunner能极大的减少负载测试所需的硬件和人力资源。2、创建真实的负载Virtual users建立起后，我们可以设定具体的负载方案，业务流程组合和虚拟用户数量。这主要是使用LoadRunner的Controller，通过不同的场景设置，可以组织起多用户的测试方案，更好地对系统进行全方位的测试。2.2.2 LoadRunner功能描述LoadRunner包含很多组件，最为我们所使用的有Visual User Generator、Controller和Analysis，其中Virtual User Generator（虚拟用户生成器）主要是

25、用于录制测试脚本；Controller（中央调度器）主要是通过场景设置控制模拟用户个数和并发数，进一步设置测试的调度方案，执行脚本并记录测试结果，包括缺陷报告和测试日志； Analysis（结果分析器）用于统计和分析测试结果，确定是否与发布的基准要求相符合。2.2.3 LoadRunner测试步骤LoadRunner是一个很好使用的测试软件，欲采用其完成相应的测试，只需要完成以下四个步骤：第一步：使用Virtual User Generator 创建脚本，具体为1、选择协议（该软件支持的协议有很错，根据不同的测试程序选用不同的协议），接着创建脚本 2、录制脚本，录入过程选择在action里3、

26、编辑脚本，因为其录制的只是事务的一个分支4、检查修改脚本是否有误，直至正确第二步：使用Controller来调度虚拟用户，具体为1、选择欲测试脚本，并创建场景2、设置机器虚拟用户数，运行时间等3、设置调度方案4、如果模拟多机测试，设置Ip Spoofer 第三步：运行脚本 分析场景，尽力保持系统没有别的程序在运行，这样可以更精确地知道整个测试过程所占用的资源数第四步：分析测试结果3.基于TPC_C基准事务的实现3.1 TPC_C基准总述3.1.1 TPC_C 简介基准TPC_C，即TPC BnechmarkTM C，是TPC(Transaction Processing Performance

27、 Council)委员会发布的数据库测试基准之一，该标准第一版于1992年7月批准并首次发布5。TPC_C是复杂联机事务处理（OLTP）应用环境工作量的一个衡量标准，其并不实际表示某一个企业所进行的操作，但是其高度提炼了所有企业都必须进行的操作，比如管理或销售产品或是服务。它模拟的是被复杂话了的联机事务处理应用环境的创建活动，其主要是把许多系统组成部件和特定环境关联起来实现的1，这种环境具有如下的一些表现：1、 能够并行执行的事务是有一定复杂度的2、 具有可在线处理事务执行的模式3、 支持多个线终端活动4、 较好地协调系统运行和应用程序执行时间5、 通过ACID特性保证事务处理的正确性。6、

28、通过主键和外键能够识别出分配高低优先级数据访问7、 数据库由一些具有各种大小、属性和关联的基本表组成TPC_C基准的目标就是要减少应用层面的多变性，而保留一些重要的应用特征，也即系统的实用性和复杂性。比如一些如登陆系统等操作，对于某些系统来说可能很重要，但是却被TPC_C忽略掉。因为这些功能对于系统的分析来说并没有太大的作用，他们占用系统的资源和执行的频率也不会很高。TPC_C模仿的是一个分布在多个地区都有销售点的公司，随着公司业务的增长，新的Warehouse和销售地区都会随之建立，一个仓库管理10个地区，每个地区为3,000名客服服务，所有的仓库管理公司的100,000条销售，客户可以提交

29、订单订购商品，平均每个订单包含10个订单项。1%的订购商品不在本地库存中，需要其它地区的仓库发货。下图说明了TPC_C应用环境的逻辑结构：图3-1 TPC_C 基准逻辑结构TPC_C的数据模型可描述为:a) 一个大型商品批发商拥有若干个分布在不同区域的商品库;b) 每个仓库负责为10个销售点供货;c) 每个销售点为3000个客户提供服务;d) 每个客户平均一个订单有10 项产品;e) 所有订单中约1%的产品在其直接所属的仓库中没有存货, 需要由其它区域的仓库来供货。3.1.2 TPC_C测试指标TPC-C测试规经过两年的研制，于1992年7月发布。几乎所有在OLTP市场提供软硬件平台的厂商都发

30、布了相应的TPC-C测试结果，随着计算机技术的不断发展，这些测试结果也在不断刷新。 TPC-C的测试结果主要有两个指标： 1、 流量指标(Throughput，简称tpmC) tpmC定义: TPC-C的吞吐量，按有效TPC-C配置期间每分钟处理的平均交易次数测量，至少要运行12分钟。按照TPC的定义，流量指标描述了系统在执行Payment、Order-status、Delivery、Stock-Level这四种交易的同时，每分钟可以处理多少个New-Order交易。所有交易的响应时间必须满足TPC-C测试规的要求。流量指标值越大越好。2、 性价比(Price/Performance，简称Pr

31、ice/tpmC) 即测试系统价格（指在美国的报价）与流量指标的比值。 性价比越小越好。这个指标对于Price无法确定，故在本次测试中不予考虑，重点考虑的是第一个性能指标。结合2.1.1节提出的数据库性能测试指标，包括吞吐量/处理能力、负载、响应时间、同时在线用户数量、TPS 等几项，TPC_C基准提供的五个事务模型各有其特点：NEW ORDER事务模仿在线用户的订单请求，用户输入一份完整的订单，提交系统。该事务执行频率高，要求系统响应时间短。PAYMENT事务更新用户的账户并反映出地区和仓库的销售状况。该事务要求高频读写，所以响应时间必须要快才能满足在线用户的需求。ORDER STATUS事

32、务查询客户上一次订单的状态，是一个只读事务，执行频率低，对系统的响应时间要求不是很严格。STOCK LEVEL事务模拟的是用户从固定的仓库和地区中选取最后20条记录，检查订单中所有货物的库存，计算并且把所有库存数低于用户指定域的商品数量。这个事务是只读事务，执行的频率较低，对系统的响应时间不做严格限制和要求。DELIVERY事务模拟的是对于任意一个客户，随机选取一个发货包，更新被处理的用户的账户余额，并把该订单从新订单中删除。这个事务的执行频率不高，对事物的响应时间也没有严格的限制。通过对这五个事务进行配比的不同体现出事务的执行频率不同，而且每个事务的复杂程度不同，这就可以体现出事务的响应时间

33、的区别。在本次测试过程中，采取的方案是通过设置不同的Vuser数以测试系统的在线用户数，进一步得到系统的TPS、响应时间等指标，具体测试方案详见4.1.1节。3.2 基于TPC_C基准数据库设计3.2.1 SQL Server 2000 中表的设计通过3.1节的介绍，TPC_C的逻辑结构图表明了TPC_C的总体操作流程，为了实现这一结构，TPC_C设计了九个相关的数据表，E-R关系图如下：图3-2 TPC_C基准E-R图表框里的数据表示该表存放的记录数，仓库数W体现了数据库中的数据规模，表间的数据表示各表中记录条数的比例关系，k表示1000。换句话说，给数据库加载数据时，如果给数据表Wareh

34、ouse表装入l条记录的话，那么District须装入10条记录，Customer须装入3000条记录，history须装入30000条记录，Order须装入30000条记录，New-Order须装入9000条记录，Order-Line须装入300000条记录，Stock须装入100000条记录。还需要注意的是，无论Warehouse表记录为多少，item表总数为100000条记录，并不随Warehouse的记录数增加而变化。由于本次测试采用的是单机测试，并且主机的配置不高，而实际每增加一个仓库，数据库就有数以万计的数据加入，这将会花费很多时间，所以Warehouse的数目就做出限制，只有wa

35、rehouse1 和warehouse2.具体的表如下图所示：图3-3 数据表构建图图中红色标注为每表的主键，各键之间的联系如所示类型说明：1.N unique Ids型。该类型要求生成N位数围的ID标识。2. Variable text. Size N型。该类型要求生成一个最大长度不超过N、任意长度、任意字符的变换尺寸文本，并且要求对于字符数小于N的需要用空格填满。3.fixed text，size N型。要求生成一个长度为固定长度N、字符为任意字符的文本。4.data and time型。要求生成一个日期。5.numeric，N digits型。要求生成一个长度为N位十进制的阿拉伯数字字符

36、串。并且，包含货币的数值域必须使用这样的数据类型具有精确度为两位小数的实型。6.numeric(m, n)说明该数总共有m位，其中小数点后n位。本项目的数据库是SQL Server 2000.，在数据库的建立时使用的是SQL脚本建表，格式是如：图3-4 SQL脚本示例如是将所有表项建立完毕，各个表之间通过外键进行约束，这样就构成了TPC_C测试基准数据库的整体结构。3.2.2 表的结构关系TPC_C基准数据库的九表通过主键引用联系起来，各个表都有各自的用途，且各表之间的结构关系（主键）为：图 3-5 各表关系图各表的使用将在事务的使用中进行详细介绍。3.2.3 TPC_C基准数据录入大多数的数

37、据库提供有专门的数据加载工具，这些加载工具具有快速高效的性能，比如说Oracle的Sql*Loader，SQL Sever的DTS等工具。对于国产数据库，有一部分厂商提供了比较高效的数据加载工具，例如可以将具有一定格式的文本数据文件加载到数据库的表中，但同时一些厂商没有提供或是提供的加载工具效率不高，如果采用这些加载工具就很浪费时间。8在本项目中数据的加载主要是通过C#编写代码实现的。图3-6 数据加载方案以下是对整个数据加载过程的定义说明： random 表示在指定围随机生成一个数。randomx,y表示从x到y的围中随机选择一个数，一般平均数为(x+y)/2。产生的数的个数也会由于所要求的

38、精度不同而发生变化。比如random0.01,100.00产生的随机数就为100，000个而random1,100产生的随机数个数为100个。random a-string x . y 随机产生一个字符串，其最小长度为x，最大长度为y，平均长度为(x+y)/2。可以是字母字符串也可以是数字字符串。采用的算法是通过产生随机数来的到字符串的长度N，然后再随机产生长度为N的字符串。4、C_LAST是Customer表中的一项，其产生采用以下机制：下表中的每一个数都对应着一个字符串，随机生成0到999的一个是，C_LAST将由随机数每一位所对应的字符串拼接而成。0123456789BAROUGHTAB

39、LEPRIPRESESEANTICALLYATIONEING比如说产生的随机数245，那么C_LAST对应的字符串就应该为ABLEPRESESE。随机数59对应C_LAST的值为ESEEING。unique within x 表示的是在小于x 的数中取值，且每个数必须是唯一的，仅能取一次。5、仓库、地区、顾客的 号W_ZIP,D_ZIP,C_ZIP通过以下机制产生：随机产生一个长度为4的字符串，然后在末尾加上11111组成。这个长度为4的字符串通过0到9999随机数产生，这就是说总共可以产生10000个编码。例如，随机字符串0970，那么 码就是097011111.对于每一个仓库有30，000

40、位顾客，但编码只有10，000个，所以平均有三位顾客是使用同一个 。定义完这些重要的数据类型，通过表3.1对应的各表的数量关系，将数据库进行初始化。表3-1 各表数量关系图Table NameCardinality Typical 3 RowTypical 3 Table(in rows)Length (in bytes)Size (in 1,000 bytes)WAREHOUSE1 890.089DISTRICT10 950.950CUSTOMER30k 65519,650HISTORY 30k 461,380ORDER30k 24720NEW-ORDER9k 872ORDER-LINE 3

41、00k 5416,200STOCK 100k 30630,600ITEM 100k 828,200通过以上的初始化，数据的加载就算告一段落了，接下来的工作就是把各个事务进行设计和实现。3.3 基于TPC_C基准事务模型的实现由3.1节对TPC_C的介绍可知，TPC_C的事务模型包含了一系列的读操作和更新事务操作频繁交互执行的处理过程，模拟的是一种复杂的联机事务应用环境的创建的活动。这个环境的核心活动是NEW ORDER事务，其他四个事务是在一个仓库中进行的PAYMENT支付操作、ORDER STATUS订单状态查询操作、DELIVERY发货操作和STOCK LEVEL库存状态查询操作。接下来将

42、对各个事务的特征和实现过程进行详细分析。3.3.1 NEW ORDER（新订单）事务的实现NEW ORDER事务是本系统中的一个核心事务，是一个读写型事务，执行的频率很高，因此要求系统的响应时间必须尽可能小，以满足在线用户的需求。其主要容就是模仿在线用户的订单请求，用户输入一份完整的订单（这一切在实现过程中都是随机数生成），提交系统的过程。在测试过程中，每分钟生成的订单数tmpC是整个系统性能的重要参考和评价指标。tmpC越大，说明系统的性能越好，系统对用户的响应时间也就越短。事务的实现分为以下部分：一、 数据输入要求1、Warehouse ID要求前后都一致，是用户输入的。考虑到如果Ware

43、house数量过多会导致数据量的庞大，故而Warehouse的取值只能为1或2.2、District ID是1到10的一个随机数，但是保证了District的D_W_ID与Warehouse的ID是一样的。即D_W_ID=W_ID.3、顾客编号C_ID是用NURand（1023，1，3000）生成的但保证顾客所选的仓库号与Warehouse的W_ID一致并且地区号与District的D_ID一致。即C_D_ID=D_ID C_W_ID=W_ID.4、Order_t表中的ol_cnt是5到15中的一个随机数，平均为10.其主要是计量order的大小。5、供货仓库99%的时间是直接从就近仓库中获取

44、，1%的时间是从远方仓库中获取。这一功能的实现可以采用随机数1到100加以实现。即当X1时，OL_SUPPLY_W_ID=W_ID,而X=1时，OL_SUPPLY_W_ID是从可用仓库中随机选择的一个，而不是W_ID.6、OL_QUANTITY是1到10的随机数。7、O_ENTRY_D是当前的系统时间。二、 事务的实现步骤1、 从WAREHOUSE表中找出与输入的W_ID相等的项并返回W-TAX2、 从DISTRICT表中找到D_W_ID=W_ID,D_ID与随机生成的D_ID相等的项，并返回D_TAX，D_NEXT_O_ID即下一个可用的订单号返回并且加一。3、 从CUSTOMER表中找到C

45、_W_ID=W_ID,C_D_ID=D_ID,C_ID与随机生成的相等的项并返回顾客的折扣率C_DISCOUNT，顾客的姓氏C_LAST，顾客当前的账务状况C_CREDIT。4、 往NEW_ORDER 和ORDER表中填入新项以表有新的订单生成，同时O_CARRIER_ID设置为NULL;如果所有订单都是本地的仓库获取，则O_ALL_LOCAL被置为1，否则为0.5、 ORDER_T表中O_OL_CNT置为相应的OL_CNT.6、 对于ORDER_T表中的每一项O_OL_CNT，表ITEM中找到符合I_ID=OL_I_ID的项，返回I_PRICE,I_NAME,I_DATA.7、 STOCK表

46、中找到S_I_ID=OL_I_ID且S_W_ID=OL_SUPPLY_W_ID,返回S_QUANTITY, S_DIST_xx (xx代表的是S_DIST的编号),S_DATA. 如果S_QUANTITY的数超过10，则S_QUANTITY=OL_QUANTITY-S_QUANTITY, 否则S_QUANTITY=(S_QUANTITY-OL_QUANTITY)+91.S_YTD =SYTD+OL_QUANTITY,S_ORDER_CNT=S_ORDER_CNT+1.如果仓库是远方的，则S_REMOTE_CNT加一。8、 OL_AMOUNT=OL_QUANTITY*I_PRICE.9、 如果I

47、_DATA和S_DATA都包含有ORIGINAL字符串，则brand-generic被标志为B，否则标志为G。10、 Total-amount=sum(OL_AMOUNT)*(1-C_DISCOUNT)*(1+W_TAX+D_TAX)3.3.2 PAYMENT（支付）事务的实现Payment事务主要是更新用户的账户并反映出地区和仓库的销售状况。对于任意一个客户，在固定的仓库中随机选取一个地区与其用户，采用随机的金额支付一笔订单，并作相应的历史记录，修改用户的金额。这个事务要求高频读写，所以响应时间必须要快才能满足在线用户的需求。一、数据输入要求地区编号D_ID是1到10的一个随机数，顾客60%的时间是按Last_name来搜寻，即搜寻条件为（C_W_ID,C_LAST）,而40%的时间是按用户编号来搜寻的，即(C_W_ID,C_D_ID,C_ID)，顾客货物的供应仓库有85%的时间是本地供货，15%的时间是远方仓库供货。即作为一个从1到100的随机数X，当X=85的时候，顾客的选择是C_D_ID=C_ID AND C_W_ID