利用智能图谱查找Oracle数据库问题的根因

白鳝的洞穴 2020-11-24

1351

Oracle数据库出现一些问题，特别是一些亚健康的问题，日常运维还是比较难以发现的，只有这些问题恶化了，真的导致了问题了，才能真正的被发现，不过那时候就已经晚了。所以说能够提前发现系统的隐患，并及时找到根因，那是最好不过的事情。不过由于深层次问题发现往往都需要做深度巡检，否则很难捕获到一些偶发性的问题。另外一点是，哪怕发现了一些异常，要分析到底问题的根因在哪，也是一件十分头痛的事情。如果手头有了智能化运维工具的支撑，那就另当别论了。

今天老白给大家分析一个真实的案例，用户把一周的监控数据发给老白在南京的实验室，希望我们对这些数据进行分析，找到一些系统潜在的隐患。在以往，利用离线数据进行数据分析，发现一些未知隐患的，其难度是非常大的,真实的案例少之又少。因为之前并不知道系统是否有问题，存在什么样的问题，所以我们说，难度很大。以往的做法是要客户提供一些AWR报告，由专家去分析这些报告，发现报告里的一些异常点，然后再和客户确认一些现象，补充采集一些数据来证明这些问题。如果做这件事的是一个比较资深的专家，那么可能能够发现一些关键性的问题，如果是一个水平很一般的人，能把AWR报告看懂1/4就已经十分难得了。2013年的时候，老白也曾经想模仿ORACLE公司的PTA做一个AWR报告的自动解析器，工具是做出来了，但是效果不好，普通的人看到这些问题发现和解析出来的数据，仍然是一头雾水。

不过随着系统健康管理工作的开展与我们的运维知识库的构建，一种基于运维知识图谱的新的自动化诊断手段，彻底改变了这种现状。这个运维知识图谱是我们的第二代运维知识图谱D-KNOWL 1.1,目前还在测试阶段，是准备12月份和D-SMART V1.9.8 AI增强版一起发布的产品。目前我们暂时把这个知识库接入了我们的D-SMART D-CENTER数据中心，用于我们的三线人员帮助客户分析运维数据。D-KNOWL 的第一次参与分析就显示出了巨大的潜力。首先我们看看问题是如何被发现的。

在这个系统的健康模型数据中，我们看到了一个低点，这套系统正常情况下，健康评分都在85分以上，不过偶尔也会出现低于80分的低分情况。以往用户一直觉得这套系统状态还不错，而且业务部门也没有明显的投诉，再加上这个现象出现的时间很短，几分钟后陆续就又恢复正常了，传统的监控模式觉得系统没宕机，就不会去做分析与跟踪了。如果这点小事都要去定位分析，那么运维这个活也没法干了。下面我们看看，基于智能知识库的运维是怎么干这个问题分析的。

首先我们点击雷达图看到确实有很多指标异常。如果分析数据的一个小白，根本不懂啥叫逻辑读，啥叫物理读，啥叫DB FILE SCATTER READ，那么我就直接点击指标，然后直接选择智能工具去分析好了。

大家看下面的截图，这货确实还挺好用，智能指标分析工具推荐了几个做问题溯源的工具用于定位当前可能存在的隐患：

我们系统中与IO分析相关的工具有好几十个，智能诊断工具只推荐了这几个。真的是比较贴心了。下面需要做的事情就是逐一点击这些工具，查找问题点，这个操作一般的对Oracle数据库有一点了解的人都可以轻松完成。可能有人发现这里确实有点不够智能，如果能够不需要人去点击就能自动进行分析就更好了。实际上D-SMART是支持自动执行的，只是目前我们缺省的情况都是手动执行。当然，目前D-SMART的智能还处于初级阶段，能够生成一份问题发现的报告，但是最终确定问题还是需要靠人工阅读这份报告，不过这份报告阅读起来比AWR报告要简单的多，我们只要关注标红的文字就可以了。

针对IO延时分析的工具也是一个基于运维知识图谱的智能化工具，这个工具的发现是当前系统问题主要集中在多块读，TOPSQL，磁盘IO，数据文件IO等方面。IO的平均延时，每秒物理读等方面都出现了异常。于是我们立即使用推荐的磁盘IO分析工具进行分析。

从磁盘IO上看，大量设备的平均延时都很高，后端存储的性能已经出现了问题。从这一点上，我们是不是直接把锅甩给存储就行了呢？恐怕是没这么简单，这是一套小系统，每秒超过200M的IO流量已经很高了。如果甩锅后端存储，存储运维的人肯定是不干的。还是老老实实继续分析吧，不是刚才AI还推荐了几个其他工具呢。

通过DIRECT PATH READ诊断工具我们发现，系统中的大多数（超过90%）物理读都是DIREC PATH READ产生的。工具也提供了相关的解决方案，通过设置数据库参数来避免这个问题。

既然发现了这个问题，顺便找找哪些SQL引起了这个问题也不是什么难事。这样，运维人员没有利用特殊的专家级的技能，仅仅依靠智能知识库的引导，就很快定位了问题。

从健康指标上发现了这个低点，到通过AI工具定位问题，最终发现了导致这个现象出现的三个比较重要的问题：（1）SQL语句不够优化产生了大量的全表扫描；（2）由于11g的特性，对于串行的表扫描也选择了DIRECT PATH方式，绕过了缓冲区，产生了大量不必要的IO；（3）后端存储的能力也出现了瓶颈，每秒200M的吞吐量，IO延时就超标了。这个以往一个水平较高的工程师花上一两个小时都不一定能完全分析清楚的问题，在基于运维知识图谱的工具的帮助下，花了大约5分钟就完成了。整个分析过程中没有使用特别专业的技能，也没有和客户要AWR报告，更没有让用户在生产环境中额外采集任何数据，甚至没有和现场运维人员做任何的交流。我想，随着运维知识图谱构建的日益完善，AIOPS真的是可以创造这样的奇迹的。

oracle

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

利用智能图谱查找Oracle数据库问题的根因

评论