本申请涉及计算机领域，尤其涉及一种建立模型数据库的方法以及客户端。
背景技术：
：：数据库(database)是按照数据结构来组织、存储和管理数据的仓库，它产生于距今六十多年前，随着信息技术和市场的发展，特别是二十世纪九十年代以后，数据管理不再仅仅是存储和管理数据，而转变成用户所需要的各种数据管理的方式。数据模型是数据库的核心，当前广泛使用的是关系数据库管理系统(relationaldatabasemanagementsystem，rdbms)，比较知名的如oracle、db2、sqlserver、sybase等。在机构、企业中，数据库系统一般存放着重要的业务数据，用于支撑日常运营业务，提供经营报表，决策服务等。像企业资源计划系统(enterpriseresourceplanning，erp)、客户关系管理系统(customerrelationshipmanagement，crm)、网上商城等交易型系统在业务高峰期出现许多用户同时并发访问系统、且要求系统能快速返回查询或操作结果；在海关风险分析、财务系统中，决策者希望尽快拿到分析报告以对后续商业行为做决策。这些都要求运行在信息技术(informationtechnology，it)硬件架构之上的数据库系统性能能够满足业务需求。因此，在购买it设备或者业务上线之前进行真实业务负载的性能测试就显得非常重要。随着科学技术的不断发展，不同行业企业的业务系统也越来越多。业务系统的性能受组成系统的每一个组件性能的影响。不同数据库类型、数据库版本、操作系统类型、操作系统版本、服务器型号及配置、存储网络、存储系统都可能导致整个系统性能出现差异。尽管业界提出了一些代表常规数据库业务类型的tpc-c、tpc-h测试工具，但这些测试工具是建立在预定义的模型基础上实现的。这些测试工具能够反映数据库系统的基本运作流程和反映系统大致的性能表现情况。但真实性还比较欠缺，当前能够比较真实反映数据库操作的数据库测试工具都需要搭建真实的数据库环境来进行测试，这种测试对测试人员技能要求高、测试周期较长。技术实现要素：本申请实施例提供了一种建立模型数据库的方法以及客户端，用于客户端根据实际的生产环境中关于存储的i/o特征和i/o负载，以及所述生产环境中目标数据库的配置参数得到模型数据库的配置文件，再根据模型数据库对目标数据库进行性能测试，得到准确性比较高的测试报告。本申请实施例第一方面提供了一种建立模型数据库的方法，可以包括：客户端可以通过ge网络或者fc网络与生产环境中的存储系统相连，客户端的i/o跟踪工具获取生产环境中关于存储的i/o特征和i/o负载，以及该生产环境中目标数据库的配置参数；对该i/o特征和该i/o负载进行分析，确定分析报告；根据该分析报告和该目标数据库的配置参数，确定模型数据库的配置文件。需要说明的是，生产环境包括存储系统和目标数据库，客户端的i/o跟踪工具获取的是关于存储系统的i/o特征和i/o负载。在本申请实施例中，客户端可以通过i/o跟踪工具，获取关于存储系统的i/o特征和i/o负载，以及获取该生产环境中目标数据库的配置参数；再对i/o特征和i/o负载进行分析，确定分析报告；最后根据该分析报告和该目标数据库的配置参数，建立模型数据库。这里的模型数据库是根据实际生产环境的相关数据确定的，所以，再根据这个模型数据库对目标数据库进行测试的时候，得到的测试报告的真实性就比较高。可选的，在本申请的一些可能的实现方式中，该生产环境中关于存储的i/o特征和i/o负载，可以包括：获取生产环境中在预置时长内，关于存储的各个逻辑单元号lun的i/o特征和i/o负载；需要说明的是，这里的预置时长是可以体现生产环境的当前属性，不能太少，太少的话，作为参考依据就不够准确，生产环境的当前属性可以是高负载的工作环境，中负载的工作环境，或者，低负载的工作环境。该对该i/o特征和该i/o负载进行分析，确定分析报告之前，该方法还可以包括：获取该生产环境中关于存储的每个逻辑单元号标识lunid和每个lun的大小。应理解，上述的存储系统中的存储空间是以lun体现的，所以，这里获取每个lun的标识和大小，用来对应的模拟模型数据库。在本申请实施例中，对客户端获取生产环境中关于存储的i/o特征和i/o负载作了一个细化，是获取生产环境在预置市场内，关于存储的i/o特征和i/o负载，因为这个预置时长是具有代表性的一段时长，时间太少，得到的数据可靠性有待商榷，时间太长，工作量比较大。所以，这里的预置时长是根据生产环境的实际情况得到的。该对该i/o特征和该i/o负载进行分析，确定分析报告之前，该方法还可以包括：获取该生产环境中关于存储的每个逻辑单元号标识lunid和每个lun的大小，用于进行模型数据库的模拟。可选的，在本申请的一些可能的实现方式中，该i/o特征包括i/o大小、偏移量和时间戳，该i/o负载包括读i/o次数和写i/o次数；该对该i/o特征和该i/o负载进行分析，确定分析报告，可以包括但不限于以下几种分析方式：(1)根据时间戳、读i/o次数、写i/o次数和每个lunid，确定每个lun的读百分比(lun的读i/o次数/lun的i/o总数)、写百分比(lun的写i/o次数/lun的i/o总数)、负载百分比(lun的i/o总数/所有lun的i/o总数)、读负载百分比(lun的读i/o总数/所有lun的读i/o总数)和写负载百分比(lun的写i/o总数/所有lun的写i/o总数)；(2)根据预先确定的i/o大小的类别、时间戳、读i/o次数、写i/o次数和每个lunid，确定每个lun中每种i/o大小的负载百分比(lun在每种i/o大小时的i/o次数/lun的i/o总数)、读负载百分比(lun在每种i/o大小时的读次数/lun的读i/o总数)和写负载百分比(lun在每种i/o大小时的写次数/lun的写i/o总数)；(3)根据偏移量、每个lunid和每个lun的大小，确定每个lun的lba地址；将预置时长均分为n等份，将每个lun的lba地址均分为m等份，n和m为正整数；根据预先确定的i/o大小的类别、时间戳、读i/o次数、写i/o次数和每个lunid，确定每个lun中每种i/o大小在每个1/n时间单元内的读负载百分比(在每种i/o大小中某时间单元内的读i/o总数/lun的读i/o总数)和写负载百分比(在每种i/o大小中某时间单元内的写i/o总数/lun的写i/o总数)，以及每个lun中每种i/o大小在每个1/m地址单元内的读负载百分比(在每种i/o大小中某lba地址单元内的读i/o总数/lun的读i/o总数)和写负载百分比(在每种i/o大小中某lba地址单元内的读i/o总数/lun的读i/o总数)。在本申请实施例中，提供的是几种根据i/o特征和i/o负载进行分析，确定分析报告的具体实现过程，增加了方案的可行性，对分析报告有了具体的了解。可选的，在本申请的一些可能的实现方式中，该方法还可以包括：若该分析报告的配置文件格式与该模型数据库的目标文件格式不同，则将该分析报告的配置文件格式转换为该目标文件格式；还可以是，若该分析报告和生产环境中目标数据库的配置参数的配置文件格式与该模型数据库的目标文件格式不同，则将该分析报告和生产环境中目标数据库的配置参数的配置文件格式转换为该目标文件格式。在本申请实施例中，若客户端确定的分析报告的配置文件格式与该模型数据库的目标文件格式不同，则将该分析报告的配置文件格式转换为该目标文件格式。那么，该模型数据库就可以根据对应的目标文件格式，对生产环境的目标数据库进行性能测试了。可选的，在本申请的一些可能的实现方式中，该方法还可以包括：根据该模型数据库对该目标数据库进行性能测试，得到测试结果；根据该测试结果，生成测试报告。在本申请实施例中，客户端可以根据建立的模型数据库，对目标数据库进行性能测试了，因为该模型数据库是根据实际的生产环境的相关数据建立的，所以，根据该模型数据库对目标数据库进行性能测试，得到的测试报告就接近于目标数据库的真实性了，这样的测试报告对于用户来说，更有参考价值。可选的，在本申请的一些可能的实现方式中，根据该模型数据库对目标数据库进行性能测试之后，该方法还可以包括：获取日志段编号lsn日志文件；根据该lsn日志文件，对该目标数据库中的数据进行一致性检查。在本申请实施例中，在对目标数据库的测试过程中，还会生成lsn日志文件，根据该lsn日志文件，对该目标数据库中的数据进行一致性检查。使得本申请技术方案更加完整。本申请实施例第二方面提供一种客户端，具有实现对应于上述第一方面提供的客户端根据实际的生产环境中关于存储的i/o特征和i/o负载，以及该生产环境中目标数据库的配置参数，得到模型数据库的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。本申请实施例第三方面提供一种发送设备，可以包括：收发器，处理器，存储器和总线，该收发器、该处理器和该存储器通过该总线连接；该存储器，用于存储操作指令；该收发器，用于获取生产环境中关于存储的i/o特征和i/o负载，以及该生产环境中目标数据库的配置参数；该处理器，用于对该i/o特征和该i/o负载进行分析，确定分析报告；根据该分析报告和该目标数据库的配置参数，确定模型数据库的配置文件。本发明实施例第四方面提供一种存储介质，需要说明的是，本发的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产口的形式体现出来，该计算机软件产品存储在一个存储介质中，用于储存为上述设备所用的计算机软件指令，其包含用于执行上述第一方面、第二方面、第三方面或第四方面为客户端所设计的程序。该存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。本发明实施例第五方面提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行如本申请第一方面或第一方面任一可选实现方式中该的方法。从以上技术方案可以看出，本申请实施例具有以下优点：在本申请实施例中，获取生产环境中关于存储的i/o特征和i/o负载，以及该生产环境中目标数据库的配置参数；对该i/o特征和该i/o负载进行分析，确定分析报告；根据该分析报告和该目标数据库的配置参数，确定模型数据库的配置文件。那么，客户端就可以根据模型数据库对目标数据库进行性能测试了，因为该模型数据库的配置文件是根据实际的生产环境中关于存储的i/o特征和i/o负载，以及该生产环境中目标数据库的配置参数得到的，所以，相对于现有的通用型模型数据库来说，进行性能测试确定的测试报告的准确性更高，接近于目标数据库的实际性能。附图说明为了更清楚地说明本申请实施例技术方案，下面将对实施例和现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，还可以根据这些附图获得其它的附图。图1为本申请实施例中现有数据库业务系统的一个结构框架图；图2为本申请实施例中db2系统架构的一个示意图；图3为本申请实施例中所应用的一个流程图；图4为本申请实施例中建立模型数据库的方法的一个实施例示意图；图5为本申请实施例中提出的模型数据库的架构示意图；图6为本申请实施例中模型数据库支持不共享存储的集群数据库的一个示意图；图7为本申请实施例中模型数据库支持共享存储的集群数据库的一个示意图；图8为本申请实施例中关于表空间和表的一个示意图；图9为本申请实施例中关于区域的一个示意图；图10为本申请实施例中一致性检查的示意图；图11为本申请实施例中生产环境为db2v95的数据库生产环境示意图；图12为本申请实施例中跟踪工具跟踪存储系统的一个示意图；图13为本申请实施例中客户端的一个实施例示意图；图14为本申请实施例中客户端的另一个实施例示意图；图15为本申请实施例中客户端的另一个实施例示意图；图16为本申请实施例中客户端的另一个实施例示意图；图17为本申请实施例中客户端的另一个实施例示意图。具体实施方式本申请实施例提供了一种建立模型数据库的方法以及客户端，用于客户端根据实际的生产环境中关于存储的i/o特征和i/o负载，以及所述生产环境中目标数据库的配置参数得到模型数据库的配置文件，再根据模型数据库对目标数据库进行性能测试，得到准确性比较高的测试报告。为了使本
技术领域：
：的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，都应当属于本申请保护的范围。数据库业务系统是一个硬件和软件的集合，主要包含it基础架构和数据库软件。如图1所示，为数据库业务系统的一个结构框架图，由这些部件一起协同工作，提供连续的数据服务。通常rdbms的系统架构基本元素基本一致，有实例、数据库的概念。实例是进程或线程加上内存的集合。数据库是存放在磁盘上用于存放数据的文件的集合。数据库的文件有控制文件、日志文件、数据文件、归档日志文件、备份文件等。如图2所示，为db2系统架构的一个示意图，基本描述了大部分rdbms系统的处理机制。db2的所有活动都是由线程处理。db2代理(agent)线程处理大部分的结构化查询语言(structuredquerylanguage，sql)操作。在db2应用系统中，每个用户应用程序(clientapplication)可能会分配多个副代理(subagents)。agent处理客户的事务请求，将数据更改日志写入日志缓冲区(logbuffer)，并等待记录器(logger)将logbuffer中的记录写入到日志文件，同时将处理事务需要的数据读入到缓冲池(bufferpool)，并对某些数据进行更改。bufferpool中被更改的数据称为脏数据，当bufferpool的使用率超过特定水位之后，这些脏数据由页面清理(pagecleaner)写入到表空间(tablespaces)。在某些情况下，agent会对数据进行顺序读(例如表扫描tablescan操作)，此时实例将对数据页进行异步预取，agent将异步预取请求放入预取队列，由预取器(prefetcher)整合之后对表空间发起并发大数据块读取操作。死锁探测器(deadlockdetector)是一个数据库死锁检测编码的数据单元(encodingdataunit，edu)，每隔一段时间，deadlockdetector会对数据库锁进行检测，发现有死锁发生时通知agent进行处理。当前数据库性能测试中，大多数采用通用输入/输出(input/output，i/o)端口测试工具、数据库i/o模拟工具和数据库脚本进行业务模拟测试。诸如iometer、iozone、vdbench通用i/o测试工具可以根据预设的i/o特征(i/o大小、随机度、读写比例等)对存储子系统进行负载测试，通过实时界面或者文本输出，观察存储子系统的性能情况。现在通用的数据库i/o测试工具是采用swingbench、tpcc等工具对数据库系统进行业务模拟测试。这些测试工具可以模拟预设业务对数据库进行负载测试，通过实时界面或者文本输出，观察数据库系统的性能情况。另外一种数据库业务模拟测试是通过sql语句编写具有类似结构的表、索引、处理逻辑等的脚本来模拟测试数据库业务。但是，通用i/o测试工具虽然通用性高，但不支持i/o建模、无法模拟热点区域、与生产环境相比真实性极低、不支持数据一致性检测，与真实数据库业务相差很大。数据库i/o测试工具常常是针对定义的特定系统的模拟，无法自定义i/o建模，热点区域较粗略，大部分只针对部分数据库环境，通用性低，不支持数据一致性检测，由于是固定模型的i/o，与生产环境相比真实性较低。数据库脚本模拟可以做到数据库层建模、可以模拟热点区域、与生产环境相比真实性较高，但通用性很低，数据一致性检测依赖于数据库，对测试人员技能要求比较高。如下述表1所示，为各个测试工具特性的对比表：分类通用i/o测试工具数据库i/o模拟工具数据库脚本i/o建模不支持无法自定义数据库层建模热点区域无法模拟较粗略可以模拟真实性极低较低较高通用性高低很低一致性检测不支持不支持依赖于数据库表1如图3所示，为本申请实施例中所应用的一个系统架构图，采样分析主机通过千兆以太网(gagabitethernet，ge)或光纤通道(fiberchannel，fc)网络与生产环境的存储系统相连，通过i/o跟踪工具跟踪并采集生产环境中数据库业务的i/o特征和i/o负载，以及获取生产环境中数据库的配置参数；再对i/o特征和i/o负载进行分析，确定分析报告；根据分析报告和目标数据库的配置参数，确定模型数据库的配置文件，建立模型数据库。这里建立的模型数据库是根据实际生产环境的相关参数确定的，进而，根据该模拟数据库对目标数据库进行性能测试的时候，得到的测试报告准确性相对比较高，那么，所得到的测试报告的可靠性也比较高了，参考价值也就比较高。下面以实施例的方式对本申请技术方案中建立模型数据库的方法进行具体说明，如图4所示，为本申请实施例中建立模型数据库的方法的一个实施例示意图，包括：401、获取生产环境中关于存储的i/o特征和i/o负载，以及生产环境中目标数据库的配置参数；在本申请实施例中，客户端(也可称为采样分析主机)可以通过ge网络或者fc网络与生产环境中的存储系统相连，使用i/o跟踪工具跟踪并采集生产系统中数据库业务的i/o特征和i/o负载，以及获取生产环境中目标数据库的配置参数和备份策略等信息。需要说明的是，生产环境包括存储系统和目标数据库，在存储系统中，包括多个逻辑单元号lun，在实际应用中，客户端除了获取上述信息之外，还需要获取生产环境中关于存储系统的每个逻辑单元号标识lunid和每个lun的大小。具体的，获取生产环境中关于存储的i/o特征和i/o负载，可以包括：获取生产环境中在预置时长内，关于存储的各个逻辑单元号lun的i/o特征和i/o负载；这里的预置时长，可以是生产环境业务高峰期的一段时间，也可以是生产环境业务低峰期的一段时间，具体可根据实际应用需求而定。其中，i/o特征可以包括偏移量、i/o大小、时间戳、随机度和顺序度等信息；i/o负载可以包括读i/o次数、写i/o次数、响应时间和队列深度等信息；目标数据库的配置参数可以包括：1.归档模式(归档，非归档)；2.备份策略(备份时间间隔，备份线程数，备份源和目的文件，备份目的文件存放位置)；3.每秒最大事务数(tps)；4.数据库缓冲区大小，日志缓冲区的大小；5.redo日志文件大小，日志文件个数；6.归档文件大小。应理解，上述所提及的跟踪工具可以多种多样，比如linux中的“blktrace”、windows中的“filemon”。一些存储系统提供i/o跟踪命令，也可以用这些存储命令来跟踪i/o。下面列举了一些i/o跟踪工具，可选择合适的i/o跟踪工具来跟踪生产环境的相关信息：blktrace–linux块i/o跟踪工具；strace–linux系统调用跟踪命令；filemon–windows文件i/o跟踪工具(主机)；vxtrace–veritasstoragefoundationtm卷管理器i/o跟踪命令；可用于hp-ux环境和其他任何使用vxvm软件的操作系统；trace–aix系统调用跟踪命令；truss–solaris系统调用跟踪命令；prex–solaris跟踪命令；cacheshowlogio–huaweisymantecoceansapcetmturbo存储的高速缓冲存储器(cache)i/o跟踪命令；swat–sunstoragetektm工作负载分析工具，可用于windows和solaris，该工具不仅跟踪i/o属性，还跟踪i/o数据。因此，必须留足够的空间给跟踪日志，分析工作也比其他跟踪工具花的时间长。i/o跟踪需在具有业务负载代表性时段跟踪，且跟踪时间应足够长。如果生产环境负载具有完全不同的特性，则需要针对不同特性的负载进行单独i/o跟踪，并建模为不同的模型数据库配置文件。在unix和linux系统中可以使用“iostat”或者“sar”命令，在windows系统中可以使用“perfmon”来跟踪i/o负载。i/o负载更新周期应非常小，比如每秒一次或者更小的时间单位。在跟踪阶段，实际应用中，对于目标数据库的参数、活动报告和目标数据库的备份策略也应该采集，因为这些信息对于模型数据库建模很有必要。402、对i/o特征和i/o负载进行分析，确定分析报告；在本申请实施例中，客户端可以对i/o特征和i/o负载进行分析，确定分析报告；i/o特征可以包括i/o大小、偏移量和时间戳，i/o负载可以包括读i/o次数和写i/o次数，读i/o次数和写i/o次数之和为i/o总数。需要说明的是，还可以将上述步骤中获取的lun的大小转换为扇区(sector)的数量，若获取的lun的单位是mb，一个扇区的大小是512字节(byte)，1kb＝512字节*2，所以，将lun转换为扇区的数量是：lun大小(mb)*1024*2。再通过偏移量和扇区就可以确定lun的lba地址了。可以根据生产环境的页面(page)的大小，来确定i/o大小的范围，若page的大小为4kb，则i/o大小的范围为4kb-512kb，且每种i/o大小都是4kb的整数倍，所以，这种情况下共有128种i/o大小；那么，客户端获取的i/o大小的实际范围可以为0kb-512kb。示例性的，那么，这128种i/o大小就是下述所说的预先确定的i/o大小的类别。假设，跟踪工具跟踪的时长为30分钟，若每隔1s对各个lun跟踪一次，那么，对于每一个lun来说，总共会跟踪到1800个跟踪信息，这里的跟踪信息是上述的i/o大小、偏移量、时间戳、读i/o次数和写i/o次数等信息。具体的，对i/o特征和i/o负载进行分析，可以包括但不限于以下几种分析：(1)根据时间戳、读i/o次数、写i/o次数和每个lunid，确定每个lun的读百分比(lun的读i/o次数/lun的i/o总数)、写百分比(lun的写i/o次数/lun的i/o总数)、负载百分比(lun的i/o总数/所有lun的i/o总数)、读负载百分比(lun的读i/o总数/所有lun的读i/o总数)和写负载百分比(lun的写i/o总数/所有lun的写i/o总数)；(2)根据预先确定的i/o大小的类别、时间戳、读i/o次数、写i/o次数和每个lunid，确定每个lun中每种i/o大小的负载百分比(lun在每种i/o大小时的i/o次数/lun的i/o总数)、读负载百分比(lun在每种i/o大小时的读次数/lun的读i/o总数)和写负载百分比(lun在每种i/o大小时的写次数/lun的写i/o总数)；(3)根据偏移量、每个lunid和每个lun的大小，确定每个lun的lba地址；将预置时长均分为n等份，将每个lun的lba地址均分为m等份，n和m为正整数；根据预先确定的i/o大小的类别、时间戳、读i/o次数、写i/o次数和每个lunid，确定每个lun中每种i/o大小在每个1/n时间单元内的读负载百分比(在每种i/o大小中某时间单元内的读i/o总数/lun的读i/o总数)和写负载百分比(在每种i/o大小中某时间单元内的写i/o总数/lun的写i/o总数)，以及每个lun中每种i/o大小在每个1/m地址单元内的读负载百分比(在每种i/o大小中某lba地址单元内的读i/o总数/lun的读i/o总数)和写负载百分比(在每种i/o大小中某lba地址单元内的读i/o总数/lun的读i/o总数)。需要说明的是，在上述的分析过程中，对于每个lba地址尽可能分为小的单元，因为越小，那么，得到的分析报告也就越准确。分析每个小单元的负载，并可以将具有相似负载且相邻的lba地址单元合并为一个较大的lba地址单元。可以将预置时长也可以分为尽可能小的时间单元，分析每个时间单元的每秒进行读写(i/o)操作的次数(input/outputoperationspersecond，iops)，还可以将具有相似负载且相邻的时间单元合并为一个较大的时间单元。通过以上分析，可以得到每个表的大小百分比、读/写比例、负载百分比等信息，作为分析报告。403、根据分析报告和目标数据库的配置参数，确定模型数据库的配置文件。在本申请实施例中，客户端确定分析报告之后，根据分析报告和目标数据库的配置参数，确定模型数据库的配置文件。示例性的，存储系统对象的每个数据库文件的lba地址会根据表、索引和分区的大小划分为段(segment)。将生产环境数据库中的物理数据库文件建模为模型数据库中的容器(container)，container的容量可以通过页面数量来表示。将段(segment)建模为模型数据库中的表(table)，table可以包括3个属性：页面数量(由大小百分比计算得到)、负载百分比、读比例。segment中较大的lba地址单元建模为模型数据库中的区域area，area可以有3个属性：大小百分比、读负载百分比、写负载百分比。将较大的时间单元建模为模型数据库中的工作负载(负载百分比、读/写百分比)。目标数据库的参数会建模为模型数据库的属性。目标数据库的备份策略会被建模为模型数据库的备份任务，且会被备份调度器(backupschedulers)线程调度。将分析结果建模为模型数据库的配置文件是一个简单的工作，但需要注意每个参数的准确性。示例性的，如图5所示，为本申请实施例中提出的模型数据库的架构示意图，该模型数据库可以支持oracle、db2、sqlserver等数据库的测试。该模型模拟了：数据库组件(数据文件、数据容器、表空间、缓存池、日志文件、归档空间、备份目标、页面、日志缓存等)。数据库线程(服务器线程、日志刷盘线程、归档线程、页面清理线程、任务调度线程、备份线程等)。数据库机制(事务、读写i/o、日志队列、日志刷盘、缓存队列、锁、脏数据刷盘、性能计数器、校验和、一致性检查等)。需要说明的是，模型数据库不仅支持单实例数据库，也支持共享存储的集群数据库(例如oracle数据库)和非共享存储的集群数据库(例如db2数据库)。如图6所示，为模型数据库支持存储不共享的集群数据库的一个示意图，如图7所示，为模型数据库支持共享存储的集群数据库一个示意图。当模拟共享存储集群数据库时，每个模型数据库都有一个独立的日志文件、归档文件，共享containers。当模拟非共享存储集群数据库时，每个模型数据库都有自己独立的数据库文件，containers不共享。这两种情况下，模型数据库将性能数据上报给监测器(monitor)线程，monitor线程再记录和汇总这些性能数据。404、根据模型数据库对目标数据库进行性能测试，得到测试结果；在本申请实施例中，客户端根据模型数据库对目标数据库进行性能测试，得到测试结果之前，还可以包括：若分析报告的配置文件格式与模型数据库的目标文件格式不同，则将分析报告的配置文件格式转换为目标文件格式。可选的，当分析报告的配置文件格式与模型数据库的目标文件格式相同时，不需要转换分析报告的配置文件格式。还可以是，若分析报告和生产环境中目标数据库的配置参数的配置文件格式与模型数据库的目标文件格式不同，则将分析报告和生产环境中目标数据库的配置参数的配置文件格式转换为目标文件格式。405、根据测试结果，生成测试报告。在本申请实施例中，客户端根据测试结果，生成测试报告。根据模型数据库对目标数据库进行性能测试之后，还可以包括：获取日志段编号lsn日志文件；根据lsn日志文件，对目标数据库中的数据进行一致性检查。在本申请实施例中，客户端获取模型数据库，模型数据库为客户端根据获取的生产环境中关于存储的i/o特征和i/o负载，以及生产环境中目标数据库的配置参数得到的；再根据模型数据库对目标数据库进行性能测试，确定测试报告。因为该模型数据库的配置文件是根据实际的生产环境中关于存储的i/o特征和i/o负载，以及生产环境中目标数据库的配置参数得到的，所以，相对于现有的通用型模型数据库来说，进行性能测试确定的测试报告的准确性更高，接近于目标数据库的实际性能。需要说明的是，在上述图5所示的模型数据库的架构示意图中，该通用数据库架构模型是一系列线程和数据结构的集合。每一个线程模拟一种特定的关系型数据库管理系统(rdbms)的进程或线程，处理特定的功能，下面可对其做一个说明：main线程：用于加载从生产环境跟踪、分析和建模得到的配置文件并启动模型数据库，定期地提交模型数据库的性能数据给监测器(monitor)线程；数据库(database)线程：执行负载，控制agents、pagecleaners的数量以及最大tps。agents线程：负责产生和执行事务，从容器containers中读取pages，写脏pages到bufferpool中，写logrecord到logbuffer中，并等待logwriter同步logbuffer中的日志记录到logsegments中。该线程模拟rdbms中sql处理线程，例如oracle中的专用服务器和db2中的服务器代理。在事务处理中，agents首先生成和发布特定数目的页面。页面的位置和i/o类型基于table和area的负载百分比随机生成。如果页面类型是读，则agents直接从container中读该页面；如果页面类型为写，则agents将该页面写入到bufferpool中，并添加一个项目(item)到日志记录中。i/o操作完成后，agent将日志记录写到logbuffer中，并等待直到logwriter完成日志记录到日志文件的同步。当每个事务处理完成后，性能数据就被更新。当一个事务执行时，有三种类型的时延：读页面时延、日志文件同步时延、缓冲池等待时延。这三种时延共同组成了事务时延。事务产生速度由最大tps配置决定。每个事务产生的页面数量在database的配置文件中配置。配置的agents数量影响到存储的i/o并发。page：页面page是i/o操作的单元。tablespace，container，table和area是以pages计算大小而不是字节数。页面有三个属性：所属的container，在container中的偏移位置，i/o类型(读/写)。当处理事务时，会产生随机页面。table、area和i/o类型页面的选择都是基于tables和areas中定义的负载百分比。bufferpool：缓冲池(bufferpool)是一个具有最大长度限制的块先进先出(firstinfirstout，fifo)队列。两种线程会对其进行操作：agents线程和pagecleaners线程。agents将写页面放到缓冲池的头部，pagecleaners线程从缓冲池的尾部取页面并写到containers中。当缓冲池为空，pagecleaners将等待，直到agents向队列里面放入页面。当缓冲池已满，agents需要等待，直到pagecleaners从队列中取出页面。当缓冲池已满，agents需要等待一个新的空间。这将导致事务时延，我们称之为空闲缓冲区等待等待时间(freebufferbusywaitlatency)。缓冲池简单地模拟了rdbms中的cache。大多数常用rdbmscache是通过具有水位(waterlevel)的lru算法实现的。当cache使用低于waterlevel时，没有页面会被同步。当cache使用超过了waterlevel时，pagecleaners(或者叫dbwriters)选择最近最少使用的脏页面进行同步和清除。当低于waterlevel时，模型数据库和rdbms是不同的；但当高于waterlevel时，模型数据库和rdbms是完全相同的，因为跟踪日志是在块设备上采样而不是在cache中采样。实际上，缓冲池模拟了rdbms的cache中最近最少使用的页面。模型数据库中的写页面(writtenpages)模拟了rdbms中被pagecleaners线程从cache中换出的页面。因此，一个模型数据库配置只能模拟被跟踪的生产环境，生产环境的任何改变将导致不同的i/o。例如给数据库服务器增加内存将导致施加到存储的物理i/o更少，因此，前面建模的模型数据库不再能够衡量新环境的性能了。logrecord：日志记录(logrecord)是一个数据结构，记录事务中产生的所有写pages。每个事务有一个日志记录。当事务结束时，日志记录被写到日志缓冲区中，此时，agents线程需要等待logwriter线程将日志记录同步到日志文件中后才产生下一个事务。日志记录模拟了rdbms中的重做日志记录redologrecord，但模型数据库中的日志记录并没有记录类似于rdbms中的pagechanges。模型数据库中的日志记录只记录写页面的位置，该记录不能用于数据恢复只能用于一致性检查。虽然存在差异，但i/o影响是相同的。模型数据库中日志记录的大小是恒定的，其值可以在database的配置文件中定义。一个事务中写页面的位置存放在日志记录的前面，日志记录的剩余空间用于填充随机数据。日志记录大小恒定并不意味着日志i/o大小恒定。在一个同步操作中，logwriter可以同步多个日志记录，因此，日志i/o大小是一个或者多个日志记录的大小，这取决于很多因素，例如事务负载和同步操作的速度。事实上，rdbms中的日志操作也存在这种现象。logbuffer：日志缓冲区(logbuffer)是一个具有最大长度限制的块先进先出(fifo)队列。两种线程可对其进行操作：agents和logwriter。agents将日志记录放到日志缓冲区的头部，logwriter从日志缓冲区的尾部取出日志记录并同步日志记录到日志文件中。当日志缓冲区为空，logwriter将等待直到日志记录被agents放入缓冲区中；当日志缓冲区已满，agents将等待直到日志记录被logwriter取出。当队列为空时，取出线程需要等待放入线程。当队列已满时，放入线程需要等待取出线程。因此，模型数据库中一个事务执行可能有四种时延：读page时延，日志记录同步时延，日志buffer等待时延和bufferpool等待时延。模型数据库将日志记录同步时延和日志buffer等待时延之和称为日志文件同步时延。logwriter能从日志缓冲区中取出多个日志记录。但每次同步操作同步的日志记录数不会超过日志记录的最大数，日志记录最大数可在database配置文件中定义。logwriter线程：负责同步logbuffer中的log记录到log文件的logsegments中。该线程模拟了关系型数据库管理系统(rdbms)中的日志记录同步线程。模型数据库中只有一个logwriter线程。日志文件由多个日志段(logsegment)组成。logwriter顺序写日志记录到logsegment中。在归档模式下，当一个logsegment已满，logwriter会将该logsegment放到归档队列中(archivequeue)，并切换日志到下一个logsegment进行顺序写操作。在非归档模式下，当一个logsegment已满，logwriter只切换到下一个logsegment，并写一个lsn记录到lsnjournal文件中。当最后一个logsegment已满，logwriter切换日志操作到第一个logsegment。logwriter每次从logbuffer中取出一个或者多个日志记录。如果取出多个日志记录，logwriter会将这多个日志记录合并为一个大i/o并写到日志文件中。pagecleaners线程：负责将bufferpool中的脏页面dirtypages写到containers中。该线程模拟了rdbms中脏页写线程，比如模拟了oracle数据库中的dbwriter以及db2中的pageclearner线程。当关闭数据库时，需要等到pagecleaners线程将bufferpool中所有脏页都写到containers中后才会终止数据库进程。归档archiver线程：在模型数据库为归档模式下，将所有的logsegments拷贝到归档文件archivefile中。当一个logsegment被归档了，logarchiver就会写一个日志段编号lsn(logsegmentnumber，一个lsn定义了3个属性：dbfileid、起始偏移地址、结束偏移地址，当logsegment切换时，会写lsn到lsnjournal文件，且一致性检查中也会用到lsn)记录到lsnjournal文件。备份调度器backupschedulers线程：负责调度备份任务，一旦到了备份时间，backupschedulers调用backup线程将备份源文件拷贝到备份目的文件中。备份源文件可以是container文件、日志文件或者归档文件。备份任务定义了6个属性：第一次备份时间、备份时间间隔、备份线程数、备份源、备份目录、备份目录的偏移。当执行备份任务时，backupscheduler启动多个线程进行备份i/o操作。备份操作的性能记录在“bkupmbps”性能计数器中。dbfile：数据库文件(dbfile)可以是本地文件系统的常规文件、网络文件系统上的文件或者裸(raw)设备。模型数据库没有模拟rdbms的自动扩展特性。数据库文件大小必须是恒定的，可在database的配置文件中定义。当一个文件被用作模型数据库的数据库文件时，必须初始化该文件的大小。在模型数据库中有四种数据库文件：日志文件(logfile)、归档文件(archivefile)、容器(container)和备份目标(backupdestination)。日志文件：用于存储事务日志记录，每个日志文件由多个日志段(logsegments)组成；日志段被循环覆盖写：日志记录被顺序地写入第一个日志段，如果第一个日志段已满，则切换日志操作到下一个日志段，直到切换到最后一个日志段；如果最后一个日志段已满，则日志切换到第一个日志段。当切换了日志段就写一个lsn到lsnjournal中来记录日志位置，用于一致性检查。lsn表示日志段编号(logsegmentnumber)，有3个属性：数据库文件id，起始偏移，结束偏移。在一致性检查操作中，checker线程从lsnjournal中读取预写入日志记录的位置信息。归档文件：用于归档模式下归档所有已写的日志段。容器：用于存放表数据。一系列的container组成一个条带化的表空间(tablespace)，表数据存放在表空间中。备份目标：用于存放备份集。备份集是一系列数据库文件的完全拷贝。数据库文件大小必须小心配置：日志文件被循环写，因此日志段的数量必须大于2，且每个日志段的大小不能太小。推荐日志段数量为大于或等于5，每个日志段配置大于100mb空间。monitor线程与database线程相互独立。monitor监听一个特定的端口。所有databases可以连接到这个端口。monitor周期性地发送命令给所有连接到这个端口的databases。当database接收到一个命令，database就提交其相应的性能数据给monitor。monitor计算所有数据库的性能计数器，并打印到屏幕上，同时将性能数据记录到性能日志文件中。当database提交性能数据时，database打印性能数据到本地终端屏幕上，同时也将性能数据记录到本地日志文件中。monitor线程监控的性能计数器有：timestamp–性能数据的时间戳tps–每秒事务数avgtlat–平均事务处理时延maxtlat–最大事务处理时延avgrlat–平均page读操作时延maxrlat–最大page读操作时延avglfsync–平均日志文件同步时延maxlfsync–最大日志文件同步时延avgfbwait–平均空闲buffer等待时延maxfbwait–最大空闲buffer等待时延rps–每秒page读操作次数wps–每秒脏page写操作次数bkupmbps–每秒备份兆字节数(mb/s)下面对本申请实施例中的表空间(tablespace)、表(table)和容器(container)分别进行说明：如图8所示，为本申请实施例中表空间和表的一个示意图；表空间用于存放表数据。一个表空间包含一个或者多个containers。表空间中的containers的条带单元为区(extent)。同一个表空间中的container的大小必须相同。其中，模型数据库中的表空间可以有不同的页面大小，这与rdbms相似。在rdbms系统中，每个页面大小必须至少有一个缓冲池或者cache。但在模型数据库中不必要为每个页面大小分配至少一个缓冲池，因为模型数据库中的缓冲池只是一个简单的fifo队列，该种队列能传输不同大小的页面。table是tablespace中一组连续的页面。table实际上模拟了rdbms中的数据段(datasegment)，table是一个非分区表或者非分区索引或者是表/索引分区。rdbms中的数据段只能使用一个表空间的空间，在模型数据库中也是如此。每个table都有一个特定的负载百分比和读/写百分比。当模型数据库中agents线程发布事务时，会生成一组随机页面。agents线程基于table的负载百分比选择table页面，并基于读写百分比选择页面的读/写属性。如图9所示，为本申请实施例中区域的一个示意图；分析跟踪生产环境得到的跟踪日志文件得到表的负载百分比，再根据这些负载百分比将表分为多个区域。在模型数据库中，当agents线程产生和发起一个事务时，会根据负载百分比选择区域页面。区域模拟了rdbms中datasegment的一部分。区域有特定的读、写负载百分比。具有高负载百分比的区域称为热点区域，具有低负载百分比的区域称为冷区域。从上述图9中可以看出各区域从热到冷分别为：area3>area1>area2>area0。热点区域被应用频繁访问的概率更大。区域的定义是模型数据库的重点之处。通过跟踪和分析真实rdbms生产环境中的每个段的i/o操作，并建模形成模型数据库中的区域。在分析阶段，每个段的lba地址被分成非常小的单元(可能1％)，再计算每个lba单元的负载，最终将具有相似负载的连续lba地址单元合并为一个area。模拟的精确性依赖于area的定义。area定义得越小，模拟的精确性越高。但最重要的是：i/o跟踪必须正确且能反应真实的工作负载。如图10所示，为本申请实施例中一致性检查的示意图，一致性检查器(consistencychecker)线程负责检查被测存储数据的一致性。在模型数据库中，每个扇区的最后一个字节用作预留。当写一个页面时，会计算该页面所包含的所有扇区的一个校验和字节，并存储在每个扇区的预留字节中。当进行一致性检查时，checker线程从lsnjournal中读取lsns来查找预写入的日志记录。从预写入的日志段中读出日志记录，定位到预写入的页面。checker线程从container中读出预写入的页面，并重新计算校验和，同时与扇区中保存的校验和进行比较。如果两个校验和不相等，就发生一个一致性错误。该错误会被写到checkerjournal中。如果错误数量超过了最大设置值，则一致性检查失败。下面以实际应用场景对本发明技术方案做进一步的说明，如图11所示，为本申请实施例中生产环境为db2v95的数据库生产环境示意图。在db2v95的数据库生产环境中，运行tpccrunner工具产生tpcc-like的工作负载。该生产环境中有9个表，每个表存放在独立的表空间上。每个表空间只包含一个container。每个container由存储系统上单独的一个lun创建。索引与其对应的表存放在同样的表空间中。另外，一个lun用于存放日志文件，一个lun存放归档文件，两个lun用作备份目标。所以，在存储系统上总共有13个lun，在实际应用中，这里对于备份目标的lun的数量不作具体限定。下面结合本申请实施例中所提出的方案对上述的生产环境进行跟踪，(1)将跟踪客户端(tracingclient)通过ge交换机与存储系统相连，在tracingclient上运行远程控制脚本trace.pl调用存储系统命令进行i/o跟踪。trace.pl跟踪脚本使用expect工具和调用ssh命令登陆到存储系统上并发送“cacheshowlogio”跟踪命令。所有发送给cache和从cache返回的i/o都会被跟踪。在存储系统上共有13个lun，该跟踪脚本会每隔一秒钟以轮询方式跟踪每个lun。假设，在tpc-c测试稳定阶段跟踪30分钟，这样跟踪的数据能代表tpc-c工作负载。如图12所示，为跟踪工具跟踪存储系统的一个示意图；跟踪时记录每个i/o的时间戳、lunid、lun大小、i/o操作码、i/o扇区和i/o大小、偏移量等信息。虽然对存储cache的操作有很多，但我们只需分析代表来自于主机系统的两种操作：cachefrontread和cachefrontwrite。所有跟踪数据保存在跟踪日志文件trace.log中。(2)对跟踪日志文件进行分析，确定分析报告。主要分析获取所有lunid、lun大小、将lun大小转换为扇区(sector)数量(lun大小(mb)*1024*2)，根据扇区数量和偏移量，可以确定每个lun的lba地址。由于db2中page的大小为4kb，所以i/o大小范围为：4kb-512kb，且每种i/o大小都是4kb的整数倍，所以，这种情况下共有128种i/o大小。在上述跟踪工具跟踪的时候，还会获取db2环境的参数、活动日志、tpccrunner测试性能数据(tps)、存储系统性能数据(iops)，并根据db2参数和活动日志设置模型数据库的配置。需要说明的是，还可以将跟踪时间按照每4ms为一个瞬时时间进行划分，对跟踪时间做一个更细致的分析，那么，得到的分析报告来说，也就越准确，但是，相对应的工作量也会增加，所以，可结合实际需求而定。①统计分析每个lun的读百分比(lun的读i/o总数/lun的i/o总数)、写百分比(lun的写i/o总数/lun的i/o总数)、负载百分比(lun的i/o总数/所有lun的i/o总数)、读负载百分比(lun的读i/o总数/所有lun的读i/o总数)、写负载百分比(lun的写i/o总数/所有lun的写i/o总数)。②统计分析每个lun每种i/o大小的负载百分比(lun在某种i/o大小时的i/o总数/lun的i/o总数)、读负载百分比(lun在某种i/o大小时的读i/o总数/lun的读i/o总数)、写负载百分比(lun在某种i/o大小时的写i/o总数/lun的写i/o总数)。③将每个lun的lba地址和时间划分为100份，统计分析每个lun每种i/o大小在每个lba地址单元内的读负载百分比(lun在某种i/o大小某lba地址单元内的读i/o总数/lun的读i/o总数)、写负载百分比(lun在某种i/o大小某lba地址单元内的写i/o总数/lun的写i/o总数)。统计分析每个lun每种i/o大小在每个时间单元内的读负载百分比(lun在某种i/o大小某时间单元内的读i/o总数/lun的读i/o总数)、写负载百分比(lun在某种i/o大小某时间单元内的写i/o总数/lun的写i/o总数)。(3)根据分析报告和目标数据库的参数进行建模，得到模型数据库的配置文件。配置文件中可以包括：数据库的名称、monitor线程所在主机的ip地址、monitor监听端口、每事务产生的i/o数(iops/tps)、归档和备份操作中顺序i/o的大小、checkseed(进行扇区checksum计算的8位无符号整型数)、数据库是否开启归档模式。数据文件的文件id和文件路径。文件路径可以是裸设备盘符路径或者常规文件路径。tablespace的id、页面大小、扩展页面数。表空间是由多个container组成，需设置表空间中包含的容器id、每个容器对应的文件id、容器页面数量。同一表空间中所有容器的页面数量需设置一样。容器的数量和页面数量由db2的containers已使用容量建模得到。table的id、表所在表空间的id、表在表空间中起始页面数、表的页面数量、负载百分比、读百分比、表包含的区域、区域的容量百分比、读负载百分比、写负载百分比。table的数量由db2的tables建模得到，容量百分比和负载百分比太小的表可以忽略不用建模。实际中只对order_line、stock、customer、history、order、new_order进行了建模。表的页面数量根据分析得到表的容量百分比计算得到。由于每个lun上只存放了一个表，所以，表所在lun的负载百分比即为表的负载百分比。每个表中具有相似负载的相邻lba地址单元合并为一个较大的lba地址单元，该较大的lba地址单元建模为模型数据库中表的area。缓冲池的大小(以页面数量表示)、日志缓冲区的大小(以日志记录数表示)。logwriter的日志文件id、日志段大小、日志段个数、日志记录大小、每次同步操作能够同步的最大日志记录数。这里的日志文件id即为数据文件的文件id。日志段大小*日志段个数的结果必须小于日志文件的大小。archive的归档文件id、归档文件大小、每次归档可挂起的最大日志段数。backupschedulers的数据库启动后开始进行第一次备份的时间、以后每次备份的时间间隔、备份线程数、备份源文件id、备份目标文件id、备份目标文件偏移地址。工作负载workload的名称、测试运行时间、agents线程数、pagecleaners线程数、每秒最大事务数。db2中agents和cleaners建模为模型数据库中的workload。tpccrunner测试的tps建模为模型数据库配置文件的每秒最大事务数。按照这种定义，可以模拟高中低等各种负载测试。(4)启动模型数据库进行模拟测试。database线程会顺序地执行配置文件中定义的工作负载workload。main线程与monitor程序进行通信。main线程每次收到monitor发送的获取性能数据的命令后，会计算所有agents线程的性能数据并反馈给monitor；同时，将性能数据打印到屏幕上以及保存到性能日志文件中。模拟测试过程中，还会产生lsn日志文件，用于数据一致性检查。(5)运行monitor监控程序对所有连接到该monitor的数据库性能进行统计。monitor可以每隔10s向每个数据库发送获取性能数据的命令，并统计性能数据，将其打印到屏幕上和保存到性能日志文件中。模型数据库可以在任何时间连接或者退出monitor。所以，只有当workload更改时才需要关闭monitor。monitor对于模型数据库是必要的。如果模型数据库连接到一个不存在的monitor，则数据库启动失败；如果模型数据库连接到的monitor已经关闭，则数据库会退出并报连接错误。(6)当模拟测试完成后，可通过重启存储或者主机模拟发生故障。然后使用checker程序进行数据的一致性检查。上面对本申请实施例中的建立模型数据库的方法进行了说明，下面对本申请实施例中的客户端进行说明，如图13所示，为本申请实施例中客户端的一个实施例示意图，包括：获取模块1301，用于获取生产环境中关于存储的i/o特征和i/o负载，以及生产环境中目标数据库的配置参数；分析模块1302，用于对i/o特征和i/o负载进行分析，确定分析报告；确定模块1303，用于根据分析报告和目标数据库的配置参数，确定模型数据库的配置文件。可选的，在本申请的一些实施例中，获取模块1301，具体用于获取生产环境中在预置时长内，关于存储的各个逻辑单元号lun的i/o特征和i/o负载；还用于获取生产环境中关于存储的每个逻辑单元号标识lunid和每个lun的大小。可选的，在本申请的一些实施例中，i/o特征包括i/o大小、偏移量和时间戳，i/o负载包括读i/o次数和写i/o次数；分析模块1302，具体用于根据时间戳、读i/o次数、写i/o次数和每个lunid，确定每个lun的读百分比、写百分比、负载百分比、读负载百分比和写负载百分比；具体用于根据预先确定的i/o大小的类别、时间戳、读i/o次数、写i/o次数和每个lunid，确定每个lun中每种i/o大小的负载百分比、读负载百分比和写负载百分比；具体用于根据偏移量、每个lunid和每个lun的大小，确定每个lun的lba地址；将预置时长均分为n等份，将每个lun的lba地址均分为m等份；根据预先确定的i/o大小的类别、时间戳、读i/o次数、写i/o次数和每个lunid，确定每个lun中每种i/o大小在每个1/n时间单元内的读负载百分比和写负载百分比，以及每个lun中每种i/o大小在每个1/m地址单元内的读负载百分比和写负载百分比。可选的，在本申请的一些实施例中，在上述图13所示的基础上，如图14所示，为本申请实施例中客户端的另一个实施例示意图，该客户端还包括：转换模块1304，用于若分析报告的配置文件格式与模型数据库的目标文件格式不同，则将分析报告的配置文件格式转换为目标文件格式。可选的，在本申请的一些实施例中，在上述图13所示的基础上，如图15所示，为本申请实施例中客户端的另一个实施例示意图，该客户端还包括：得到模块1305，用于根据模型数据库对目标数据库进行性能测试，得到测试结果；生成模块1306，用于根据测试结果，生成测试报告。可选的，在本申请的一些实施例中，在上述图15所示的基础上，如图16所示，为本申请实施例中客户端的另一个实施例示意图，该客户端还包括：获取模块1301，用于获取日志段编号lsn日志文件；检查模块1307，用于根据lsn日志文件，对目标数据库中的数据进行一致性检查。如图17所示，为本申请实施例中客户端的一个实施例示意图，可以包括：该客户端可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessingunits，cpu)1722(例如，一个或一个以上处理器)和存储器1732，一个或一个以上存储应用程序1742或数据1744的存储介质1730(例如一个或一个以上海量存储设备)。其中，存储器1732和存储介质1730可以是短暂存储或持久存储。存储在存储介质1730的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对客户端中的一系列指令操作。更进一步地，中央处理器1722可以设置为与存储介质1730通信，在客户端上执行存储介质1730中的一系列指令操作。客户端还可以包括一个或一个以上电源1726，一个或一个以上有线或无线网络接口1750，一个或一个以上输入输出接口1758，和/或，一个或一个以上操作系统1741，例如windowsservertm，macosxtm，unixtm,linuxtm，freebsdtm等等。上述各个实施例中由客户端所执行的步骤可以基于该图17所示的客户端结构。在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solidstatedisk(ssd))等。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。当前第1页12当前第1页12