一种基于因果关系的数据库故障诊断方法

1.本发明涉及故障诊断和因果关系构建技术领域，尤其涉及一种基于因果关系的数据库故障诊断方法。


背景技术：

2.同属于一个数据库的监控指标之间相互关联、存在因果关系，表现为当数据库中出现故障时，多个监控指标会同时发生变化，干扰技术人员的判断。随着数据库越来越复杂，单名技术人员难以理解系统中的每个细节，也就愈发依赖监控。然而，监控指标的数量也在增长，理解监控指标之间的关系对于技术人员维护系统、进而基于监控数据搭建智能化应用愈发重要而困难。
3.同时，因果发现致力于从观测数据中寻找变量之间的因果关系。基于观测数据的因果发现是一个新兴的研究方向，尽管已经有了一定的理论发展，在实际问题中，已有方法的构建结果相比真实的因果关系仍有不小的差距。例如，基于限制的方法依赖于统计性条件独立检验工具。然而已有工作表明，不存在一个普遍有效的条件独立检验工具。另一方面，基于梯度的方法存在过度拟合观测数据、忽视因果关系正确性的风险。
4.再有sage、microhecl这两个基于因果假设的构建方法针对数据库特点进行设计，但考虑的监控指标种类较少，不具备通用性。已有方法对于机器cpu利用率这样更细粒度的监控、服务负载与服务延迟之间这样更多元的关系缺少系统性的刻画。
5.进一步地，监控是大数据中的重要组成部分，用于揭示系统运行状态，方便技术人员在系统做出不符合预期的行为时推断进而解决问题。一个监控指标指监控中的一个维度。例如，平均响应时间、访问量、访问成功率是搜索引擎、在线购物等在线服务系统中常见的监控指标。
6.现有技术中，人工定位：技术人员逐一查看各监控数据。深度优先搜索：基于深度优先搜索的方案：首先应用异常检测技术，筛选出异常的监控指标。继而在监控指标之间构成的因果关系图中沿异常的监控指标进行深度优先遍历，将遍历停止处的监控指标标记为根因。随机游走：一些现有技术计算监控指标与业务层面关键监控指标的皮尔森相关系数、偏相关系数等，继而依托监控指标之间的因果关系图计算转移概率矩阵，最后应用随机游走为各监控指标打分并排序。
7.现有技术的缺点：人工定位方法费时费力，面对越来越多的监控数据、同时剧烈变化的监控指标，技术人员看不过来是数据库诊断的现实问题，严重滞后系统恢复正常。基于深度优先搜索的方法依赖于异常检测技术的表现，异常检测中的误报、漏报都会导致深度优先搜索方法错失指向系统故障根源的监控指标。目前，随机游走的工作机理不明确，转移概率矩阵的计算缺少依据。实际应用中，基于随机游走的诊断方法在不同数据库中的表现差异很大。
8.当出现故障时，多个监控指标会同时发生变化，干扰技术人员的判断。随着越来越复杂，单名技术人员难以理解系统中的每个细节，也就愈发依赖监控。然而，监控指标的数
量也在增长。因此当故障发生时，如何在大量监控指标中筛选最关键的一个或几个监控指标、并辅助技术人员使系统恢复正常，成为亟待解决的问题。


技术实现要素：

9.本发明旨在至少在一定程度上解决相关技术中的技术问题之一。
10.为此，本发明的目的在于提出一种基于因果关系的数据库故障诊断方法，可以通过构建监控指标的因果关系，实现精准故障定位，以在大量监控指标中筛选最关键的一个或几个监控指标、并辅助技术人员使系统恢复正常。
11.为达上述目的，本发明提出了一种基于因果关系的数据库故障诊断方法，包括：
12.采集数据库预设时间段的监控指标的监控数据，并构建所述监控指标之间的因果关系图；其中，所述监控数据包括故障数据和无故障数据；基于所述因果关系图，利用所述无故障数据对所述监控指标构建回归模型；通过所述回归模型计算所述故障数据的回归误差；基于所述回归误差，通过预设计算公式对每个所述监控指标进行计算，以对所述监控指标进行排序得到监控指标排列顺序；根据所述监控指标排列顺序，并基于所述监控指标确定所述数据库的故障位置。
13.本发明实施例的基于因果关系的数据库故障诊断方法，在故障发生时，从大量监控中筛选最关键的一个或几个监控指标、辅助技术人员使系统恢复正常，并且实现方法简单、操作方便以及效率高。
14.另外，根据本发明上述实施例的基于因果关系的数据库故障诊断方法还可以具有以下附加的技术特征：
15.进一步地，所述监控指标，包括：访问情况、连接数占用情况、内存占用情况、磁盘容量占用情况、索引使用情况、网络流量、节点状态、数据查询情况和/或节点日志信息。
16.进一步地，所述通过所述回归模型计算所述故障数据的回归误差，包括：对于发生故障时所述故障数据的故障前数据，统计所述故障前数据对所述监控指标的回归误差的均值mi和方差si；以及，所述故障数据的故障过程中数据，统计所述故障过程中数据对所述监控指标的回归误差为e
ij
。
17.进一步地，所述预设计算公式为：
18.zi＝maxj|e
ij-mi|/si19.其中，zi是衡量每个监控指标vi是否表征故障的统计量。
20.进一步地，将所述监控指标构建监控指标集合，则所述构建所述监控指标之间的因果关系图，包括：将所述监控指标划分为数据库架构对应组件的相应元变量，获得从元变量到所述监控指标集合的第一映射，以及从有序元变量对到所述监控指标集合的第二映射；基于所述数据库架构和多种元变量之间的因果关系信息构建元变量因果关系图；基于所述元变量因果关系图、所述第一映射以及所述第二映射构建所述监控指标之间的因果关系图；将所述监控指标之间的因果关系图，实例化为各组件实例监控指标之间的因果关系图。
21.进一步地，所述数据库架构表示为调用关系图gc＝《vc,ec》，所述多种元变量之间的因果关系信息，包括：组件内元变量之间的关系ag＝《va,ea》；以及，从元变量类型到元变量类型集合的映射ap、ac、ad和aa；其中，所述ap为来自调用方组件的原因元变量集，所述ac
为处于调用方组件的结果元变量集，所述ad为处于各级调用方组件的结果元变量集，所述aa为来自各级调用方组件的原因元变量集。
22.进一步地，基于gc、ag、ap、ac、ad、aa构建元变量因果关系图gm＝《vm,em》，包括：
23.对于vc中的每个组件ci、va中的每个元变量类型tx，在vm中添加元变量《ci,tx》；对于vc中的每个组件ci、对于ea中的每条边tx
→
ty，在em中添加边《ci,tx》
→
《ci,ty》；对于ec中的每条边ci
→
cj、va中的每个元变量类型tx、ap(tx)中的每个元变量类型ty，在em中添加边《ci,ty》
→
《cj,tx》；对于ec中的每条边ci
→
cj、va中的每个元变量类型tx、ac(tx)中的每个元变量类型ty，在em中添加边《cj,tx》
→
《ci,ty》；对于vc中的每个组件cj、gc中cj的每个祖先组件ci、va中的每个元变量类型tx、ad(tx)中的每个元变量类型ty，在em中添加边《cj,tx》
→
《ci,ty》；对于vc中的每个组件cj、gc中cj的每个祖先组件ci、va中的每个元变量类型tx、aa(tx)中的每个元变量类型ty，在em中添加边《ci,ty》
→
《cj,tx》。
24.进一步地，所述监控指标之间的因果关系图为g＝《v,e》，以拓扑序遍历元变量因果关系图gm并从原因变量最少的元变量开始，对于依次遍历到的每个元变量mvi，顺序执行如下步骤：令令对于m(mvi)中的每个监控指标vy，进行第一情况处理；对于gm中mvi的每个原因元变量mvj，进行第二情况处理；对于p(mvi)中的每个监控指标vx、r(mvi)中的每个监控指标vy，将vx
→
vy加入e；若则令r(mvi)＝p(mvi)。
25.进一步地，所述进行第一情况处理，包括：若rm(vy)只包含一个元变量mvi，则将vy分别加入r(mvi)和v；若rm(vy)包含多个元变量，但rm(vy)中除mvi外存在未在构建所述监控指标之间的因果关系图时访问过的元变量，则不进行操作；若rm(vy)包含多个元变量，且rm(vy)中除mvi外所有元变量均在构建所述监控指标之间的因果关系图时访问过，则
26.将vy分别加入p(mvi)和v；以及，对于rm(vy)中除mvi外的元变量mvj、r(mvj)中的每个监控指标vx，将vx
→
vy加入e；所述进行第二情况处理，包括：若vy加入e；所述进行第二情况处理，包括：若则对r(mvj)中的每个监控指标vx，将vx加入p(mvi)；若则对r(mvj)中的每个监控指标vx、iv(mvj,mvi)中的每个监控指标vy，将vy分别加入p(mvi)和v，并将vx
→
vy加入e。
27.进一步地，将所述监控指标之间的因果关系图g实例化为各组件实例监控指标之间的因果关系图gi，对于e中的每一条边《ci,x》
→
《cj,y》，其中x、y是监控指标名称，分如下两种情况进行处理：若ci＝cj，则对于组件ci的每个实例u，将《ci,u,x》
→
《ci,u,y》加入图gi；若ci≠cj，则对于组件ci的每个实例u、组件cj的每个实例v，将《ci,u,x》
→
《cj,v,y》加入图gi。
28.本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。
附图说明
29.本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
30.图1为根据本发明实施例的基于因果关系的数据库故障诊断方法流程图；
31.图2为根据本发明实施例的构建监控指标因果关系的整体流程示意图；
32.图3为根据本发明实施例的oracle数据库内部sql处理逻辑和内存架构的调用关系示例图。
具体实施方式
33.需要说明的是，在不冲突的情况下，本技术中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。
34.为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。
35.此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本发明的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。
36.在本发明中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”、“固定”等术语应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。
37.在本发明中，除非另有明确的规定和限定，第一特征在第二特征之“上”或之“下”可以包括第一和第二特征直接接触，也可以包括第一和第二特征不是直接接触而是通过它们之间的另外的特征接触。而且，第一特征在第二特征“之上”、“上方”和“上面”包括第一特征在第二特征正上方和斜上方，或仅仅表示第一特征水平高度高于第二特征。第一特征在第二特征“之下”、“下方”和“下面”包括第一特征在第二特征正上方和斜上方，或仅仅表示第一特征水平高度小于第二特征。
38.下面参照附图描述根据本发明实施例提出的基于因果关系的数据库故障诊断方法。
39.图1是本发明一个实施例的基于因果关系的数据库故障诊断方法的流程图。
40.如图1所示，该方法包括但不限于以下步骤：
41.步骤s1，采集数据库预设时间段的监控指标的监控数据，并构建监控指标之间的因果关系图；其中，监控数据包括故障数据和无故障数据。
42.具体地，数据库的运行状况，包括待优化问题和/或故障问题，都会体现在具体的状态指标特征信息中，为了实现数据库的自动优化处理，本发明实施例需要预先设置一些状态指标作为监控对象，通过监控这些状态指标，采集得到对应的数据库的监控指标。其中，监控是持续进行的，以便及时地发现数据库集群存在的问题。这些预设状态指标包括但不仅限于以下指标：访问情况、连接数占用情况、内存占用情况、磁盘容量占用情况、索引使用情况、网络流量、节点状态、数据查询情况和/或节点日志信息。
43.预设时间段可以根据需要优化的时间和/或需要关注的故障来选择，在本实施例
中，从监控的数据库的状态信息中，采集与预设时间段对应的监控数据，并存储在数据库中，便于针对该监控数据构建因果关系图。监控数据包括故障数据和无故障数据。
44.可以理解的是，本发明将数据库的故障映射为因果推断理论中的干预(intervention)，并依据奥卡姆剃刀原理假定引起监控指标变化的干预才是数据库中需要考虑的故障。对于监控指标之间的因果关系图g＝《v,e》，v为所有监控指标构成的集合，e为监控指标之间的边(因果关系)构成的集合，记任一监控指标vi在g中的父结点(原因变量)集合为pa(vi)。依因果推断理论，可以得到如下判定条件：
[0045]“一个监控指标vi是干预的一部分”，等价于“p(vi|pa(vi)＝pa(vi),do(vi＝vi))≠p(vi|pa(vi)＝pa(vi))”；
[0046]
其中，“do”为干预算子(do-calculus)，是因果推断中表示“干预”的数学符号；
[0047]
不等号左边的p(vi|pa(vi)＝pa(vi),do(vi＝vi))表示干预后的概率分布，即故障发生后，监控指标vi在原因变量取给定值时的取值分布；
[0048]
不等号右边的p(vi|pa(vi)＝pa(vi))表示未发生干预时的干预分布，即故障发生前，监控指标vi在原因变量取给定值时的取值分布。
[0049]
进一步地，为了更好地理解关系构建，本实施例将监控指标描述为监控变量，数据库架构可以表示为调用关系图gc＝《vc,ec》。以一个oracle数据库为例，每个sql请求在被数据库服务端(server)接收后需执行架构中的3个组件：解析(parse)、硬解析(hardparse)、执行(execute)。在这个例子中，vc＝{server,parse,hardparse,execute}为组件集合，ec＝{server
→
parse,server
→
hardparse,server
→
execute}为组件之间的调用关系。调用关系图可以有不同的粒度，例如oracle数据库的内存结构可以细分为buffer cache、redo log buffer等，而这些组件进一步占用内存资源(分别“调用”内存)。图3为oracle数据库内部sql处理逻辑和内存架构的调用关系示例，如图3所示。
[0050]
对于数据库中的每个组件的监控指标，本发明将其分为四类元变量：输入分布(i，input)，输出分布(o，output)，响应时间分布(l，latency)，资源利用率分布(s，saturation)。其中，不能归入前三类的监控指标，均可认为是在描述系统中的某种抽象的资源，进而归入第四类。一个元变量(mv，meta variable)是组件、元变量类型的二元组，例如，元变量《server,l》描述数据库整体的响应时间分布，数据库的“每秒sql时间”可以归入该元变量。
[0051]
针对数据库的特点，本发明在元变量之间引入如下五组因果假设。
[0052]
1)组件内元变量之间的关系ag(assumed graph)。ag＝《va,ea》，其中，va＝{i,o,l,s}表示所有元变量类型。ea＝{i
→
o,i
→
l,i
→
s,l
→
o,s
→
o,s
→
l}表示组件内部元变量之间的关系。数据库的输入(i)被当做其它元变量的原因，输出(o)则被当做其它元变量的结果，资源利用率(s)被当做对响应时间(l)的约束。
[0053]
2)来自调用方组件的原因元变量集ap(assumed parents)。ap是从元变量类型到元变量类型集合的映射。具体而言，ap(i)＝{i}，例如，在前述oracle数据库中，hardparse的输入由server的输入决定。而即一个组件的输出、响应时间、资源利用率不由调用方直接影响。
[0054]
3)处于调用方组件的结果元变量集ac(assumed children)。ac是从元变量类型到元变量类型集合的映射。具体而言，ac(o)＝{o}，ac(l)＝{l}，例如，在前述oracle数据库
中，server的输出、响应时间受parse、hardparse、execute等组件影响。而中，server的输出、响应时间受parse、hardparse、execute等组件影响。而即一个组件的输入、资源利用率不能直接影响到调用方。
[0055]
4)处于各级调用方组件的结果元变量集ad(assumed descendents)。ad是从元变量类型到元变量类型集合的映射。具体而言，ad(o)＝{o}，例如，在前述oracle数据库中，server的输出受hardparse输出、继而受data dictionary cache输出的影响。ad(o)与ac(o)含义的区别在于，对hardparse输出分布的监控可能遗漏data dictionary cache输出分布的部分信息，ad(o)结合数据库的特点显式添加了这一限制。而即不考虑其它元变量类型的级联效应。
[0056]
5)来自各级调用方组件的原因元变量集aa(assumed ancestors)。aa是从元变量类型到元变量类型集合的映射。本发明中，为了设计的完整性，本发明仍显式定义aa。
[0057]
上述因果假设丰富了现有技术讨论的监控指标类型及监控指标之间的关系。基于数据库架构信息及元变量之间的因果假设，本发明将数据库架构首先细化为元变量之间的因果关系，进而细化为监控变量之间的因果关系。表1汇总了本发明中用到的记号及其含义。
[0058]
表1
[0059]
[0060][0061]
作为一种示例，如图2所示：
[0062]
首先是对监控变量划分：技术人员将监控变量划分为数据库对应组件的相应元变量，获得如下两种信息：
[0063]
步骤1-1：从元变量到监控变量集合的映射m，第一映射。例如，m(《server,l》)＝{《server,每秒sql时间》}表示server的“每秒sql时间”这一监控变量属于《server,l》这一元变量。同一个监控变量可以对应于多个组件的元变量，例如，“每执行逻辑读”作为单独的监控变量由server和buffercache两个组件的输入分布计算而来。
[0064]
步骤1-2：从有序元变量对到监控变量集合的映射iv(intermediating variables，中介变量)，即第二映射。例如，iv(《buffercache,t》,《storage,t》)＝{《oracle,db file parallel read》}，表示orale数据库的“db file parallel read”这一监控变量是元变量《buffercache,t》对元变量《storage,t》影响的一个中介变量，即《buffercache,t》对《storage,t》的影响都通过“db file parallel read”体现，而《buffercache,t》不是《storage,t》的直接原因。
[0065]
进一步地，元变量因果关系构建：
[0066]
基于gc、ag、ap、ac、ad、aa构建元变量之间的因果关系图gm＝《vm,em》。该步骤细分为如下步骤：
[0067]
步骤2-1：对于vc中的每个组件ci、va中的每个元变量类型tx，在vm中添加元变量《ci,tx》。
[0068]
步骤2-2：对于vc中的每个组件ci、对于ea中的每条边tx
→
ty，在em中添加边《ci,tx》
→
《ci,ty》。
[0069]
步骤2-3：对于ec中的每条边ci
→
cj、va中的每个元变量类型tx、ap(tx)中的每个元变量类型ty，在em中添加边《ci,ty》
→
《cj,tx》。
[0070]
步骤2-4：对于ec中的每条边ci
→
cj、va中的每个元变量类型tx、ac(tx)中的每个元变量类型ty，在em中添加边《cj,tx》
→
《ci,ty》。
[0071]
步骤2-5：对于vc中的每个组件cj、gc中cj的每个祖先组件ci、va中的每个元变量类型tx、ad(tx)中的每个元变量类型ty，在em中添加边《cj,tx》
→
《ci,ty》。
[0072]“gc中cj的每个祖先组件ci”指，存在一些组件cx、cy、
……
、cz，使得ci
→
cx、
[0073]
cx
→
cy、
……
、cz
→
cj都是ec的元素，或者ci
→
cj是ec的元素。
[0074]
步骤2-6：对于vc中的每个组件cj、gc中cj的每个祖先组件ci、va中的每个元变量类型tx、aa(tx)中的每个元变量类型ty，在em中添加边《ci,ty》
→
《cj,tx》。
[0075]
进一步地，监控变量填充：
[0076]
基于gm、m、及iv构建监控变量因果关系图g＝《v,e》。该步骤的设计需要特别考虑如下两个因素：
[0077]
一个元变量可能没有对应的监控变量。为此，令r为一个从元变量到监控变量集合的映射。对于任意元变量mvi，r(mvi)表示对mvi的结果元变量而言mvi包含的监控变量；当mvi没有对应的监控变量时，r(mvi)继承来自gm中mvi的原因元变量的监控变量。
[0078]
一个监控变量可能对应多个元变量。为此，令rm为一个从监控变量到元变量集合的映射。rm与m含义相反，对于任意监控变量vi，rm(vi)表示vi对应的所有元变量。
[0079]
以拓扑序遍历gm且从原因变量最少的元变量开始。对于依次遍历到的每个元变量mvi，顺序执行如下步骤：
[0080]
步骤3-1：令令
[0081]
步骤3-2：对于m(mvi)中的每个监控变量vy，分如下三种情况进行处理：
[0082]
步骤3-2-1：若rm(vy)只包含一个元变量mvi，则将vy分别加入r(mvi)和v。
[0083]
步骤3-2-2：若rm(vy)包含多个元变量，但rm(vy)中除mvi外存在未在以拓扑序遍历gm且从原因变量最少的元变量开始中访问过的元变量，则不进行操作。这一步骤是为了避免在一个监控变量对应多个元变量的情况下引入自环。
[0084]
步骤3-2-3：若rm(vy)包含多个元变量，且rm(vy)中除mvi外所有元变量均在上述步骤中访问过，则：
[0085]
将vy分别加入p(mvi)和v；
[0086]
对于rm(vy)中除mvi外的元变量mvj、r(mvj)中的每个监控变量vx，将vx
→
vy加入e。
[0087]
步骤3-3：对于gm中mvi的每个原因元变量mvj，分如下两种情况进行处理：
[0088]
步骤3-3-1：若则对r(mvj)中的每个监控变量vx，将vx加入p(mvi)。
[0089]
步骤3-3-2：若则对r(mvj)中的每个监控变量vx、iv(mvj,mvi)中的每个监控变量vy，将vy分别加入p(mvi)和v，并将vx
→
vy加入e。
[0090]
步骤3-4：对于p(mvi)中的每个监控变量vx、r(mvi)中的每个监控变量vy，将vx
→
vy加入e。
[0091]
步骤3-5：若则令r(mvi)＝p(mvi)。
[0092]
进一步地，组件实例化：
[0093]
数据库中，同一种组件可能有多个实例。例如，数据库可采用主备模式，数据库db对应于两个实例数据库db1和数据库db2；在前述oracle数据库中，可以采用多个存储设备。将得到的g实例化为各组件实例监控变量之间的因果关系图gi。对于e中的每一条边《ci,x》
→
《cj,y》，其中x、y是监控变量名称，分如下两种情况进行处理：
[0094]
步骤4-1：若ci＝cj，则对于组件ci的每个实例u，将《ci,u,x》
→
《ci,u,y》加入图gi。
[0095]
步骤4-2：若ci≠cj，则对于组件ci的每个实例u、组件cj的每个实例v，将《ci,u,x》
→
《cj,v,y》加入图gi。
[0096]
作为一种实现方式，本发明中的因果假设及步骤监控变量划分、元变量因果关系构建是针对数据库提出的。其它技术领域独有的因果假设和元变量因果关系构建方法不包含在本发明中。但是，如果其它技术领域同样采用先构建元变量因果关系、继而通过监控变量填充的方法构建监控变量因果关系图的技术路线，本发明的步骤监控变量填充、组件实例化同样适用。本发明提出的五组因果假设ag、ap、ac、ad、aa的具体取值作为关键参数不应视为对本发明的限制。在本发明的设计框架内，更换因果假设依然可以通过本发明包含的步骤构建监控变量因果关系。
[0097]
步骤s2，基于因果关系图，利用无故障数据对监控指标构建回归模型。
[0098]
具体地，对于各监控变量vi，使用无故障数据构建vi对pa(vi)的回归模型。
[0099]
本发明实施例不对回归模型的设计做具体限定。本领域技术人员可以根据系统的特点选择已有的回归技术，例如线性回归、使用非线性核函数的支持向量回归(svr)、适用于有明显自回归特性时间序列的递归神经网络(rnn)等。
[0100]
进一步地，既可以在故障发生前使用历史数据构建回归模型，也可以在故障发生时借助故障发生前一段时间的数据进行在线构建。前者数据量大、时间充裕，可以选用复杂的回归模型；后者所借助的数据贴近系统最新状态，但迫于故障诊断的时效性，需要选用轻量级的回归模型。
[0101]
步骤s3，通过回归模型计算故障数据的回归误差。
[0102]
具体地，在一次故障发生后，分别对故障过程中一段时间(例如从发现故障开始前推10分钟)、故障前一段时间(例如检测到的故障发生时刻之前的2小时，与前一段时间无重合)的数据应用构建的回归模型。对于每个监控变量vi计算vi在这两段时间的各数据点的回归误差：
[0103]
对于故障前数据，统计对vi的回归误差的均值mi和方差si。
[0104]
对于故障过程中数据，对vi的回归误差记为e
ij
。
[0105]
步骤s4，基于回归误差，通过预设计算公式对每个监控指标进行计算，以对监控指标进行排序得到监控指标排列顺序。
[0106]
具体地，在一次故障发生后，对于每个监控变量vi计算zi＝maxj|e
ij-mi|/si。其中，zi是衡量每个监控指标vi是否表征故障的统计量，该式用于统一不同监控变量回归误差的标准差，方便比较。则通过监控指标进行排序得到监控指标排列顺序。
[0107]
步骤s5，根据监控指标排列顺序，并基于监控指标确定数据库的故障位置。
[0108]
具体地，在一次故障发生后，根据上述计算得到的zi对监控变量排序，技术人员按照本发明推荐的顺序检查监控变量时可以尽早确定数据库故障所在。
[0109]
本发明实施例的有益效果可以使用只考虑排在前k位的监控变量时的召回率来衡量，记为ac@k。基于收集自oracle数据库的监控数据与故障案例，表2将本发明与已有技术进行对比。相比于这3种方案，本发明显著提升了故障诊断的性能。比较的3种方案分别是：
[0110]
深度优先搜索，且在遍历时为监控变量和业务指标的皮尔森相关系数设定阈值。
[0111]
随机游走，基于监控变量和业务指标的偏相关系数计算转移概率矩阵。
[0112]
enmf，在监控变量两两之间构建arx模型，并建模故障传播过程。
[0113]
表2不同故障诊断技术的效果
[0114]
故障诊断技术ac@1ac@3ac@5深度优先搜索0.2780.4190.449随机游走0.1010.3380.475enmf0.1260.2930.389本发明0.3280.6010.677
[0115]
在本发明的实施例中，可以通过构建监控指标的因果关系，实现精准故障定位，以在大量监控指标中筛选最关键的一个或几个监控指标、并辅助技术人员使系统恢复正常。
[0116]
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
[0117]
尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在不脱离本发明的原理和宗旨的情况下在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。