CN102541966A - 用于验证数据库系统正确性的方法和装置 - Google Patents

Abstract

本发明涉及数据库技术领域。更具体地，本发明涉及验证关系数据库系统的正确性的技术。本发明提供了一种用于验证数据库系统的正确性的方法，包括：接收结构化查询SQL指令；扩展所接收到的SQL指令的访问路径；利用所述扩展的访问路径执行所述SQL指令；以及根据执行所述SQL指令的结果验证数据库系统的正确性。通过本发明的方法和系统，可以实现通过自动扩展SQL语句的访问路径来验证数据库系统的正确性的目的，还可以实现基于由各种数据操作方式(访问路径元素的不同取值)引发数据库自身存在的错误或缺陷的比重，科学高效、有的放矢地验证数据库系统的正确性的目的。

Description

用于验证数据库系统正确性的方法和装置

技术领域

本发明涉及数据库技术领域。更具体地，本发明涉及验证关系数据库系统的正确性的技术。

背景技术

在信息技术(IT)领域中，数据库尤其是关系型数据库得到了越来越广泛的应用。数据库用于存储海量数据，人们通常利用结构化查询语句(SQL语句)来对关系型数据库中的数据进行查询、插入、删除的操作。以SQL查询语句(SELECT语句)为例，该语句指示了要查询什么数据，但是并未告知关系型数据库管理系统(RDBMS)如何查找这样的数据，可能存在多种可能的途径来查找该数据。因此RDBMS需要对SQL语句进行解析，依据各种策略生成最合理的获取该数据的方式——访问路径(Access Path)。访问路径即为关于如何获取想要的数据的具体步骤。RDBMS按照访问路径指示的具体步骤来执行SQL语句，从而最终获得要查找的数据。

然而，随着RDBMS的复杂程度日益增加，经常会出现对SQL语句输出错误结果。导致输出错误结果的原因可能有很多，但主要的原因都可以归结为RDBMS自身存在缺陷或逻辑错误。因此，如何测试并验证RDBMS的正确性就成了数据库领域的一个重要问题。

目前，存在着一些用于验证数据库系统的正确性的技术方案，例如白盒测试法和黑盒测试法。所谓“白盒测试法”，指的是直接根据数据库的代码逻辑来设计测试用例。而“黑盒测试法”是指不深入代码，而是根据产品功能描述，利用外部接口来写测试用例，通常是编写各种各样的SQL语句。由于数据库系统本身非常复杂，所以无论是白盒测试还是黑盒测试均很难覆盖各种情况，无法做到有的放矢地验证数据库系统的正确性。而且编写测试用例是一项比较费时费力的工作，需要测试人员对数据库系统有着很深入的了解，严重影响了测试效率。

发明内容

考虑到上述存在的问题，本发明的目的之一在于提供一种能够通过接收到的SQL语句(指令)来自动验证数据库系统的正确性的方法和装置。本发明的又一目的在于提供一种通过扩展SQL语句的访问路径(Access path)来有的放矢地验证数据库系统的正确性的方法和装置。

根据本发明的一个方面，提供了一种用于验证数据库正确性的方法，包括：接收结构化查询SQL指令；扩展所接收到的SQL指令的访问路径；利用所述扩展的访问路径执行所述SQL指令；以及根据执行所述SQL指令的结果验证数据库系统的正确性。

根据本发明的一个实施例，其中扩展所接收到的SQL指令的访问路径包括：获取组成所述SQL指令的访问路径的元素；扩展所述元素；以及组合所述元素的可能取值以生成扩展的访问路径。

根据本发明的另一方面，提供了一种用于验证数据库系统的正确性的装置，包括：接收装置，用于接收结构化查询SQL指令；访问路径扩展装置，用于扩展所接收到的SQL指令的访问路径；执行装置，用于利用所述扩展的访问路径执行所述SQL指令；以及验证装置，用于根据执行所述SQL指令的结果验证数据库系统的正确性。

通过本发明的方法和系统，可以实现通过自动扩展SQL语句的访问路径来验证数据库系统的正确性的目的，还可以实现基于由各种数据操作方式(访问路径元素的不同取值)引发数据库自身存在的错误或缺陷的比重，科学高效、有的放矢地验证数据库系统的正确性的目的。

附图说明

通过对结合附图所示出的实施方式进行详细说明，本发明的上述以及其他特征将更加明显，本发明附图中相同的标号表示相同或相似的部件。在附图中，

图1示出了根据本发明一个实施例的用于验证数据库系统的正确性的方法的流程图；

图2示出了根据本发明又一实施例的用于验证数据库系统的正确性的方法的流程图；

图3示出了根据本发明一个实施例的记录历史错误信息的示意性饼图；

图4示出了根据本发明一个实施例的利用蒙特卡洛算法选择访问路径的示意图；

图5示出了根据本发明一个实施例的用于的验证数据库系统的正确性的装置的框图；

图6示出了根据本发明又一实施例的用于验证数据库系统的正确性的装置的框图。

具体实施方式

在下文中，将参考附图通过实施方式对本发明提供的用于确定要被物化的节点的方法和系统进行详细地描述。

图1示出了根据本发明一个实施例的用于验证数据库系统的正确性的方法的流程图。图1所示的方法从步骤101开始。在步骤101中，接收结构化查询SQL指令。SQL指令又称SQL语句，是一种数据库查询和程序设计语言，用于存取数据以及查询、更新和管理关系数据库系统。SQL指令包括多种类型，例如INSERT(插入)、UPDATE(修改)、DELETE(删除)以及SELECT(查询)等。数据库系统通常在接收到一条SQL指令后，会对SQL指令进行解析，然后分析得到最优的访问路径以执行该SQL指令，并输出执行SQL指令的结果。本领域技术人员应当了解，访问路径(Access Path)是指数据库系统对SQL指令的具体执行方法，一条访问路径由多个元素组成，对于每个元素而言又有多种可能的取值。例如，访问路径的元素包括但不限于：访问方法(Access Method)、表连接方式(Join Method)、是否仅通过索引访问(Index Only)、访问的表类型(Table Access)、预取方式(Prefetch)、并发模式(Parallelism Mode)等。对于上述示例的访问路径的元素，以访问方法(Access Method)为例，其可能的取值有表扫描(RSCAN)、索引扫描(ISCAN)以及多索引扫描(MISCAN)三种。以表连接方式(Join Method)为例，其可能的取值有排序合并连接(SMJ，Sort Merge Join)、嵌套循环连接(NLJ，Nested Loop Join)以及混合连接(HYJ，Hybrid Join)三种。优选地，出于验证数据库系统正确性的目的，步骤101中接收到的SQL语句是查询(SELECT)语句，因为有别于插入(INSERT)、UPDATE(修改)和DELETE(删除)语句，SELECT语句中可能涉及诸如表连接方式、预取方式等多个访问路径的元素，可以对访问路径进行扩展。当然，如果一条非SELECT语句中嵌套有SELECT子句，则同样属于这里所指的SELECT语句。

接下来在步骤102，扩展所接收到的SQL指令的访问路径。由于一条SQL指令可能存在多个可能的访问路径，而数据库系统通常在执行一条SQL指令时是选取其所分析出来的一个最优的访问路径进行执行，因此在步骤102中进行的“扩展”就是指扩展得到对应于所接收到的SQL指令的多个可能的访问路径。根据本发明的一个实施例，在步骤102中进行的扩展是指扩展得到该SQL指令的所有可能的访问路径。根据本发明的另一实施方式，在步骤102中进行的扩展是指有选择地扩展得到该SQL指令的部分可能的访问路径。至于如何有选择地扩展可以参照在下文针对图2进行的描述中关于选择一部分经扩展的访问路径的方法执行。关于扩展访问路径的具体方法，根据本发明的一个实施例，扩展访问路径是通过组合访问路径中的元素的可能取值来实现的(将在下文结合图2具体描述)。当然，本领域技术人员应当理解，通过扩展元素来扩展访问路径只是一种可能的扩展方式，无论采用何种扩展方式，只要能够实现对访问路径的扩展，均落入本发明的保护范围。

接下来在步骤103中，利用所扩展的访问路径执行所述SQL指令。如上文所述，数据库对SQL指令的处理是通过执行该SQL指令的访问路径实现的。由于在步骤102中已经扩展得到了多条可能的访问路径，因此可以在步骤103中分别执行多条可能的对应于同一SQL语句的访问路径。

在步骤104中，根据执行所述SQL指令的结果验证数据库系统的正确性。由于所执行的多条访问路径乃是对应于同一SQL语句的，因此在数据库系统本身不存在错误或缺陷的情况下，执行所有的经扩展后的访问路径应当获得同样的输出结果。所以，根据本发明的一个实施例，根据执行所述SQL指令的结果验证数据库系统的正确性是通过判断在执行多条扩展的访问路径后，是否存在不同的输出结果来实现的。只要有一条访问路径经执行后的输出结果不同于其它访问路径执行后的结果，就可以认定数据库系统中存在错误或缺陷。

由图1所示的方法以及上述文字描述可以看出，利用本发明提供的方法可以基于接收到的SQL指令扩展其访问路径，并通过检验对扩展后的访问路径的执行结果来验证数据库系统的正确性的技术效果。

图2示出了根据本发明又一实施例的用于验证数据库系统的正确性的方法的流程图。图2所示的方法从步骤201开始。在步骤201中，接收结构化查询SQL指令，这类似于图1所示的方法中的步骤101，在此不再赘述。

接下来进行至步骤202，在步骤202中获取所接收到的SQL指令的访问路径的元素。本领域技术人员应当了解，目前的关系数据库管理系统RDBMS产品均是通过对SQL指令进行解析并生成数据库引擎所分析得到的最优的访问路径，并且执行该访问路径以输出针对SQL指令的结果。数据库引擎在分析SQL指令的最优访问路径的过程中就是通过对组成访问路径的各个元素的取值进行逐一确定而实现的。因此，如何获取SQL指令的访问路径中的元素属于现有技术中的方案，在此不再赘述。

在步骤203中，组合在步骤202中所获取的访问路径的元素的可能取值，以生成扩展的访问路径。通常，数据库系统对一条SQL指令的处理是试图找出一个最优最合理的访问路径，也就是唯一地确定访问路径中的各个元素的取值，而摒弃其它的可能取值。在本发明中，为了验证数据库系统的正确性，我们需要为访问路径中的元素赋予更多的可能取值并将这些具有多种可能取值的元素组合起来。举例而言，假设一条SQL指令的访问路径中包括两个元素：访问方法AccessMethod和表连接方式Join Method，对于访问方法元素有三个可能的取值，分别是：表扫描、索引扫描和多索引扫描，对于表连接方式也有三个可能的取值，分别是：排序合并连接、嵌套循环连接和混合连接。那么按照步骤203和204，最终扩展的访问路径就有9条，分别是：访问方法(表扫描)—>表连接方式(排序合并连接)、访问方法(表扫描)—>表连接方式(嵌套循环连接)、访问方法(表扫描)—>表连接方式(混合连接)、访问方法(索引扫描)—>表连接方式(排序合并连接)……以此类推。

在步骤203中生成扩展的访问路径后，在步骤204中计算扩展的访问路径的权重值。之所以要计算扩展的访问路径的权重值，是因为通常对于一条SQL指令而言，其访问路径中可能包含多个元素，而每个元素又有多个可能的取值，这样一来，扩展得到的访问路径的数量就会非常庞大。如果让数据库系统在后续的操作中逐一执行所有被扩展的访问路径，就会非常耗时、耗资源并且没有效率。为了能够选取出那些最有可能体现出数据库系统存在的错误的访问路径，在步骤205中计算扩展的访问路径的权重值。根据本发明的一个实施方式，根据访问路径中的元素的权重值以及历史错误信息来计算所扩展的访问路径的权重值。元素的权重值每一个访问路径中的元素自身的权重，体现了在数据库输出错误的SQL指令结果可能由该元素所导致的比重。例如，访问方法元素的权重值为0.1，连接方法元素的权重值为0.4，就说明连接方法这个元素相对于访问方法元素更可能导致出现数据库错误的情况。根据本发明的一个实施方式，元素的权重值是在数据库系统产品发布之后由用户、产品支持和服务人员定义的。根据本发明的另一实施方式，元素的权重值是在数据库系统产品发布之前由开发和测试人员预定义的。根据本发明的再一实施例，元素的权重值在数据库系统产品的生命周期中是可以进行动态调整的。而“历史错误信息”是指在SQL指令执行出错的情况下，每个元素中所包含的各个方案(也就是各个可能的取值)所占的比例。通过图3可以更好地理解“历史错误信息”的含义。

图3示出了7个饼图，其中每个饼图均代表一个访问路径的元素，元素的名称被标识于每个饼图上方。以第一个饼图为例，该饼图代表访问方法(Access Method)这个访问路径中的元素。该饼图被分为三份，分别对应着该元素的三种可能的取值，即表扫描RSCAN、索引扫描ISCAN以及多索引扫描MISCAN。其中，表扫描RSCAN占20％意味着，访问方法这个元素在历史上数据库系统出错时有20％的情形取值为表扫描RSCAN，有20％的情形取值为多索引扫描MISCAN，有60％的情形取值为索引扫描ISCAN，其它各个饼图的含义均可以此类推。需要指出的是，图3所示的饼图仅仅是记录历史错误信息的一种具体方式，本领域技术人员完全可以采用其它方式记录历史错误信息，例如表格等。根据本发明的一个实施例，图3所示的历史错误信息是在数据库系统运行过程中由系统自动记录的。还需要强调的是，对于访问路径的某些元素而言，无法统计相关的历史信息。例如，对于连接顺序(Joint Sequence)这个元素而言，它的取值与SQL指令所要查询的具体的表名相关，只能在接收到具体的SQL指令后，通过获取SQL指令所涉及的数据库对象(表、索引等)的元信息来获取该元素的可能取值。例如，如果一条SQL查询指令涉及表1、表2和表3的连接，那么连接顺序的可能取值就是1—>2—>3、1—>3—>2等。

在步骤204中计算扩展的访问路径的权重时既要利用元素本身的权重值，又要利用历史错误信息中记录的元素的每个可能取值所占的比例，也就是二级分权。下面给出一个计算扩展的访问路径的权重的例子。假设扩展出的两条访问路径为：(1)访问方法(表扫描)—>表连接方式(排序合并连接)以及(2)访问方法(表扫描)—>表连接方式(嵌套循环连接)。假设访问方法元素的权重值为0.1，表连接方式元素的权重值为0.4，再假设历史错误信息如图3所示，那么对于第1条访问路径其权重值为0.1×20％+0.4×35％＝0.16，对于第2条访问路径其权重值为0.1×20％+0.4×58％＝0.252。本领域技术人员应当了解，上述计算过程只是为了示例性地说明一种可能的计算方法，实际上由于访问路径的元素数量很多，等式左边的加号也会很多。

接下来图2所示的方法进行至步骤205。在步骤205中，选择需要利用的扩展的访问路径。根据本发明的一个实施方式，随机地从扩展的访问路径中选取一定数量的访问路径。根据本发明的另一实施方式，利用在步骤204中所计算的权重值由高到低选取一定数量的访问路径。根据本发明的再一实施方式，利用在步骤204中计算的权重值以及蒙特卡洛算法(Monte-Carlo)，选取需要执行的访问路径。图4示出了蒙特卡洛算法的一个示意图。之所以利用蒙特卡洛算法，是因为即使有些访问路径的权重值很低，但是从长期的统计学的观点来看，总有一定的概率出现，而如果仅仅按照步骤204中计算得到的权重值的高低来选取要执行的访问路径，可能会导致漏选一些虽然权重小但是仍然有可能出现的访问路径。而蒙特卡洛算法的基本原理就是以类似“轮盘”的方式，为小权重的访问路径分配较小的面积，为大权重的访问路径分配较大的面积(如图4所示)，然后在选取要执行的访问路径时以模拟旋转圆盘的方式进行。这样可以使得在选取访问路径时更加科学。

接下来在步骤206中，利用选择的访问路径执行SQL指令，并且在步骤207中判断利用该访问路径执行SQL指令的输出结果是否与之前所有执行该SQL指令的其它访问路径输出的结果一致，如果不一致，则在步骤209中判断数据库系统存在错误。如果一致，则进行至步骤208，进一步判断是否已经将所有选择的访问路径执行完毕。如果尚未全部执行完毕，则返回至步骤206，重复206至208的执行、判断步骤，如果已经全部执行完毕，则说明对于所有选择访问路径均输出了相同的执行该SQL指令的结果，从而在步骤210中确定数据库系统不存在错误。

需要强调的是，图2所示的方法中的步骤204和205并非本发明必须的步骤。因为，本领域技术人员在不考虑效率的情况下，完全可以不对步骤203中扩展的访问路径进行选择，而执行所有的扩展得到的访问路径。即使需要对访问路径进行选择，步骤204计算权重值也并非必需的，因为本领域技术人员完全可以采用随机选择的方式或者以限定某种条件(例如要求访问方法元素的取值必须是表扫描)的方式选择需要执行的访问路径。

还需要指出的是，在步骤205选择了需要执行的访问路径之后，通常还需要对所选择的访问路径的可行性进行验证。例如，对于并发模式(PARALLELISM MODE)这个元素而言，有一条访问路径中其取值为多子系统级并发(SYSPLEX)，但是实际系统并不是一个SYSPLEX系统，因此这个被扩展得到的访问路径实际上就是不可行的。这一验证可行性的操作并没有被列入在图2所示的流程图中，因为目前数据库系统在解析SQL指令并生成访问路径时也需要执行类似的操作，在此不再赘述。当然，这一验证访问路径可行性的操作既可以在步骤205选择了需要执行的访问路径之后进行，也可以在步骤203生成扩展的访问路径时就进行。

图5示出了根据本发明一个实施方式的用于的验证数据库系统的正确性的装置的框图。图5所示的系统在总体上由系统500表示。具体地，系统500包括SQL指令接收装置501，用于接收结构化查询SQL指令；访问路径扩展装置502，用于扩展所接收到的SQL指令的访问路径；执行装置503，用于利用所述扩展的访问路径执行所述SQL指令；以及验证装置504，用于根据执行所述SQL指令的结果验证数据库系统的正确性。本领域技术人员应当理解，系统500中的装置501至504分别对应于图1所示的方法中的步骤101至104，在此不再赘述。

图6示出了根据本发明另一实施方式的用于验证数据库系统的正确性的装置的框图。图6所示的系统总体上由系统600表示。具体地，系统600包括SQL指令接收装置601，用于接收结构化查询SQL指令；元素获取装置602，用于获取组成SQL指令的访问路径的元素；访问路径扩展装置603，用于组合所述元素的可能取值以生成扩展的访问路径；访问路径选择装置604，用于计算扩展的访问路径的权重值并选择需要利用的扩展的访问路径；执行装置605，用于利用选择的访问路径执行SQL指令；第一判断装置606，用于判断执行结果是否与所有已经输出的执行结果一致，并且在判断结果为否的情形下，确定数据库系统存在错误；以及第二判断装置607，用于判断是否所有选择的访问路径均执行完毕，并且在判断结果为否的情况下，继续执行尚未执行的访问路径，以及在判断结果为是的情况下，确定数据库系统中不存在错误。本领域技术人员应当理解，系统600中的装置601-603以及605分别对应于图2所示的方法中的步骤201-203以及206，系统600中的装置604对应于图2所示的方法中的步骤204-205，系统600中的装置606对应于图2所示的方法中的步骤207以及209，系统600中的装置607对应于图2所示的方法中的步骤208以及210。

通过以上对具体实施例的描述，本领域技术人员可以理解，上述的系统、装置和方法可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本实施例的装置、服务器及其单元可以由诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用由各种类型的处理器执行的软件实现，也可以由上述硬件电路和软件的结合实现。

虽然以上结合具体实例，对本发明的利用远程应用处理本地文件的系统及方法进行了详细描述，但本发明并不限于此。本领域普通技术人员能够在说明书教导之下对本发明进行多种变换、替换和修改而不偏离本发明的精神和范围。应该理解，所有这样的变化、替换、修改仍然落入本发明的保护范围之内。本发明的保护范围由所附权利要求来限定。

Claims (14)

1.一种用于验证数据库系统的正确性的方法，包括：

接收结构化查询SQL指令；

扩展所接收到的SQL指令的访问路径；

利用所述扩展的访问路径执行所述SQL指令；以及

根据执行所述SQL指令的结果验证数据库系统的正确性。

2.如权利要求1所述的方法，其中扩展所接收到的SQL指令的访问路径包括：

获取组成所述SQL指令的访问路径的元素；以及

组合所述元素的可能取值以生成扩展的访问路径。

3.如权利要求2所述的方法，进一步包括：

根据访问路径中的元素的权重值以及历史错误信息，计算所扩展的访问路径的权重值。

4.如权利要求3所述的方法，所述历史错误信息包括：在SQL指令执行出错的情况下，每个元素的各个可能的取值所占的比例。

5.如权利要求3或4所述的方法，其中利用所述扩展的访问路径执行所述SQL指令包括：

根据所计算得到的所扩展的访问路径的权重值，选择需要利用的所扩展的访问路径；以及

利用所选择的访问路径执行所述SQL指令。

6.如权利要求5所述的方法，其中根据所计算得到的所扩展的访问路径的权重值，选择需要利用的所扩展的访问路径是利用蒙特卡洛算法实现的。

7.如权利要求1-6任一所述的方法，其中根据执行所述SQL指令的结果验证数据库系统的正确性包括：

判断执行所述SQL指令的结果是否与之前的执行所述SQL指令的结果相同；以及

如果结果不同，则确定所述数据库系统存在错误。

8.一种用于验证数据库系统的正确性的系统，包括：

接收装置，用于接收结构化查询SQL指令；

访问路径扩展装置，用于扩展所接收到的SQL指令的访问路径；

执行装置，用于利用所述扩展的访问路径执行所述SQL指令；以及

验证装置，用于根据执行所述SQL指令的结果验证数据库系统的正确性。

9.如权利要求8所述的系统，其中访问路径扩展装置包括：

元素获取装置，用于获取组成所述SQL指令的访问路径的元素；以及

访问路径扩展装置，用于组合所述元素的可能取值以生成扩展的访问路径。

10.如权利要求9所述的系统，进一步包括：

访问路径选择装置，用于根据访问路径中的元素的权重值以及历史错误信息，计算所扩展的访问路径的权重值。

11.如权利要求10所述的系统，所述历史错误信息包括：在SQL指令执行出错的情况下，每个元素的各个可能的取值所占的比例。

12.如权利要求10或11所述的系统，其中执行装置被进一步配置为：

根据所计算得到的所扩展的访问路径的权重值，选择需要利用的所扩展的访问路径；以及

利用所选择的访问路径执行所述SQL指令。

13.如权利要求12所述的系统，其中执行装置被进一步配置为：利用蒙特卡洛算法选择需要利用的所扩展的访问路径。

14.如权利要求8-13任一所述的系统，其中验证装置被进一步配置为：

判断执行所述SQL指令的结果是否与之前的执行所述SQL指令的结果相同；以及

如果结果不同，则确定所述数据库系统存在错误。

Images