基于Oracle 数据库性能异常诊断模型探析

韩 超，梁 策，贾琦婧

（中国民航信息网络股份有限公司 北京 101318）

0 引言

当前， 数据库系统成为信息技术（information technology， IT）架构下的重要支撑环节，数据库系统的健康状态在整个IT 业务系统的可用性指标中起到了决定性的作用［1］。基于此背景，实现数据库服务异常点快速定位，提前识别当前数据库系统隐患的工作变得至关重要。维持数据库系统的健康程度、快速地定位数据故障并能有效率地解决故障，使数据库系统状态健康、数据库系统的性能稳定地保持在一个相对良好的水平，成为当前数据库管理员（database administrator， DBA）与业务系统运维管理人员的长期目标。因此，如何快速发现数据库异常与隐患、如何有效率地收集故障现场dump trace 信息，为数据库当前出现的异常找到根因，成为DBA 的首要痛点。

本文基于Oracle 数据库软件（版本11gR2），立足数据库软件自身的特点、运行机理，结合现有的数据库专家故障处理经验，进行了一系列数据库软件异常点的组合建模，最终形成了基于Oracle 数据库的故障自动诊断系统。针对该系统实际工程落地的思路与难点，进行了剖析与展望，为该领域有关的后续研究提供参考。

1 数据库性能异常诊断模型

1.1 数据库性能异常诊断模型的定义

在数据库异常诊断模型中，故障模型是一个十分重要的模型，数据库性能异常诊断依赖故障模型中专家经验的丰富程度与算法的健壮性，进行数据库异常原因分析判断与计算。结合问题发现（监控预警）、建模分析（异常点组合）、报告分析（建议输出）3 个维度，最终可以快速定位数据库异常点，并自动提供有效的异常处置建议。

例如，当前数据库系统如果发现性能问题，DBA 可借助此自动化诊断分析模型进行故障处置。首先，该模型的故障诊断依据是由预先定义完备的一系列程序脚本组成的，这些程序脚本由数据库运维专家多年的运维经验汇总提炼得出，由平台自动执行并利用向量模型计算出异常的概率预期，最后向DBA 输出针对异常的已知解决方案。

1.2 数据库性能异常诊断模型的作用

目前，以本文所探究的Oracle 数据库软件为例，该数据库软件系统共涉及了375 个标准参数，2 914 个隐含内核参数和4 412 个动态性能视图，每一个参数、动态性能视图均有不同的作用。例如，某个特定参数控制着特定数据库功能的开关，某个动态性能视图提供了基于特定功能点的可观测性数据，各项数据指标的依赖关系十分复杂。如果当前数据库发生故障，DBA 可借助该异常诊断模型快速定位当前数据库系统异常点，避免了故障处置人进行繁琐的数据库指令输入，故障处置人无需具备丰富的数据库故障处置经验，按照模型提供的处置建议操作即可。除此之外，因将多个操作封装成了程序脚本，异常分析模型对于日常运维工作的便捷性也有了极大提高，针对各项运维工作提供了“一键式”“白屏化”的可能。

2 现有探索成果综述

数据库性能异常诊断模型可细化为专家经验模型、诊断路径模型和分析报告建议模型，共3 个维度。首先，专家经验模型需要预先定义已知异常故障点，如何对经过数据库专家积累、框架化的经验进行合理的编排与组合，是构建异常诊断模型的核心工作之一。其次，经验经过输出后，通过诊断路径模型进行自动化判定计算，形成最终的分析报告，从而提供对故障有价值的、经过专家经验计算的分析报告。

2.1 专家经验模型

在以Oracle 产品为研究数据库软件目标的背景下，专家经验可以借助Oracle 软件体系中的时间、等待事件模型，进而构建一系列的数据库故障图谱［3］。

2.1.1 数据库性能缓慢之异常等待事件模型实例

Oracle 数据库11G R2 版本开放提供了1 367 个等待事件，Oracle 数据库19c 版本上开放提供了1 920 个等待事件，数据库系统如出现性能异常，可以利用各个等待事件的关系进行组合编排，如表1、表2、图1 所示。

图1 新建故障检查项示意图

表1 异常等待事件Library Cache Lock 检查点示例

表2 等待事件Log File Sync 异常检查点示例

2.1.2 数据库SQL 效率健康度检查模型

在数据库系统中，结构化查询语言（structured query language， SQL）性能的优劣决定了数据库整体性能健康程度。数据库中的SQL 问题往往非常隐蔽（因为SQL 问题与数据量、表中的数据分布的变化有极大的关系），所以需要在SQL 出现隐患初期尽量将SQL 进行优化，在日常期间进行数据库中的SQL 巡检、风险SQL 的提前识别。针对SQL 问题，同样可借助专家经验进行封装，根据SQL优化的经验与对数据库优化器的理解，识别出数据库系统中当前低效SQL、低效索引进行优化［4－5］。如表3、图2、图3 所示。

图2 数据库中出现低效访问路径全表扫描的SQL 信息检查结果

图3 数据库中出现结果集偏小但使用了HASH JOIN 连接方式的SQL 信息检查结果

表3 SQL 效率健康检查点示例

2.2 诊断路径模型

本文通过基于专家经验的积累与实践检验，将各个定义好的检查点构建成针对故障点的诊断模型与决策树。诊断模型通过向量模型的建立，进一步计算根因概率预期，最终可构造决策树矩阵模型［6－7］。

根据需要定义故障检查点c与根因检查点f，借助专家规则从而最终定义CF（故障检查点与根因检查点）关系。如图4 所示，c1与f1、f2有关，f1存在2 个故障检查点，f2存在3 个故障检查点，故c1占比f1的权重关系为1/2，c1占比f2的权重关系为1/3，从而构建故障检查点与根因检查点的向量模型【R】。

图4 建立故障根因向量模型矩阵示例【R】

数据库系统性能出现异常情况时，运行此模型进行CF（故障检查点与根因检查点）分析，检查点c1…c4 结果命中故障检查点为权重为1，非命中故障检查点权重为0，故可构建现象矩阵【C】。如图5 所示。

图5 建立故障现象检查点矩阵模型示例【C】

根据检查点现象矩阵与故障根因向量运算结果的输入，构建概率矩阵，进行故障根因概率计算，故障现象检查点矩阵【C】×根因向量矩阵【R】 ＝最终故障原因分析结果－概率矩阵。如图6 所示，根因检查点f1概率为1/2，根因检查点f2概率为1，根因检查点f3概率为2/3，经过概率分析比较，故当前数据库系统异常时，由f2根因导致的可能性最大。

图6 概率运算结果算法示例

根据上述模型运算结果：f1＝1/2，f2＝1，f3＝2/3，所以，故障原因f2的发生概率最大。

2.3 分析报告建议模型工程落地

故障发生时借助前文提到的故障检查点模型与故障根因模型，通过概率计算预期得出根因报告。故障发生时点击故障定位按钮，模型并发执行定义好的故障检查项，输出最终定位的可能性。如图7 所示，检查“数据库硬解析类等待严重”故障点，并输出检查结果，正常为“绿灯”，异常为“红灯”。

图7 模型故障分析报告结果

3 数据库性能异常诊断与健康度检查模型未来展望

异常诊断与健康度检查目前已经成为基于机器学习的智能运维（artificial intelligence for IT operations， AIOps）建设道路上最为常见的方法与手段之一。异常诊断最早起步于日志分析，其主要方法是针对各类IT 组件的运行日志进行异常关键字的筛选并报警。但是，在分析较为复杂的数据库故障场景中会发现，故障点并非单一因素，每个数据库中的异常日志和数据库可观测性指标并不能独立地去审视，需要根据各指标变化的时间点，反复地结合故障现场进行分析。随着IT 技术的革新，数据库软件版本不断迭代，新的数据库架构与功能也同步更新。同时，复杂数据库故障诊断人工成本居高，导致数据库IT 从业人员在数据库故障诊断和技术栈知识掌握两方面增加了挑战，因此，减少数据库专家针对异常点的标注，是故障自动诊断处理首先要解决的问题。未来，可采用无监督机器学习的方法对数据库异常点进行分类，形成一系列独立的异常检查规则，针对不同故障，通过对异常检查规则进行编排，实现减少监督学习的异常点人工标注成本。基于以上背景提出以下展望：

第一，数据库性能异常的根因（决策树）、算法模型需要不断地进行更新与进步。故障点与故障处理知识图谱是无法穷尽的，通过机器学习手段的引入和算法专家的接入，减轻严重依赖专家经验的现状，降低故障模型训练的成本，是当前探研模型中的缺失部分，并成为当前的困境之一。

第二，在通过异常检测指标进行的异常诊断中，异常检测指标的判定十分重要。由于数据库在IT 链路上处于重要位置，大多的简单标准化指标无法使其充分发挥异常自动检测作用，需要运维团队结合企业自身应用、运维特点打造个性化的异常检测模型，并在经过“加工”后进行输出使用。针对同一个指标，不同的运维自动化系统采集出来的数值可能有所不同；不同能力的团队，对系统指标的认知也有所不同，因此采集和加工的方法也同样存在差异。对采集、使用的数据的标准化是建立健壮异常诊断系统的灵魂，否则模型永远是实验室中的“玩具”，无法形成最终的生产力。

第三，随着大数据、人工智能的发展，一条新的原因分析的路径也展现在面前，构建完善的指标集合，精确地采集动态性能数据，基于专家经验与案例抽象的“泛知识”体系的道路已经步入正轨。数据库是一个庞大且复杂的信息系统，同样要经历这个过程，只有越来越多的专家经验的输入、分享与算法专家的经验进行有机结合，才能够加快数据库在AIOPS 上的成长速度，更快地让AIOPS 在数据库领域产生更突出的实战效应［10－11］。

4 结语

综上所述，本文对当前主要探究的数据库系统性能异常诊断与健康度检查模型进行了论述，介绍了将该模型涉及的专家经验与涉及模型的建模思路，分享了当前工程化落地的一些成果内容，同时分析了模型现状的痛点与未来的改进方向，为该领域继续深入推进提供一定参考。