上周一个客户的系统出故障，一些微服务在连接数据时报了一个未知错误，因此大家都怀疑数据库的问题导致了本次故障，为了配合问题分析，我们也安排了一个DBA前往用户现场做综合排查。我们的同事到现场的时候，分析故障的小组也已经把数据库的嫌疑排名从第一名往后移而把网络放在重点排查的首位。
实际上在一个复杂的系统故障中，数据库想要自证清白有时候比发现数据库的故障更加困难。因为大多数数据库故障都有较为明显的现象，阻塞、卡顿、性能下降、服务中断等都可以从数据库自身的指标中发现问题，尤其是你在分析Oracle数据库的时候。而大多数数据库系统平时都处于亚健康状态，虽然没有大问题，没有引发故障，但是某些指标或者对外表现中还是能够发现大量不正常的因素的。只有有经验的DBA才能逐一将这些现象与故障现象排除。
上周的故障发生后，问题分析小组的朋友们就发现了各种监控手段的缺失，虽然说云平台、应用系统都号称提供了强大的监控工具，但是这些监控数据在真正问题发生的时候显得十分不够用。幸亏Oracle数据库有丰富的可观测性体系，能够保存大量的历史运行数据。今天通过这个案例我给大家介绍一下当一个复杂故障发生时，Oracle如何甩锅。
首先看ALERT LOG，在故障时段前后30分钟甚至更长时间范围内对ALERT LOG中的故障告警做认真分析，如果能够手工写个工具，将这段时间内发生的重要事件记录下来就最好了。实际上也很简单，只要把ORA告警与日志切换等重要事件的时间点与告警信息采集下来，按照时间顺序输出就可以了（日志切换只需要一个时间）。通过排查ALERT LOG，我们发现这个2节点RAC的ALERT LOG正常到了不能再正常了，日志切换也是正常的，平时大概5-10分一次，而故障期间内照样有日志切换发生，只是频率低了一些。说明数据库的总体是正常的，日志切换频率降低也有可能是应用出现故障导致的。
第二个我们需要去分析的就是AWR报告 ，通过AWR报告我们可以对数据库的宏观运行状态做一个初步的判断。在这个分析中，还是需要一定的技巧和经验的。
图片
Load Profile是大家必须关注的重要数据，很多经验不足的DBA往往会跳过这个数据，直接去看TOP EVENTS，实际上先看看负载是否正常更为重要。可以看出当时系统中的IO负载很高（RAC两个节点加在一起有8GB/秒），系统负载也不小。如果跑数据库的是一般系统，可能会出问题。不过考虑到这套数据库是跑在EXADATA X9上的，这种强度的负载也应该不是大问题了。从后面的TOP EVENTS和前台后台进程的EVENTS上，我们可以看到IO延时是很正常的。
图片
一些DBA看到这个等待事件的时候会觉得系统还真的有些问题，实际上有经验的DBA从Top 10 foreground Events中看到的满满的都是正常。首先AVG WAIT读不高，其次是没有哪个等待事件能看出来系统存在HANG住或者登录失败引起的问题。
看到上面我就基本上不认为这次故障的原因是数据库了。不过为了更加安全起见，我们还是去看看ASH，ASH是能够从微观角度发现数据库问题的重要数据，一般用于发现通过AWR很难发现的短时间问题导致的系统卡顿与故障。
图片
Activity Over Time是快速发现系统存在问题的重要数据，要验证这个数据库有没有和系统故障相关的大问题，基本上看一眼这部分数据就可以了。可以看出上面的数据也是没有问题的。
看到这里，你可以比较自信地去和平台组的其他同事互怼了，其他专业的人可能很难找到对你十分不利的直接证据了。不过对于应用无法正常连接数据库的问题，最好再看一眼listener日志。
图片
不出所料，监听日志也很干净，几乎没有任何报错。从上面的三方面的信息可以看出，数据库应该是无辜的。而且从监听日志可以看出，起码应用连接数据库的这段网络应该也是十分正常的，否则监听日志里会有大量的网络超时或者断联的告警信息。
对于Oracle这样具有十分完善的可观测性体系的数据库来说，只要有经验丰富的DBA参与，想要排除数据库的问题还是不算太难的。不过对于国产数据库来说就困难一些了，因为我今天介绍分享Oracle的方法用到国产数据库上的时候，就会因为缺乏准确的数据而无法完成了，这也是国产数据库应该抓紧完善的地方。
发现数据库系统没有问题确实比发现数据库存在问题要困难一些，因为需要分析者具有什么数据是正常的，什么数据是不正常的，什么样的故障在会反映到哪些指标上去，这样的一些分析经验，这些经验需要在不断的运维工作中不断积累。而拥有这些经验的人往往不会去写书来介绍这些经验，因此需要我们通过更广泛的学习来完成积累工作。
