CN102081623B - 一种数据库异常检测方法和系统 - Google Patents

Abstract

本发明实施方式公开了一种数据库异常检测方法。包括：利用活动会话历史(ASH)接口从数据库获取运行状态信息；将预定时间段内的运行状态信息与该数据库的历史运行状态信息进行比较，以确定数据库的运行状态趋势，并根据数据库的运行状态趋势评估数据库是否存在异常。本发明实施方式还公开了一种数据库异常检测系统。应用本发明实施方式后，提高了数据库故障感知的即时性，而且实现了对单进程的性能评估，能够准确定位数据库故障所在。

Description

一种数据库异常检测方法和系统

技术领域

本发明涉及数据库技术领域，更具体地，本发明涉及一种数据库异常检测方法和系统。

背景技术

数据库是依照某种数据模型组织起来并存放在二级存储器中的数据集合。这种数据集合具有如下特点：尽可能不重复；以最优方式为某个特定组织的多种应用服务；其数据结构独立于使用它的应用程序；对数据的增、删、改和检索由统一软件进行管理和控制。从发展的历史看，数据库是数据管理的高级阶段，它是由文件管理系统发展起来的。

长久以来，数据库管理员(DBA)一直面临着两个问题，发生故障时的信息滞后性以及故障原因定位难的问题。也就是说，数据库发生故障时，DBA通常不能够第一时间获知，往往是由于数据库故障引起应用拥堵后，由应用维护人员告知DBA。此时DBA已经非常被动，而且在发生故障后，数据库一般处于停止响应或者响应极度缓慢的状态，给DBA介入处理带来了极大的困扰和不便。紧急情况下，DBA可能不得不选择临时重启数据库以尽快恢复应用。数据库重启后，由于现场环境的缺失，问题无法准确定位，给后续从根本上解决问题带来了极大的困扰。

针对以上两个问题，在目前数据库维护中，一般采取以下三种方案来或多或少地避免此类问题：

1.针对关键系统，安排专人实时监控，通过各种性能检测工具(如OEM，PRECISE等)，以图表显示的方式，实时观察数据库性能变化情况，人为判断是否存在异常。如有异常，及时介入处理。

2.针对数据库中的各类性能指标，如CPU使用率、IO等待状况，系统主要等待事件等等，制定相应的告警策略，比如CPU使用率超过60％为CPU主要告警，超过80％为CPU严重告警等。

3.通过关键性的性能指标，对数据库进行间隔性的采样监控，评估出当前数据库综合性能指标。由于从内存进行采样时会对数据库造成一定的影响，因此采样时间间隔通常为10-15分钟左右，然后通过分析采样点的瞬时数据，进行监控设置，建立一定的报警机制。

第一种技术是最直观的监控方式，对于交易量或主机负荷之类的少数重要数据，能够有效的表现出数据库运行状态的趋势，对于判断当前数据库性能等等方面，有着积极的参考意义。但是，这种技术并不能够实现自动监控，仍然停留在人力监控的阶段上。首先，所显示的屏幕内能提供的信息量比较少，对于详细诊断问题所在起不了多少帮助，其次，这种技术需要安排专人进行实施监测，浪费大量的人力。另外，随着集群系统的引入，监控需求量呈几何级增长，依靠此类传统作业方式无法满足现代化的需求。

第二种技术在第一种技术的基础上，引入了性能指标的概念，对数据库中的各类性能指标进行针对性的监控，形成了初步的自动监控机制。但是，该技术准确率偏低，单个性能指标的恶化往往不能说明问题。并且针对单独性能指标制定监控，工作量相对比较繁琐，不能适应集群环境中复杂的多系统环境。

第三种技术在第二种技术的基础上，引入了关键性能指标及综合性能指标的概念，并且，对数据库中成百上千的性能指标进行了筛选分析，通过量化关键性能指标，形成一个综合的性能指标来反映当前采样点时数据库的综合性能，完善了自动监控告警的功能。但是，由于其存在机理，以及其采样间隔周期较长，此技术只能在一定程度上减少数据库维护人员的故障感知延后性，并不能及时感知问题预兆。并且，在发生问题后，不能给维护人员提供太多有用的信息以进行问题定位处理。

以上三种技术，从根本上来说，均是通过各种手段，在减少故障感知滞后性方面做出一定的努力，但由于各方面的限制以及技术原理的欠缺，均没有能够从根本上解决问题故障感知滞后性的问题，同时，对于故障定位难的问题，更是没有取得实质性的突破。

另外，以上三种技术的机理，均是基于采样瞬间数据库性能状况进行的，也就是说，均是基于时间点的数据库性能监控及告警。然而，基于时间点的性能监控难免产生以偏概全的情况，在系统性能渐变时，不能立即发现并定位问题所在。

发明内容

本发明实施方式提出一种数据库异常检测方法，以提高数据库故障感知的即时性。

本发明实施方式还提出一种数据库异常检测系统，以提高数据库故障感知的即时性。

本发明实施方式的技术方案如下：

一种数据库异常检测方法，该方法包括：

利用活动会话历史(ASH)接口从数据库获取运行状态信息；

将预定时间段内的所述运行状态信息与该数据库的历史运行状态信息进行比较，以确定所述数据库的运行状态趋势，并根据所述数据库的运行状态趋势评估所述数据库是否存在异常。

一种数据库异常检测系统该，系统包括运行状态信息获取单元、运行状态趋势确定单元和异常确定单元，其中：

所述运行状态信息获取单元，用于利用活动会话历史ASH接口从数据库获取运行状态信息；

所述运行状态趋势确定单元，用于将预定时间段内的所述运行状态信息与该数据库的历史运行状态信息进行比较，以确定所述数据库的运行状态趋势；

所述异常确定单元，用于根据所述数据库的运行状态趋势评估所述数据库是否存在异常。

从上述技术方案可以看出，在本发明实施方式中，利用活动会话历史(ASH)接口从数据库获取运行状态信息，然后将预定时间段内的运行状态信息与该数据库的历史运行状态信息进行比较，以确定数据库的运行状态趋势，并根据数据库的运行状态趋势评估数据库是否存在异常。由此可见，应用本发明实施方式后，通过引入高实时性的时间段性能分析技术预测数据库运行状态趋势，避免了长时间间隔的样本数据的弊端，更加真实贴近数据库实际运行状况，从而提高了数据库故障感知的即时性。

而且，本发明实施方式由于采用了ASH技术，以秒为单位对数据库活动进程进行采样，极大降低了数据库维护中故障感知滞后性的问题，并且创造性地引入了趋势分析监控手段，在一定程度上能够于系统异常初期发现问题，并及时介入处理，降低故障规模及故障时间。

另外，本发明实施方式在单纯监控数据库级性能的基础上，进一步的细化到进程级，并在发现异常的同时，即能够对异常进行初步定位，有效降低了维护处理中的时间成本。不仅与此，本发明实施方式以ASH为基础，从oracle内部结构中直接进行数据采集，避免了其他方式带来的各种误差，实现了精确的性能数据采集。

附图说明

图1为根据本发明实施方式的数据库异常检测方法流程示意图。

图2为根据本发明实施方式的数据库异常检测系统的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点表达得更加清楚明白，下面结合附图及具体实施方式对本发明再作进一步详细的说明。

图1为根据本发明实施方式的数据库异常检测方法流程示意图。

如图1所示，该方法包括：

步骤101：利用活动会话历史(ASH)接口从数据库获取运行状态信息。

在Oracle 10g之前，用户的连接将产生会话(session)，当前会话记录保存在v$session中，处于等待状态的会话会被复制一份放在v$session_wait中。当该连接断开后，其原来的连接信息在v$session和v$session_wait中就会被删除。在数据库管理中，一个普通的会话(没有显著地消耗系统资源)对于数据库性能来说无足轻重。但如果该会话在活动时大量消耗了系统资源(比如：CPU，内存，I/O等)，则此类会话信息的丢失，会造成后续无法评估其活动时系统具体的资源消耗及争用状况，也就无法准确定位具体问题。因此，在Oracle中引入了ASH(active session history)技术。

ASH技术的原理在于，在数据库中的共享池(shared_pool)中分配一定的空间，每秒对数据库中所有活动的会话进行快照采样，不活动的会话对性能影响几乎为0，在采样时被忽略。由于ASH直接访问Oracle 10g的内部结构，因此采样效率非常高，对系统性能基本无影响，采样后的数据存放在已分配的内存空间中，循环使用空间，达到生命周期后，过期采样数据将被从内存中清除。

在一个实施方式中，利用活动会话历史接口从数据库的v$session视图和/或v$session_wait视图获取瞬时的运行状态信息；和/或

利用活动会话历史接口从数据库的v$active_session_history视图和/或v$sqlstats视图获取预定区段时间内的运行状态信息。

在一个实施方式中，所采集的运行状态信息可以包括：数据库中央处理器(CPU)整体运行状况信息；各活动进程的CPU运行状况信息；数据库I/O整体运行状况信息；各活动进程的I/O运行状况信息；数据库内存等待整体状况信息；各活动进程的内存等待状况信息；数据库锁等待整体状况信息；各活动进程的锁等待状况信息。

以上虽然罗列出运行状态信息的一些具体实施方式，本领域技术人员可以意识到，这种罗列仅是示范性的，并不用于限定本发明实施方式的保护范围。

在从数据库的v$session视图、v$session_wait视图、v$active_session_history视图或v$sqlstats视图采集了运行状态信息后，可以针对预先确定的核心性能指标再进行二次采集，比如CPU、IO、锁资源、共享内存等进行过滤，并形成相应的子性能指标。

理论上，利用ASH技术，进行适当的二次数据采集，可以实现秒级的数据库性能分析。而从实际意义角度出发，可以利用15秒为一个时间维度段，记录并分析最近15秒内数据库的性能状况，并与前两个15秒时间段内的数据库性能状况进行对比分析，评估出当前数据库系统级和进程级的绝对性能指标及相对性能指标。从而能够有效的持续评估数据库的实时运行状况，达到系统异常变化预兆告警及异常进程准确定位的功能。

步骤102：将预定时间段内的运行状态信息与该数据库的历史运行状态信息进行比较，以确定数据库的运行状态趋势，并根据数据库的运行状态趋势评估数据库是否存在异常。

在这里，可以将包括当前时间段的预定时间段内的运行状态信息与该数据库的历史运行状态信息进行同比；和/或

将包括当前时间段的预定时间段内的运行状态信息与该数据库的历史运行状态信息进行环比。

无论是同比还是环比，在实际操作中，都可以有多种的具体应用形式。本发明实施方式对同比或环比的具体应用形式并无限定。

而且，可以将预定时间段内的运行状态信息与该数据库的历史运行状态信息进行比较，以确定数据库的突变状态趋势和/或渐变状态趋势。

在一个实施方式中，数据库的运行状态趋势可以包括：根据核心子指标进行评估的运行状态趋势；根据综合性能指标行进行评估的状态趋势；以及综合考虑核心子指标和综合性能指标进行评估的的运行状态趋势。比如：通过当前时间区段的性能指标与前10个时间区段内性能指标的同比，以及与历史上相同时间区段的性能指标的环比，来进行运行状态趋势评估。

运行状态趋势评估可以包括数据库的绝对性能评估预测和数据库相对性能评估预测。数据库的绝对性能评估预测包括：根据CPU资源使用的绝对量(包括总使用量以及集中使用量)进行评估、根据IO资源绝对使用量(包括顺序读、离散读和IO等待等)进行评估，等等。数据库的相对性能评估预测包括：根据CPU资源相对量(当前总使用量与前两个时间段对比)进行评估、根据IO资源相对量(当前总使用量与前两个时间段对比)进行评估、根据系统综合性能相对量(当前总使用量与前两个时间段对比)进行评估，等等。

下面以CPU性能子指标为例说明核心子指标：

假设有10个连续的时间区段，当前时间区段为第10个时间区段，则分别定义如下：

C1：定义为当前时间区段内即第十个时间区段内，数据库CPU平均使用率；

C2：定义为第一时间区段到第五时间区段之间，数据库CPU平均使用率；

C3：定义为第五时间区段到第七时间区段之间，数据库CPU平均使用率；

C4：定义为第七时间区段到第九时间区段之间，数据库CPU平均使用率；

C5：定义为第一时间区段到第十时间区段之间，数据库CPU平均使用率；

C6：定义为前10天，相同的10个时间区段内，数据库CPU平均使用率；

可以如下定义：

P1＝(C1-C5)/C5；

P2＝(C1-C2)/C2；

P3＝(C1-C3)/C3；

P4＝(C1-C4)/C4；

P5＝(C5-C6)/C6；

其中：

P1指标用来检测当前时间区段内，与前10个时间区段相比，是否存在突变状况；

P2，P3，P4指标，用来检测这10个连续的时间区段内，是否存在渐变状况；

P5指标用来检测相同时间区段内，是否存在压力异常现象。

通过此5项指标，结合C1这个绝对量指标，可以组合设计出CPU性能子指标的趋势预兆检测。

下面再举例说明综合性能指标趋势预兆检测。

综合性能指标可以通过CPU等待与正常IO等待占总体等待的比重来衡量：

C1：定义为当前时间区段内的CPU使用总量；

I1：定义为当前时间区段内正常IO的使用总量；

Q1：定义为当前时间区段内，所有活动进程的资源使用/等待总量；

P1＝(C1+I1)/Q1：定义为当前时间区段内，数据库综合性能指标；

同理可得：

P2：定义为第一时间区段到第五时间区段之间，数据库综合性能指标；

P3：定义为第五时间区段到第七时间区段之间，数据库综合性能指标；

P4：定义为第七时间区段到第九时间区段之间，数据库综合性能指标；

P5：定义为第一时间区段到第十时间区段之间，数据库综合性能指标；

P6：前10天，相同的10个时间区段内，数据库综合性能指标；

定义有：

Q1＝(P1-P5)/P5；

Q2＝(P1-P2)/P2；

Q3＝(P1-P3)/P3；

Q4＝(P1-P4)/P4；

Q5＝(P5-P6)/P6；

其中：

Q1指标用来检测当前时间区段内与前10个时间区段相比，是否存在突变状况；

Q2，Q3，Q4指标，用来检测这10个连续的时间区段内是否存在渐变状况；

Q5指标用来检测相同时间区段内是否存在压力异常现象。

通过此5项指标，结合P1这个当前时间区段的绝对性能指标，可以组合设计出数据库综合性能指标的趋势预兆检测，及时发现数据库性能恶化趋势。

在一个实施方式中，可以利用综合性能指标及异常性能指标结合的方式进行设计，在完成一个时间区段的数据采集后，即触发异常检测进程，检测机制如下：

定义有：

C1：定义为当前时间区段内的CPU使用总量；

I1：定义为当前时间区段内正常IO的使用总量；

Q1：定义为当前时间区段内，所有活动进程的资源使用/等待总量；

P1＝(C1+I1)/Q1：定义为当前时间区段内，数据库综合性能指标；

E1：当前时间区段内，除C1与I1外，最多的异常等待总量(如db filescattered read等)。

可以设定一些具体的异常判定条件，当检测发现数据库的运行状况达到该异常判定条件时，即产生了异常。比如，当确定CPU资源绝对使用量及快速递增趋势时确定异常，并告警；当确定IO资源绝对使用量及快速递增趋势时确定异常，并告警；当确定系统综合性能资源一查以及快速递增趋势时确定异常，并告警；或其它非核心但非空闲等待异常以快速递增趋势时确定异常，并告警。

在一个实施方式中，异常判定条件可以为：

当E1＞40 or(E1＞30 and P1＜0.25)时，检测为严重异常；

当(E1＞30 and P1 between 0.25 and 0.5)or(E1＞25 and P1＜0.5)时检测为普通异常。

当检测到异常，或者发现恶化趋势后，即根据引发异常的资源消耗，对当前时间区段内的该类资源使用情况进行筛选排序，定位出在造成该类资源使用异常的具体服务进程。比如：如系统当前检测到综合性能指标为0.4，同时当前系统中，除正常CPU及IO使用外，资源消耗最多的是db filescattered read，则异常定位程序立即被触发，定位出当前时间区段内，该类资源的异常使用情况，供维护人员参考。

基于上述分析，本发明实施方式还提出了一种数据库异常检测系统。

图2为根据本发明实施方式的数据库异常检测系统的结构示意图。

如图2所示，该系统包括：运行状态信息获取单元201、运行状态趋势确定单元202和异常确定单元203，其中：

运行状态信息获取单元201，用于利用活动会话历史ASH接口从数据库获取运行状态信息；

运行状态趋势确定单元202，用于将预定时间段内的运行状态信息与该数据库的历史运行状态信息进行比较，以确定数据库的运行状态趋势；

异常确定单元203，用于根据数据库的运行状态趋势评估数据库是否存在异常。

优选地，该系统进一步包括资源消耗确定单元204和异常服务进程定位单元205，其中：

资源消耗确定单元204，用于当评估所述数据库存在异常时，确定引发数据库异常的资源消耗；

异常服务进程定位单元205，用于从引起资源消耗的服务进程中定位出异常服务进程。

其中，运行状态趋势确定单元202，可以用于将包括当前时间段的预定时间段内的运行状态信息与该数据库的历史运行状态信息进行同比；和/或，用于将包括当前时间段的预定时间段内的运行状态信息与该数据库的历史运行状态信息进行环比。

优选地，运行状态趋势确定单元203，可以用于确定数据库的突变状态趋势和/或渐变状态趋势。

其中：运行状态信息包括下列组中的任意一个或者多于一个的任意组合：数据库中央处理器CPU整体运行状况信息；各活动进程的CPU运行状况信息；数据库I/O整体运行状况信息；各活动进程的I/O运行状况信息；数据库内存等待整体状况信息；各活动进程的内存等待状况信息；数据库锁等待整体状况信息；各活动进程的锁等待状况信息。

优选地，预定时间段内的运行状态信息为最近15秒内的运行状态信息。以上虽然以15秒为例进行说明，本领域技术人员可以意识到，这种罗列仅是示范性的，并不用于限定本发明实施方式的保护范围。

综上所述，本发明实施方式结合系统综合性能评估指标，设计出一套实时高效的数据库多级别的绝对性能及相对性能评估方案，并依据此评估方案，设计出能够有效解决故障感知滞后性及故障定位难两大问题的数据库系统异常预兆检测及定位技术。

本发明实施方式借助于oracle 10g引入的ASH技术，实现了对数据库中最近时间内所有活动会话的资源消耗及资源等待情况的全记录，并以此为依据，实现了以秒为单位的持续时间段内数据库性能分析。而且，通过秒级持续时间段内的数据库性能持续分析对比，能够实现实时高效的数据库性能变化预兆告警，第一时间获知数据库性能变化趋势，解决了数据库维护人员故障感知滞后性的问题，同时，由于对数据库性能的监控分析细化到了会话级别，在实现对整库进行性能评估的同时，也实现了对单进程的性能评估，可以立即根据系统资源消耗及争用状况，定位到引起性能突变或者造成系统资源争用繁忙的具体session，具体sql等；以及在系统整体性能尚未恶化时及时定位出当前系统中持续占用核心资源的会话(cpu持续占用，持续离散读文件，持续占有锁等)，使维护人员能够有的放矢，迅速从源头上介入并处理问题，有效解决了故障发生时及发生后定位难的问题。

应用本发明实施方式以后，对数据库的故障处理机制，将从被动处理方式转入主动预防方式，从根本上有效降低故障发生及处理时间，从而有效的降低了应用对数据库性能故障的感知度。大大提升了数据库稳定运行指标。

以上所述，仅为本发明的较佳实施方式而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (11)

1.一种数据库异常检测方法，其特征在于，该方法包括：

利用活动会话历史ASH接口从甲骨文Oracle数据库获取运行状态信息；

将预定时间段内的所述运行状态信息与该数据库的历史运行状态信息进行比较，以确定所述数据库的运行状态趋势，并根据所述数据库的运行状态趋势评估所述数据库是否存在异常；

当评估所述数据库存在异常时，确定引发所述数据库异常的资源消耗；

从引起所述资源消耗的服务进程中定位出异常服务进程。

2.根据权利要求1所述的数据库异常检测方法，其特征在于，所述利用活动会话历史接口从数据库获取运行状态信息包括：

利用活动会话历史接口从数据库的v$session视图和/或v$session_wait视图获取瞬时的运行状态信息；和/或

利用活动会话历史接口从数据库的v$active_session_history视图和/或v$sqlstats视图获取预定区段时间内的运行状态信息。

3.根据权利要求1所述的数据库异常检测方法，其特征在于，所述将预定时间段内的运行状态信息与该数据库的历史运行状态信息进行比较，以确定数据库的运行状态趋势包括：

将包括当前时间段的预定时间段内的运行状态信息与该数据库的历史运行状态信息进行同比；和/或

将包括当前时间段的预定时间段内的运行状态信息与该数据库的历史运行状态信息进行环比。

4.根据权利要求1所述的数据库异常检测方法，其特征在于，所述确定数据库的运行状态趋势包括：

确定所述数据库的突变状态趋势和/或渐变状态趋势。

5.根据权利要求1-4中任一项所述的数据库异常检测方法，其特征在于，所述运行状态信息包括下列组中的任意一个或者多于一个的任意组合：

数据库中央处理器CPU整体运行状况信息；

各活动进程的CPU运行状况信息；

数据库I/O整体运行状况信息；

各活动进程的I/O运行状况信息；

数据库内存等待整体状况信息；

各活动进程的内存等待状况信息；

数据库锁等待整体状况信息；

各活动进程的锁等待状况信息。

6.根据权利要求1-4中任一项所述的数据库异常检测方法，其特征在于，所述预定时间段内的运行状态信息为最近15秒内的运行状态信息。

7.一种数据库异常检测系统，其特征在于，该系统包括运行状态信息获取单元、运行状态趋势确定单元和异常确定单元，其中：

所述运行状态信息获取单元，用于利用活动会话历史ASH接口从Oracle数据库获取运行状态信息；

所述运行状态趋势确定单元，用于将预定时间段内的所述运行状态信息与该数据库的历史运行状态信息进行比较，以确定所述数据库的运行状态趋势；

所述异常确定单元，用于根据所述数据库的运行状态趋势评估所述数据库是否存在异常；

该系统进一步包括资源消耗确定单元和异常服务进程定位单元；资源消耗确定单元，用于当评估所述数据库存在异常时，确定引发所述数据库异常的资源消耗；异常服务进程定位单元，用于从引起所述资源消耗的服务进程中定位出异常服务进程。

8.根据权利要求7所述的数据库异常检测系统，其特征在于，

所述运行状态趋势确定单元，用于将包括当前时间段的预定时间段内的运行状态信息与该数据库的历史运行状态信息进行同比；和/或

将包括当前时间段的预定时间段内的运行状态信息与该数据库的历史运行状态信息进行环比。

9.根据权利要求7所述的数据库异常检测系统，其特征在于，所述运行状态趋势确定单元，用于确定所述数据库的突变状态趋势和/或渐变状态趋势。

10.根据权利要求7-9中任一项所述的数据库异常检测系统，其特征在于，所述运行状态信息包括下列组中的任意一个或者多于一个的任意组合：

数据库中央处理器CPU整体运行状况信息；

各活动进程的CPU运行状况信息；

数据库I/O整体运行状况信息；

各活动进程的I/O运行状况信息；

数据库内存等待整体状况信息；

各活动进程的内存等待状况信息；

数据库锁等待整体状况信息；

各活动进程的锁等待状况信息。

11.根据权利要求7-9中任一项所述的数据库异常检测系统，其特征在于，所述预定时间段内的运行状态信息为最近15秒内的运行状态信息。

Images