数据是自动化与智能化的基础

　　传统的以人为中心的分析往往都是一点点的去采集数据的，而需要实现自动化或者智能化分析，这些数据采集必须能够自动的、高质量的进行，才能让整个分析过程能够顺利的自动化完成。

　　​周五下午的DTCC智能运维专场(专场19)因为临时原因，让我客串主持人，幸亏是线上会议，对主持人的形象要求不高，否则因为疫情原因两个月没去理发店的本尊真的很难上镜。

　　说到智能运维或者说自动化运维，实际上主要依靠的还是数据智能和知识智能。而知识智能的分析基础还是数据，因此说数据无论对于自动化运维还是智能化运维来说，都是最为关键的。本周二DBAIOPS社区的培训是由我来介绍如何利用工具来运维自己的数据库系统，其中我强调了“知识自动化”的基础就是数据，一个知识自动化系统从数据采集开始就已经充满了专家经验和知识了。

　　既然数据如此重要，那么我们需要什么样的数据呢?传统的运维自动化系统都仅仅采集用于告警的数据，当告警发生后，再去补充分析其他数据。这种模式在智能化运维时代已经越来越不适合了。要想实现自动化的智能分析，必须拥有较为完整的数据，利用这些数据，可以在故障现象发生时第一时间被捕捉到，并被分析与分类，告知运维人员的同时已经把大体的问题分类一并告知了。这样的告警可以加速故障定位，缩短消缺时间。

　　我临时画了一张草图，并不完整，如果对数据库需要采集哪些数据有兴趣的朋友，可以安装一套D-SMART社区版，在监控信息里可以看到D-SMART使用的监控信息，在基本信息里可以看到配置相关的信息。在集群拓扑里可以看到相关的关联信息。这些数据有些是可以自动化采集到的，不过有些是无法采集的，需要在配置的时候人工输入。

　　有道是书到用时方恨少，实际上数据只有到了要分析问题的时候才会发现是不够的。昨天网上有个朋友发了一个AWR报告，让人帮助看看，我正好有空，就下载下来看了看。这个案例挺有意思的，初一看，系统的问题有好几条线索。

　　从AWR上看，DB TIME确实很高，和Load Profile完全对不上，从上面的数据可以看出，系统的负载极小，每秒的执行数仅为153。不过负载不高有两种可能性，一种是从上游来的SQL并发量就很小，还有一种可能性是当时系统出现问题，形成了一定的阻塞，因此并发量下降了。

　　从TOP等待事件上看，排在第一位的是lru链的闩锁等待，这种等待并不常见，我们见得比较多的是CBC闩锁等待。这个闩锁等待一般来说是DB CACHE不够用的时候才会出现的。在如此小的并发访问下出现此类等待确实是十分罕见的。不过看到排在第三位的free buffer waits以及后面的write complete waits等待心里就有点数了，从这里可以看出是因为DBWR写脏块太慢才导致了free buffer wais，从而引发了LRU链闩锁等待。

　　原本想着只要确认了写IO存在性能问题，就基本上可以定位问题在哪了。于是立即查看后台进程的写IO相关的指标。

　　没想到写IO的性能指标并无大碍，文件写平均延时3毫秒，日志写平均延时不到1毫秒，按理说这样的写IO性能不会产生如此大的影响。不过从后台进程等待中我们也发现了一些特殊的东西，比如发现当时存在备份相关的等待。因为无法直接得出结论，所以必须继续查看更多的信息。

　　从IO情况分析看，确实读写IO都不大，表空间的读写延时也看不出什么问题。

　　不过从文件IO情况的汇总信息上还是能看出一些特殊的东西来。

　　这套RAC系统居然把数据文件存放在ACFS上了，在11.2.0.4上使用ACFS还是有很多坑的。从这里我们又发现了一条新的线索，是不是因为ACFS的BUG导致了IO性能问题，进而引发了这个问题呢?这就需要日志和TRACE的信息了，在AWR报告里我们是找不到答案的。

　　从参数小节里，我们也发现了一些异常，很多配置是来自于Oracle ODA一体机的配置模板，难道这是一台Oracle一体机?另外cpu_count=8也是有些异常的，因为从OS信息可以看出这是一台两路服务器，36核的。难道说这台服务器上还有其他数据库实例?

　　这些问题从AWR报告里都是没有的。必须和运维人员沟通才能获得到相关的信息。对于这些问题的不同回答，很可能问题分析的方向也会发生变化。如果这个数据库不是跑在Oracle一体机上的，那么很多参数设置就值得商榷了。如果说这台服务器只有一个实例使用，CPU_COUNT=8就是一个容易引发闩锁问题的设置，而且刚才我们看到的IO负载很小的结论也不存在了。因为我们必须看整个服务器上所有实例的IO负载，才能了解到IO是否存在负载过高的问题，这就需要OSW的数据作为分析的补充了。

　　传统的以人为中心的分析往往都是一点点的去采集数据的，而需要实现自动化或者智能化分析，这些数据采集必须能够自动的、高质量的进行，才能让整个分析过程能够顺利的自动化完成。甚至有些数据很可能都无法实现自动化的采集，必须由运维人员手工输入。比如redo是放在SSD上的吗?从REDO的写IO延时上似乎能看到这样的意思。数据文件是存放在SATA HDD还是NVME SSD上的呢?如果是存放在SATA SSD上，那么3毫秒的写延时虽然有点慢，但是还可以接受，如果是NVME SSD，那就说明IO性能下降的很厉害了。

　　通过这个案例，我们也可以看出完整的数据对智能化运维的意义。实际上这也是最难说服领导的地方，我曾经和一个客户沟通过建设智能化运维诊断系统。但是客户就不愿意花钱去改造运行指标采集模块，他觉得他们已经用了好几年ZABBIX了，基于ZABBIX采集的数据去做上面的分析应用不就够了，为啥还要再花钱呢?​

　　来源： 白鳝的洞穴

　　>>>>>>点击进入系统运维专题