本发明属于数据库技术领域，尤其涉及一种sql脚本的故障修复方法及其终端。
背景技术：
sql脚本，作为数据查询的常用手段，被广泛应用于网络服务领域，每个sql脚本的数据搜索策略，主要由该sql脚本中查询因子序列确定的，数据库将根据sql脚本中查询因子序列中各个查询因子的先后顺序，确定数据查询时，先搜索哪一种类的关键词，再搜索哪一种类的关键词，因此sql脚本中各个查询因子的排序，将直接决定其运行的效率以及服务响应的快慢。另一方面，为了提高数据查询的效率，用户可根据自身的搜索习惯以及搜索目的，为每个sql脚本制定一个运行控制文件，该策略中包含发起一次调用请求时，该sql脚本的运行次数以及赋予该sql脚本中各个查询因子预设的参数值，从而实现“一键查询”的目的。
若某一sql脚本出现故障情况，则可能是由于该sql脚本中各个查询因子排布次序不合理导致，或者是由于该sql脚本对应的运行控制文件进行配置出错而导致的。然而现有的sql脚本的故障修复技术，需要人工对数据库中包含的sql脚本一一进行手动排查，故障检测效率较低，并且检测到故障的sql脚本后，也依赖维护人员的专业知识进行人工故障修复，也进一步降低了sql脚本故障响应的效率。
技术实现要素：
有鉴于此，本发明实施例提供了一种sql脚本的故障修复方法及其终端，以解决现有的sql脚本的故障修复技术，需要人工对数据库中包含的sql脚本一一进行手动排查，故障检测效率较低，并且检测到故障的sql脚本后，也依赖维护人员的专业知识进行人工故障修复，也进一步降低了sql脚本故障响应的效率的问题。
本发明实施例的第一方面提供了一种sql脚本的故障修复方法，所述sql脚本的故障修复方法包括：
若监测到故障sql脚本，则获取所述故障sql脚本的脚本标识；
根据所述脚本标识，获取所述故障sql脚本对应的运行控制文件；其中，所述运行控制文件具体用于：确定脚本调用终端每发起一次脚本调用操作时，执行所述故障sql脚本的循环次数，以及确定每次循环执行所述故障sql脚本时，该故障sql脚本内各个查询因子所取的取值；
基于预存的调用资源占用记录，确定执行各个运行控制文件时对应的消耗特征值；其中，所述消耗特征值用于表示调用所述运行控制文件时对设备资源的占用情况；
获取所述消耗特征值大于预设的消耗阈值的消耗特征值个数，得到所述故障sql脚本对应的异常消耗比例；
若所述异常消耗比例大于预设的比例阈值，则判定所述故障sql脚本中的查询因子序列出现异常，调整所述查询因子序列；所述查询因子序列具体用于：当脚本调用终端调用sql脚本执行数据查询操作时，根据各个查询因子在所述查询因子序列中的顺序，确定各个所述查询因子的查询次序；
若所述异常消耗比例小于或等于预设的比例阈值，则识别所述消耗特征值大于预设的消耗阈值的运行控制文件为故障控制文件，并修复所述故障控制文件。
本发明实施例的第二方面提供了一种终端设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现以下步骤：
若监测到故障sql脚本，则获取所述故障sql脚本的脚本标识；
根据所述脚本标识，获取所述故障sql脚本对应的运行控制文件；其中，所述运行控制文件具体用于：确定脚本调用终端每发起一次脚本调用操作时，执行所述故障sql脚本的循环次数，以及确定每次循环执行所述故障sql脚本时，该故障sql脚本内各个查询因子所取的取值；
基于预存的调用资源占用记录，确定执行各个运行控制文件时对应的消耗特征值；其中，所述消耗特征值用于表示调用所述运行控制文件时对设备资源的占用情况；
获取所述消耗特征值大于预设的消耗阈值的消耗特征值个数，得到所述故障sql脚本对应的异常消耗比例；
若所述异常消耗比例大于预设的比例阈值，则判定所述故障sql脚本中的查询因子序列出现异常，调整所述查询因子序列；所述查询因子序列具体用于：当脚本调用终端调用sql脚本执行数据查询操作时，根据各个查询因子在所述查询因子序列中的顺序，确定各个所述查询因子的查询次序；
若所述异常消耗比例小于或等于预设的比例阈值，则识别所述消耗特征值大于预设的消耗阈值的运行控制文件为故障控制文件，并修复所述故障控制文件。
本发明实施例的第三方面提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：
若监测到故障sql脚本，则获取所述故障sql脚本的脚本标识；
根据所述脚本标识，获取所述故障sql脚本对应的运行控制文件；其中，所述运行控制文件具体用于：确定脚本调用终端每发起一次脚本调用操作时，执行所述故障sql脚本的循环次数，以及确定每次循环执行所述故障sql脚本时，该故障sql脚本内各个查询因子所取的取值；
基于预存的调用资源占用记录，确定执行各个运行控制文件时对应的消耗特征值；其中，所述消耗特征值用于表示调用所述运行控制文件时对设备资源的占用情况；
获取所述消耗特征值大于预设的消耗阈值的消耗特征值个数，得到所述故障sql脚本对应的异常消耗比例；
若所述异常消耗比例大于预设的比例阈值，则判定所述故障sql脚本中的查询因子序列出现异常，调整所述查询因子序列；所述查询因子序列具体用于：当脚本调用终端调用sql脚本执行数据查询操作时，根据各个查询因子在所述查询因子序列中的顺序，确定各个所述查询因子的查询次序；
若所述异常消耗比例小于或等于预设的比例阈值，则识别所述消耗特征值大于预设的消耗阈值的运行控制文件为故障控制文件，并修复所述故障控制文件。
实施本发明实施例提供的一种sql脚本的故障修复方法及其终端具有以下有益效果：
本发明实施例通过终端设备检测各个sql脚本的运行情况，若监测到存在故障的sql脚本，则启动故障修复流程，获取该故障sql脚本对应的脚本标识，继而通过该脚本标识，查询该故障sql脚本所对应的运行控制文件，确定数据库在调用该故障sql脚本时所对应的调用策略，继而根据各个运行控制文件对应的消耗特征值，定位该次故障是由于sql脚本本身导致的，抑或是某些运行控制文件中相关参数设置不合理而导致的。因此，终端设备在计算了各个运行控制文件对应的消耗特征值后，将该消耗特征值与预设的消耗阈值进行比较，确定大于预设消耗阈值的消耗特征值个数，继而确定其异常消耗比例，若该异常消耗比例大于预设的比例阈值，则表示大部分的运行控制文件均处于异常消耗的情况，因此将表示并非运行控制文件中参数设置不合理，而是该故障sql脚本本身存在问题，从而导致了调用该sql脚本的各个运行控制文件发生异常消耗；反之，若异常消耗比例小于或等于预设的比例阈值，则表示只有部分运行控制文件存在异常消耗情况，因此可以判定并非sql脚本本身存在异常，而是部分运行控制文件中的循环参数设置不合理导致的，因此对异常消耗的运行控制文件进行修复调节。因此，终端设备通过识别故障sql脚本的消耗异常成因，执行对应的修复操作，从而提高了修复的准确性。与现有的sql脚本的故障修复技术相比，故障修复整个流程均由终端设备自动执行，无需数据库的管理人员进行人工操作，从而提高了故障修复的效率。另一方面，由于故障修复的过程不依赖维护人员的专业技能水平，终端设备可通过相应的修复算法对故障sql脚本进行修复，从而降低了系统的维护成本。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本发明第一实施例提供的一种sql脚本的故障修复方法的实现流程图；
图2是本发明第二实施例提供的一种sql脚本的故障修复方法s105的具体实现流程图；
图3是本发明第三实施例提供的一种sql脚本的故障修复方法s106的具体实现流程图；
图4是本发明第四实施例提供的一种sql脚本的故障修复方法s106的具体实现流程图；
图5是本发明第五实施例提供的一种sql脚本的故障修复方法s101的具体实现流程图；
图6是本发明一实施例提供的一种sql脚本的故障修复终端的结构框图；
图7是本发明一实施例提供的一种终端设备的示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
本发明实施例通过终端设备检测各个sql脚本的运行情况，若监测到存在故障的sql脚本，则启动故障修复流程，获取该故障sql脚本对应的脚本标识，继而通过该脚本标识，查询该故障sql脚本所对应的运行控制文件，确定数据库在调用该故障sql脚本时所对应的调用策略，继而根据各个运行控制文件对应的消耗特征值，定位该次故障是由于sql脚本本身导致的，抑或是某些运行控制文件中相关参数设置不合理而导致的。因此，终端设备在计算了各个运行控制文件对应的消耗特征值后，将该消耗特征值与预设的消耗阈值进行比较，确定大于预设消耗阈值的消耗特征值个数，继而确定其异常消耗比例，若该异常消耗比例大于预设的比例阈值，则表示大部分的运行控制文件均处于异常消耗的情况，因此将表示并非运行控制文件中参数设置不合理，而是该故障sql脚本本身存在问题，从而导致了调用该sql脚本的各个运行控制文件发生异常消耗；反之，若异常消耗比例小于或等于预设的比例阈值，则表示只有部分运行控制文件存在异常消耗情况，因此可以判定并非sql脚本本身存在异常，而是部分运行控制文件中的循环参数设置不合理导致的，因此对异常消耗的运行控制文件进行修复调节。因此，终端设备通过识别故障sql脚本的消耗异常成因，执行对应的修复操作，从而提高了修复的准确性，解决了现有的sql脚本的故障修复技术，需要人工对数据库中包含的sql脚本一一进行手动排查，故障检测效率较低，并且检测到故障的sql脚本后，也依赖维护人员的专业知识进行人工故障修复，也进一步降低了sql脚本故障响应的效率的问题。
在本发明实施例中，流程的执行主体为sql脚本的故障修复终端，终端设备包括手机、计算机设备、平板电脑、服务器等终端，特别地，该终端设备具体为一布放于数据库系统中的sql脚本的故障修复终端，通过获取各个sql脚本在数据库中的运行情况，并对各个sql脚本进行故障修复以及维护操作，该数据库系统中，包含多个数据服务器，各个数据库服务器调用sql脚本资源库中的sql脚本，完成对应的搜索、数据提取操作。图1示出了本发明第一实施例提供的sql脚本的故障修复方法的实现流程图，详述如下：
在s101中，若监测到故障sql脚本，则获取所述故障sql脚本的脚本标识。
在本实施例中，sql脚本可运行于终端设备的数据库内，该情况下，待检测的终端即为本发明实施例提供的终端设备，即检测本地数据库中各个sql脚本是否存在异常情况；sql脚本也可以运行于终端设备外的其他数据库服务器中，在该情况下，终端设备即作为一独立的检测终端，监控该数据库服务器中的sql脚本是否存在异常情况。特别地，终端设备还可以检测一数据库系统，该数据库系统中包含多个数据库服务器，且各个数据库服务器均从同一个sql脚本资源库中提取对应的sql脚本进行查询操作。其中，sql脚本资源库中存储有多个sql脚本，用于满足不同用户的查询需求，例如用户需要查询季度奖金相关的数据，则通过调用第一sql脚本进行查询；用户需要统计车险客户的续保情况，则通过调用第二sql脚本进行查询。
在本实施例中，终端设备将以预设的频率或以预设的监测触发条件，获取数据库中各个sql脚本的运行参数，根据各个sql脚本的运行参数与预设的运行参数阈值进行比较，确定上述监测的sql脚本中是否存在故障sql脚本。若监测到存在故障sql脚本，则执行s101的相关操作；反之，若各个sql脚本的运行参数均处于正常的参数范围内，终端设备则等待下一个监测时机的到达，并重复执行上述步骤。
在本实施例中，脚本监测的触发条件包括手动触发以及自动触发两种模式。其中，手动触发具体为：管理员在终端设备上生成一个脚本监测的启动指令，或通过用户终端向终端设备发送一个脚本监测启动指令，终端设备若接收到该异常检测启动指令后，则执行s101的相关操作。而自动触发具体为：终端设备设置有脚本监测启动时机，若终端设备检测到当前状态与预设的异常检测启动时机匹配，则执行s101的相关操作。
在本实施例中，各个sql脚本均对应一个脚本标识，作为每个脚本的身份标识。该脚本标识可以为：脚本名称、脚本唯一标识码、脚本唯一标识码对应的哈希值、脚本编号等具有身份标识功能的字符或字符串。终端设备在监测到某一sql脚本为故障sql脚本时，为了确定该故障sql脚本相关的运行情况以及相关信息，将获取该故障sql脚本对应的脚本标识，通过进行信息查询。
可选地，sql脚本的异常监测操作，可交由其他终端设备诶完成。在该情况下，sql脚本的异常监测终端在确定数据库中存在故障sql脚本时，将发送故障修复请求给本发明实施例提供的终端设备，该故障修复请求中包含故障sql脚本的脚本标识，该故障修复请求中可包含一个故障sql脚本，也可以包含两个或以上的故障sql脚本。终端设备在接收到该sql脚本的异常监测终端发送的故障修复请求后，将执行s101的相关操作。
在s102中，根据所述脚本标识，获取所述故障sql脚本对应的运行控制文件；其中，所述运行控制文件具体用于：确定脚本调用终端每发起一次脚本调用操作时，执行所述故障sql脚本的循环次数，以及确定每次循环执行所述故障sql脚本时，该故障sql脚本内各个查询因子所取的取值。
在本实施例中，数据库在实际调用各个sql脚本时，将根据该sql脚本对应的运行控制文件执行调用操作。由于sql脚本中一般只是定义了所包含的查询因子，以及以一定的次序排列各个查询因子，但每个查询因子所取的参数值以及每次调用所循环的次数，是根据数据库每一次所要查询的内容决定的。因此，为了明确上述内容，数据库将基于该sql脚本生成一个运行控制文件，该运行控制文件中包含一次调用操作中，执行该sql脚本的循环次数，以及每次循环操作中，各个查询因子所取的取值。
例如，用户在调用一次sql脚本时，需要对比广州地区以及深圳地区的投保比例，即该sql脚本中包含两个查询因子，分别为“地区”以及“是否投保”。为了实现上述对比两个地区的投保比例，数据库将生成一个运行控制文件，该运行控制文件的循环次数为2，第一次循环时“地区”的查询因子取值为“广州”，“是否投保”的查询因子的取值为“是”，从而获取了广州地区的投保比例；而第二次循环时“地区”的查询因子取值为“深圳”，“是否投保”的查询因子的取值为“是”，从而获取了深圳地区的投保比例，根据上述两个投币比例，即可实现两个地区的投保情况的比对。诸如上述的情况，数据库在调用第一次sql脚本时，往往需要循环多次操作，并赋予该sql脚本中各个查询因子不同的取值。
在本实施例中，一个故障sql脚本可对应多个运行控制文件，实现数据库不同搞得查询功能。终端设备将通过故障sql脚本对应的脚本标识，从运行控制文件库中获取与该脚本标识对应的运行控制文件。需要说明的是，一个运行控制文件是基于一个sql脚本生成的，即每个运行控制文件只对应一个脚本标识。
在s103中，基于预存的调用资源占用记录，确定执行各个运行控制文件时对应的消耗特征值；其中，所述消耗特征值用于表示调用所述运行控制文件时对设备资源的占用情况。
在本实施例中，终端设备每一次在数据库执行运行控制文件时，则记录对应的消耗特征值，继而生成预存的调用资源占用记录。终端设备在获取了故障sql脚本所对应的运行控制文件后，将根据运行控制文件对应的文件标识，查询该调用资源占用记录，确定该运行控制文件被调用的次数以及每一次调用时所对应的消耗特征值，继而根据多次调用时对应的消耗特征值，计算得到该运行控制文件对应的消耗特征值。
可选地，在本实施例中，终端设备获取的调用资源占用记录具体为本次监测周期内的占用资源记录，由于在本次监测周期内，确定该故障sql脚本存在异常状态，即表示具体异常消耗情况也是存在于本次监测周期的调用操作中，因此，终端设备也只是统计本次监测周期内，各个运行控制文件所对应的消耗特征值，从而减少了统计的运算量，也提高了故障修复的效率。特别地，若部分运行控制文件在本次调用周期内并未被调用，则其对应的消耗特征值为0。
可选地，在本实施例中，调用占用消耗记录中记录的是数据库每次调用运行控制文件时对应的运作状态参数，在该情况下，终端设备将每个运行控制文件对应的运行状态参数导入到预设的消耗特征值转换模型内，计算得到各个运行状态参数对应的消耗特征值。
在s104中，获取所述消耗特征值大于预设的消耗阈值的消耗特征值个数，得到所述故障sql脚本对应的异常消耗比例。
在本实施例中，终端设备将各个运行控制文件对应的消耗特征值与预设的消耗阈值进行比较，确定消耗特征值大于预设的消耗阈值的消耗特征值个数，并将消耗特征值大于预设的消耗阈值的运行控制文件识别为故障控制文件，继而根据故障控制文件的个数以及运行控制文件的总个数，得到该故障sql脚本所对应的异常消耗比例。
例如，该故障sql脚本对应有10个运行控制文件，其中预设的消耗阈值为50％，而终端设备检测到4个运行控制文件的消耗特征值大于50％，则识别故障控制文件的个数为4，继而得到该故障sql脚本对应的异常消耗比例为0.4。
可选地，在本实施例中，终端设备为各个运行控制文件匹配对应的消耗阈值，即终端设备在执行s104的操作时，首先识别该运行控制文件的文件标识，继而从预存的运行文件标准消耗列表中，查询该文件标识对应的消耗阈值，并将该运行控制文件对应的消耗特征值与其对应的消耗阈值进行比对，确定该运行控制文件是否为故障控制文件。具体地，该运行文件标准消耗列表中，各个运行控制文件对应的消耗阈值为该运行控制文件的平均消耗特征值。
在本实施例中，终端设备在得到该异常消耗比例后，将该异常消耗比例与预设的比例阈值进行比较；若异常消耗比例大于预设的比例阈值，则执行s105的相关操作；反之，若异常消耗比例小于或等于预设的比例阈值，则执行s106的相关操作。
在s105中，若所述异常消耗比例大于预设的比例阈值，则判定所述故障sql脚本中的查询因子序列出现异常，调整所述查询因子序列；所述查询因子序列具体用于：当脚本调用终端调用sql脚本执行数据查询操作时，根据各个查询因子在所述查询因子序列中的顺序，确定各个所述查询因子的查询次序。
在本实施例中，终端设备确定该异常消耗比例大于预设的比例阈值，则表示该故障sql脚本中大部分的运行控制文件均处于异常消耗情况，从而可以确定该故障情况并不是个别案例，而是各个基于该故障sql脚本的运行控制文件的共性特征，因此终端设备将判定该故障sql脚本中的查询因子序列出现异常，从而导致了大部分基于该sql脚本生成的运行控制文件，均处于异常消耗的情况。
在本实施例中，sql脚本包含查询因子序列，该查询因子序列由以一定顺序排列的多个查询因子构成。数据库在调用该sql脚本时，将根据该查询因子序列中各个查询因子的次序，依次选取与查询因子的参数值对应的数据。
例如，序号为1的第一查询因子具体为“地区”，该查询因子在某次查询的过程中，对应的参数值为“深圳”，而序号为2的第二查询因子具体为“性别”，在该次查询的过程中，对应的参数值为“女”。因此，数据库在调用该sql脚本时，首先会将本次查询各个查询因子对应的参数值，导入到该sql脚本中，并从数据库中依次选取与上述查询因子均匹配的数据。首先，数据库将查询包含“深圳”这一参数的数据，得到第一查询结果；并从第一查询结果中，选取性别为“女”的数据，得到第二查询结果，通过上述过程依次迭代，继而得到最后的查询结果，完成一次完整的查询操作。
因此可以看出，由于得到第一查询结果时，数据库需要遍历全部数据得到第一查询结果，而第二次查询操作时，则从第一查询结果中再次选取对应的数据。因此，若第一查询因子的数据筛选效率较低，则第一查询结果中包含的数据量较大，数据库服务器需要将较多的缓存来存储该第一查询结果，并且第二查询因子在进行数据选取时，其对应的数据基数量也较大，因此会导致运行消耗较大，因此虽然sql脚本中包含的查询因子是固定的，但不同的排布将直接影响sql脚本的运行效率。因此，若判定该故障sql脚本的查询因子序列发生异常，则需要对该查询因子序列进行调整，将数据筛选效率较高的查询因子排在较前的位置，将数据筛选效率较低的查询因子排在较后的位置，继而使得整个查询因子序列的查询效率最高，降低查询消耗。
在s106中，若所述异常消耗比例小于或等于预设的比例阈值，则识别所述消耗特征值大于预设的消耗阈值的运行控制文件为故障控制文件，并修复所述故障控制文件。
在本实施例中，终端设备在确定了该异常消耗比例小于或等于预设的比例阈值时，则表示该异常消耗情况只是发生于小部分的运行控制文件上，即并非sql脚本本身存在异常，而是某部分的运行控制文件可能参数设置错误，从而导致异常情况发生，因此终端设备将对该部分消耗异常的运行控制文件进行故障修复。
在本实施例中，终端设备识别消耗特征值大于预设的消耗阈值的运行控制文件为故障控制文件，并获取各个故障控制文件中的控制参数，该控制参数包括：脚本循环次数以及每次循环时所各个查询因子所取的取值。终端设备基于控制参数以及预设的修复算法，分别对每个运行控制文件进行运行参数优化，以修复故障控制文件。
可选地，在s105或s106之后，终端设备还将获取修复后的故障sql脚本的运行状态参数，并判断该sql脚本的消耗情况是否处于正常范围，若是，则识别该次修复已完成；若该sql脚本修复后的消耗情况仍超出正常范围，则返回s103的相关操作，继续执行故障识别修复操作，直到返回次数大于预设阈值，则发送故障处理信息给该数据库对应的维护人员，以便维护人员进行手动修复。
以上可以看出，本发明实施例提供的一种sql脚本的故障修复方法通过终端设备检测各个sql脚本的运行情况，若监测到存在故障的sql脚本，则启动故障修复流程，获取该故障sql脚本对应的脚本标识，继而通过该脚本标识，查询该故障sql脚本所对应的运行控制文件，确定数据库在调用该故障sql脚本时所对应的调用策略，继而根据各个运行控制文件对应的消耗特征值，定位该次故障是由于sql脚本本身导致的，抑或是某些运行控制文件中相关参数设置不合理而导致的。因此，终端设备在计算了各个运行控制文件对应的消耗特征值后，将该消耗特征值与预设的消耗阈值进行比较，确定大于预设消耗阈值的消耗特征值个数，继而确定其异常消耗比例，若该异常消耗比例大于预设的比例阈值，则表示大部分的运行控制文件均处于异常消耗的情况，因此将表示并非运行控制文件中参数设置不合理，而是该故障sql脚本本身存在问题，从而导致了调用该sql脚本的各个运行控制文件发生异常消耗；反之，若异常消耗比例小于或等于预设的比例阈值，则表示只有部分运行控制文件存在异常消耗情况，因此可以判定并非sql脚本本身存在异常，而是部分运行控制文件中的循环参数设置不合理导致的，因此对异常消耗的运行控制文件进行修复调节。因此，终端设备通过识别故障sql脚本的消耗异常成因，执行对应的修复操作，从而提高了修复的准确性。与现有的sql脚本的故障修复技术相比，故障修复整个流程均由终端设备自动执行，无需数据库的管理人员进行人工操作，从而提高了故障修复的效率。另一方面，由于故障修复的过程不依赖维护人员的专业技能水平，终端设备可通过相应的修复算法对故障sql脚本进行修复，从而降低了系统的维护成本。
图2示出了本发明第二实施例提供的一种sql脚本的故障修复方法s105的具体实现流程图。参见图2所示，相对于图1所述实施例，本实施例提供的一种sql脚本的故障修复方法中s105还包括s201以及s204，具体详述如下：
进一步地，所述判定所述故障sql脚本中的查询因子序列出现异常，调整所述查询因子序列，包括
在s201中，根据所述故障sql脚本中查询因子序列包含的各个查询因子，获取数据库内每个数据中所述查询因子所取的参数值。
在本实施例中，终端设备将根据该查询因子序列中包含的各个查询因子，确定数据库中每个数据中该查询因子所取的参数值，继而确定该查询因子在数据库中包含多少个不同的参数值，得到对应的参数值个数。
例如，某一查询因子为“地区”，在数据库中，某部分数据“地区”所取的值为“广州”，某部分数据“地区”所取的值为“深圳”，某部分数据“地区”所取的值为“香港”，剩余部分数据“地区”所取的值为“澳门”，因此，该“地区”查询因子在数据库中包含4个不同的参数值，即其对应的参数值个数为4。而对于查询因子为“性别”，则可以确定其对应的参数值个数为2，即取值为“男”或取值为“女”。因此可见，参数值个数越大的查询因子，其对应的数据筛选效率则越高，还是利用上述的例子，“地区”查询因子可以从数据库中平均筛选出四分之一的数据，而“性别”查询因子则只可以从数据库中筛选出二分之一的数据。
在s202中，统计各个所述查询因子的参数值个数，并根据所述参数值个数，计算各个所述查询因子对应的区分度；其中，所述区分度用于表示所述查询因子对所述数据库中数据的筛选效率。
在本实施例中，终端设备在得到各个查询因子对应的参数值个数后，将根据该参数值个数导入到预设的区分度转换模型，从而计算出各个查询因子对应的区分度。其中，参数值个数越大的查询因子，其对应的区分度越大。由于区分度是用于表示该查询因子对数据库中数据的筛选效率，因此通过s201中阐述可以确定，参数值个数的筛选效率越高，因此其对应的区分度也越大。
需要说明的是，每个查询因子的参数值个数以及区分度是相对于某一数据库而言的，是一个相对特征值。即某一查询因子在第一数据库中的参数值个数为5，但在另一数据库中的参数值个数可以为9，即在另一数据库中包含更多不同的取值。同样地，区分度也具有该特征。由于查询因子的参数值个数以及区分度是相当于某一数据库而言的，因此若数据库中包含的数据发生改变，也将影响该查询因子对应的区分度以及参数值个数。例如数据库增加了数据、删除了数据或替换了部分数据，则可能改变了数据库中查询因子包含的参数值的种类，从而改变了各个查询因子的参数值个数以及区分度。由此可见，sql脚本发生异常，常常是由于sql脚本中对应的查询因子序列，并未根据数据库中数据的更新而进行调整。
可选地，可通过区分度计算模型计算各个查询因子的区分度，该区分度计算模型为：
其中，s(x)为所述查询因子的区分度，所述q(x)为所述查询因子的参数值个数，所述f(x)为所述查询因子的数据覆盖率，所述f总为数据库包含的总数据量，所述fx为包含所述查询因子的数据量。
在s203中，基于各个查询因子对应的区分度的数值，由大至小依次排列，生成标准查询因子序列。
在本实施例中，终端设备在获取了各个查询因子对应的区分度后，则根据各个区分度的数值大小，由大至小依次排列，既然生成标准查询因子序列。其中，区分度较大的查询因子，其序号越前，反之，区分度较小的查询因子，其序号越后。
可选地，若两个或以上的查询因子，其对应的区分度数值大小相同，则上述查询因子之间的相对位置可任意排列，例如查询因子a到f对应的区分度分别为：8、12、8、5、8、6，则调整后的标准查询因子序列可以为：bacefd、baecfd或者becafd，只要aec三个查询因子均排在b之后、fd之前即可。终端设备还可以根据区分度相同的查询因子其参数值个数的大小，设置上述查询因子之间的排列顺序。依然通过上述例子进行说明，查询因子ace其对应的区分度均为8，但a的参数值个数为7，c的参数值个数为9，而e的参数值个数为6，则上述三者之间的相对排序可以为：cae。
在s204中，将所述标准查询因子序列替换所述故障sql脚本中的查询因子序列。
在本实施例中，终端设备将根据各个查询因子对应的区分度的数值大小，有小到大依次排列，得到标准的查询因子序列，并将该标准的查询因子序列作为该sql脚本的查询因子序列，从而修复该故障的sql脚本，提高其查询效率。
在本实施例中，若故障sql脚本的查询因子序列中某些查询因子固定了对应的参数值，则终端设备在替换成功后，将各个查询因子对应的固定参数值配置至标准查询因子序列中，以保持修复后的sql脚本的查询策略一致。
在本发明实施例中，根据查询因子序列中各个查询因子对应的区分度，生成数据筛选效率最高的查询因子序列，并将该查询因子序列替换为故障sql脚本的查询因子序列，从而减少了数据库调用基于sql脚本生成的运行控制文件时的资源占用情况，从而修复故障的sql脚本，提高了故障修复的准确率。
图3了本发明第三实施例提供的一种sql脚本的故障修复方法中s106的具体实现流程图。参见图3所示，相对于图1所述实施例，本实施例提供的一种sql脚本的故障修复方法中，在s106包括s301～s302，具体详述如下：
进一步地，所述识别所述消耗特征值大于预设的消耗阈值的运行控制文件为故障控制文件，并修复所述故障控制文件，包括：
在s301中，获取所述故障控制文件对应的控制参数变更记录。
在本实施例中，终端设备还可以记录有各个运行控制文件的控制参数变更记录。该控制参数变更记录记载有该运行控制文件变更的参数、变更创建人、变更时间等信息，以便用户通过该变更记录获知运行控制文件的使用情况，是否存在未授权的用户更改过该运行控制文件，以及数据库的管理账户可根据该控制参数变更记录，随时还原运行控制文件至对应的版本。
在本实施例中，由于故障控制文件是在本次监测周期内才确定其消耗异常，即在监测周期之前该故障控制文件仍能被数据库正常调用，因此可以确定该该监测周期附近，该故障控制文件被部分用户修改过，因此通过还原该故障控制文件中相应的控制参数，即可修复该故障控制文件，因此将获取该故障控制文件对应的控制参数变更记录，并执行s302的相关操作。
在s302中，根据所述控制参数变更记录创建时间的逆序，逐次还原所述控制参数变更记录包含的变更内容，并监测所述故障控制文件对应的消耗特征值，直到所述故障运行策略对应的消耗特征值小于或等于预设的消耗阈值。
在本实施例中，终端设备将根据各个控制参数变更记录的创建时间的逆序，每一次还原一个控制参数变更记录中的变更内容，以便将故障运行控制文件逐步还原到正常的范围内，从而对故障情况进行修复。
在本实施例中，终端设备在每还原一个变更内容后，将获取还原后模拟运行一次故障控制文件，获取运行该故障控制文件时数据库的运行状态参数，并根据该运行状态参数计算其对应的消耗特征值，若该消耗特征值小于或等于预设的消耗阈值，则表示异常情况已修复成功，终止s302的相关操作；反之，若该第一消耗特征值仍大于预设的消耗阈值，则进行下一个变更内容的还原，重复执行上述操作。
在本发明实施例中，终端设备通过还原故障控制文件中的变更内容，实现对异常的运行控制脚本进行修复的目的，从而实现对自动故障情况进行修复，提高了异常的处理效率以及响应速度。
图4了本发明第四实施例提供的一种sql脚本的故障修复方法s106的具体实现流程图。参见图4所示，相对于图1所述实施例，本实施例提供的一种sql脚本的故障修复方法中s106包括s401以及s402，具体详述如下：
进一步地，所述识别所述消耗特征值大于预设的消耗阈值的运行控制文件为故障控制文件，并修复所述故障控制文件，包括：
在s401中，选取所述消耗特征值最小的运行控制文件作为优选运行文件。
在本实施例中，终端设备除了通过还原故障控制文件的变更内容进行故障修复外，还可以通过将较优的运行控制文件中对应的运行参数值推广至故障运行文件中，从而实现对故障控制文件的控制参数进行优化的目的。因此，终端设备首先需要确定该故障sql脚本对应的优选运行文件。
在本实施例中，终端设备将选取消耗特征值最小的运行控制文件作为优选运行文件，由于消耗越少，则表示数据库在运行该运行控制文件时所对应的搜索效率最高。当然，终端设备还可以根据其他判定规则选取优选运行文件，例如通过选取每次循环的运行时间最小的运行控制文件作为优选运行文件；还可以选取每次查询操作内存以及cpu消耗最小的运行控制文件作为优选控制文件。终端设备可根据不同的监测模式，选取与该监测模式关注的运行状态参数作为识别优选运行文件的判定条件。可选地，该选取的运行状态参数可以为两个或以上的状态运行参数。
在s402中，将所述优选运行文件中包含的循环次数以及各个查询因子的参数值，应用至所述故障控制文件。
在本实施例中，终端设备将获取优选运行文件中更包含的控制参数，包括循环次数以及各个查询因子所取的取值，并根据上述两个参数对故障控制文件进行修改，以修复故障控制文件的故障情况。具体地，该应用至故障控制文件具体为:终端设备将优选运行文件中的控制参数替换故障控制文件中的控制参数。
在本发明实施例中，终端设备通过确定优选运行文件，并将该优选运作文件中对应的运行控制参数应用到故障控制文件中，实现对故障进行修复的目的，提高了故障修复的准确性。
图5示出了本发明第五实施例提供的一种sql脚本的故障修复方法s101的具体实现流程图。参见图5所示，相对于图1至图4所示实施例，本实施例提供的一种sql脚本的故障修复方法中所述若监测故障sql脚本，则获取所述故障sql脚本的脚本标识，包括s501～s503，详述如下：
进一步地，所述若监测故障sql脚本，则获取所述故障sql脚本的脚本标识，包括：
在s501中，获取各个sql脚本的运行状态参数。
在本实施例中，异常检测的触发条件包括手动触发以及自动触发两种模式。其中，手动触发具体为：管理员在终端设备上生成一个异常检测启动指令，或通过用户终端向终端设备发送一个异常检测启动指令，终端设备若接收到该异常检测启动指令后，则执行s501的相关操作。而自动触发具体为：终端设备设置有异常检测启动时机，若终端设备检测到当前状态与预设的异常检测启动时机匹配，则执行s501的相关操作。
可选地，在本实施中，所述异常检测启动时机可以为一预设的检测周期，终端设备在监测到当前时刻满足该检测周期，则执行s501的相关操作。所述异常检测启动时机还可以为一运行消耗阈值，例如资源占用率，终端设备在监测到当前时刻待检测终端的运行消耗值大于或等于预设的运行消耗阈值，则执行s501的相关操作。由于设备的消耗过大，一般是由于sql脚本异常而导致的，因此可通过运行消耗的情况作为触发条件，与周期触发的方式相比，可减少不必要的检测流程，从而提高设备的资源利用率。
在s502中，将所述sql脚本的运行状态参数导入至预设的消耗等级转换模型，计算各个所述sql脚本对应的消耗等级；其中，所述消耗等级用于表示调用所述sql脚本时对设备资源的占用情况。
在本实施例中，终端设备在获取了各个sql脚本的运行状态参数后，将根据各个运行状态参数获取sql脚本的消耗情况，因此将sql脚本对应的运行状态参数中包含的多个参数值，导入到预设的消耗特征转换模型中，以通过运行状态参数计算其对应的消耗等级，通过该消耗等级表征该sql脚本的消耗情况。
可选地，该预设的消耗特征值转换模型具体为：
ex＝α1ct(sql)+α2t(sql)+α3buff(sql)+α4q(sql)
其中，ex为sql脚本的第一消耗特征值，α1、α2、α3和α4为各个运行状态参数对应的权重值，ct(sql)为sql脚本的运算资源占用参数，t(sql)为sql脚本的平均运行时间参数，buff(sql)为sql脚本的内存占用参数，q(sql)为sql脚本的运行次数。
在s503中，选取所述消耗等级大于预设的等级阈值的所述sql脚本作为故障sql脚本。
在本实施例中，终端设备在计算了各个sql脚本对应的消耗等级后，将各个消耗等级与预设的等级阈值进行比对，若某一sql脚本对应的消耗等级小于或等于预设的等级阈值，则表示该sql脚本的消耗情况处于正常状态，识别该sql脚本为正常sql脚本；反之，若某一sql脚本对应的消耗等级大于预设的等级阈值，则表示该sql脚本的消耗情况已超出正常范围，处于异常消耗的sql脚本，因此将是被该sql脚本为故障sql脚本。终端设备将从sql脚本资源库中，将本次检测判定的故障sql脚本提取出来，对其进行故障修复。
在本发明实施例中，终端设备根据各个sql的运行状态参数，转换为对应的消耗等级，并将消耗等级与预设的消耗阈值进行比较，从而确定该sql脚本是否为故障sql脚本，实现对故障sql脚本的故障自检测，从而减少了人工的介入，提高了故障修复效率。
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。
图6示出了本发明一实施例提供的一种sql脚本的故障修复终端的结构框图，该sql脚本的故障修复终端包括的各单元用于执行图1对应的实施例中的各步骤。具体请参阅图1与图1所对应的实施例中的相关描述。为了便于说明，仅示出了与本实施例相关的部分。
参见图6，所述sql脚本的故障修复终端包括：
脚本标识获取单元61，用于若监测到故障sql脚本，则获取所述故障sql脚本的脚本标识；
运行控制文件获取单元62，用于根据所述脚本标识，获取所述故障sql脚本对应的运行控制文件；其中，所述运行控制文件具体用于：确定脚本调用终端每发起一次脚本调用操作时，执行所述故障sql脚本的循环次数，以及确定每次循环执行所述故障sql脚本时，该故障sql脚本内各个查询因子所取的取值；
消耗特征值获取单元63，用于基于预存的调用资源占用记录，确定执行各个运行控制文件时对应的消耗特征值；其中，所述消耗特征值用于表示调用所述运行控制文件时对设备资源的占用情况；
异常消耗比例确定单元64，用于获取所述消耗特征值大于预设的消耗阈值的消耗特征值个数，得到所述故障sql脚本对应的异常消耗比例；
查询因子序列修复单元65，用于若所述异常消耗比例大于预设的比例阈值，则判定所述故障sql脚本中的查询因子序列出现异常，调整所述查询因子序列；所述查询因子序列具体用于：当脚本调用终端调用sql脚本执行数据查询操作时，根据各个查询因子在所述查询因子序列中的顺序，确定各个所述查询因子的查询次序；
故障控制文件修复单元66，用于若所述异常消耗比例小于或等于预设的比例阈值，则识别所述消耗特征值大于预设的消耗阈值的运行控制文件为故障控制文件，并修复所述故障控制文件。
可选地，所述查询因子序列修复单元65，还包括：
查询因子统计单元，用于根据所述故障sql脚本中查询因子序列包含的各个查询因子，获取数据库内每个数据中所述查询因子所取的参数值；
区分度计算单元，用于统计各个所述查询因子的参数值个数，并根据所述参数值个数，计算各个所述查询因子对应的区分度；其中，所述区分度用于表示所述查询因子对所述数据库中数据的筛选效率；
标准查询因子序列确定单元，用于基于各个查询因子对应的区分度的数值，由大至小依次排列，生成标准查询因子序列；
查询因子序列调整单元，用于将所述标准查询因子序列替换所述故障sql脚本中的查询因子序列。
可选地，故障控制文件修复单元66，包括：
参数变更记录获取单元，用于获取所述故障控制文件对应的控制参数变更记录；
变更内容还原单元，用于根据所述控制参数变更记录创建时间的逆序，逐次还原所述控制参数变更记录包含的变更内容，并监测所述故障控制文件对应的消耗特征值，直到所述故障运行策略对应的消耗特征值小于或等于预设的消耗阈值。
可选地，所述故障控制文件修复单元66包括：
优选运行文件选取单元，用于选取所述消耗特征值最小的运行控制文件作为优选运行文件；
优选运行文件推广单元，用于将所述优选运行文件中包含的循环次数以及各个查询因子的参数值，应用至所述故障控制文件。
可选地，所述脚本标识获取单元61包括：
运行状态参数获取单元，用于获取各个sql脚本的运行状态参数；
消耗等级计算单元，用于将所述sql脚本的运行状态参数导入至预设的消耗等级转换模型，计算各个所述sql脚本对应的消耗等级；其中，所述消耗等级用于表示调用所述sql脚本时对设备资源的占用情况；
故障sql脚本监测单元，用于选取所述消耗等级大于预设的等级阈值的所述sql脚本作为故障sql脚本。
因此，本发明实施例提供的sql脚本的故障修复终端同样可以通过终端设备检测各个sql脚本的运行情况，若监测到存在故障的sql脚本，则启动故障修复流程，获取该故障sql脚本对应的脚本标识，继而通过该脚本标识，查询该故障sql脚本所对应的运行控制文件，确定数据库在调用该故障sql脚本时所对应的调用策略，继而根据各个运行控制文件对应的消耗特征值，定位该次故障是由于sql脚本本身导致的，抑或是某些运行控制文件中相关参数设置不合理而导致的。因此，终端设备在计算了各个运行控制文件对应的消耗特征值后，将该消耗特征值与预设的消耗阈值进行比较，确定大于预设消耗阈值的消耗特征值个数，继而确定其异常消耗比例，若该异常消耗比例大于预设的比例阈值，则表示大部分的运行控制文件均处于异常消耗的情况，因此将表示并非运行控制文件中参数设置不合理，而是该故障sql脚本本身存在问题，从而导致了调用该sql脚本的各个运行控制文件发生异常消耗；反之，若异常消耗比例小于或等于预设的比例阈值，则表示只有部分运行控制文件存在异常消耗情况，因此可以判定并非sql脚本本身存在异常，而是部分运行控制文件中的循环参数设置不合理导致的，因此对异常消耗的运行控制文件进行修复调节。因此，终端设备通过识别故障sql脚本的消耗异常成因，执行对应的修复操作，从而提高了修复的准确性，解决了现有的sql脚本的故障修复技术，需要人工对数据库中包含的sql脚本一一进行手动排查，故障检测效率较低，并且检测到故障的sql脚本后，也依赖维护人员的专业知识进行人工故障修复，也进一步降低了sql脚本故障响应的效率的问题。
图7是本发明另一实施例提供的一种终端设备的示意图。如图7所示，该实施例的终端设备7包括：处理器70、存储器71以及存储在所述存储器71中并可在所述处理器70上运行的计算机程序72，例如sql脚本的故障修复程序。所述处理器70执行所述计算机程序72时实现上述各个sql脚本的故障修复方法实施例中的步骤，例如图1所示的s101至s106。或者，所述处理器70执行所述计算机程序72时实现上述各装置实施例中各单元的功能，例如图6所示模块61至66功能。
示例性的，所述计算机程序72可以被分割成一个或多个单元，所述一个或者多个单元被存储在所述存储器71中，并由所述处理器70执行，以完成本发明。所述一个或多个单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序72在所述终端设备7中的执行过程。例如，所述计算机程序72可以被分割成脚本标识获取单元、运行控制文件获取单元、消耗特征值获取单元、异常消耗比例确定单元、查询因子序列修复单元以及故障控制文件修复单元，各单元具体功能如下：
脚本标识获取单元，用于若监测到故障sql脚本，则获取所述故障sql脚本的脚本标识；
运行控制文件获取单元，用于根据所述脚本标识，获取所述故障sql脚本对应的运行控制文件；其中，所述运行控制文件具体用于：确定脚本调用终端每发起一次脚本调用操作时，执行所述故障sql脚本的循环次数，以及确定每次循环执行所述故障sql脚本时，该故障sql脚本内各个查询因子所取的取值；
消耗特征值获取单元，用于基于预存的调用资源占用记录，确定执行各个运行控制文件时对应的消耗特征值；其中，所述消耗特征值用于表示调用所述运行控制文件时对设备资源的占用情况；
异常消耗比例确定单元，用于获取所述消耗特征值大于预设的消耗阈值的消耗特征值个数，得到所述故障sql脚本对应的异常消耗比例；
查询因子序列修复单元，用于若所述异常消耗比例大于预设的比例阈值，则判定所述故障sql脚本中的查询因子序列出现异常，调整所述查询因子序列；所述查询因子序列具体用于：当脚本调用终端调用sql脚本执行数据查询操作时，根据各个查询因子在所述查询因子序列中的顺序，确定各个所述查询因子的查询次序；
故障控制文件修复单元，用于若所述异常消耗比例小于或等于预设的比例阈值，则识别所述消耗特征值大于预设的消耗阈值的运行控制文件为故障控制文件，并修复所述故障控制文件。
所述终端设备7可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述终端设备可包括，但不仅限于，处理器70、存储器71。本领域技术人员可以理解，图7仅仅是终端设备7的示例，并不构成对终端设备7的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述终端设备还可以包括输入输出设备、网络接入设备、总线等。
所称处理器70可以是中央处理单元(centralprocessingunit，cpu)，还可以是其他通用处理器、数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现成可编程门阵列(field-programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
所述存储器71可以是所述终端设备7的内部存储单元，例如终端设备7的硬盘或内存。所述存储器71也可以是所述终端设备7的外部存储设备，例如所述终端设备7上配备的插接式硬盘，智能存储卡(smartmediacard,smc)，安全数字(securedigital,sd)卡，闪存卡(flashcard)等。进一步地，所述存储器71还可以既包括所述终端设备7的内部存储单元也包括外部存储设备。所述存储器71用于存储所述计算机程序以及所述终端设备所需的其他程序和数据。所述存储器71还可以用于暂时地存储已经输出或者将要输出的数据。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
以上所述实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。