​昨天晚上项目组向D-SMART研发报了一个故障案例，这个项目是以D-SMART为基础监控功能的常态化优化机制的项目。他们发现了一个数据库近期偶发性出现LOGON时间严重超长的情况。经过现场DBA的分析，发现是因为AUD$长期没有清理，数据量已经达到数千万条导致的。清理AUD$后，暂时还没有发现类似现象出现。

基于这个案例，他们向D-SMART项目组报了一个运维经验，那就是AUD$长期不清理，会存在会话登录延时加大的风险。

(资料图)

看到这个需求后，我第一反应是D-SMART日检里应该是有AUD$的检查项的，于是让他们现场确认一下，他们而模板里是否禁用了这个检查项。经过检查发现，他们并未禁用，每天也都是有这方面的告警出现的，以前这个日检告警也向甲方负责人汇报过，因为封网，最近无法做清理操作，所以才积压了大量的数据。

处理完这个问题，我就去干其他事情了。不过总觉得这个事情哪里有点不对劲。突然一想，AUD$数据量过大与LOGON超时有什么内在的关联呢？似乎并没有什么直接关联啊。因为LOGON的时候仅仅是往AUD$里插入了一条数据而已，并没有去读取AUD$表的数据做什么分析，往一张1000条记录的表里插入一条数据和往一张1000万记录的表里插入一条数据应该不会有如此巨大的差别啊。于是我在微信里又问了现场的DBA，他怎么发现AUD$引发了LOGON超时这个问题的。

他说他分析了故障期间的AUD$的插入语句，244条INSERT花了128秒，而清理了AUD$后，304条花了1.25秒，效果是十分明显的。于是我让他查查是否存在LOGON触发器之类的机制，或者一些特殊的审计项，他的反馈是没有。

这就让人不解了，从机理上看，AUD$表变成5GB+并不会引发插入一条记录的性能下降100倍，从而导致LOGON超时。因此我相信一定是其他的原因导致了这个问题。于是我让他用hola导出数据发给实验室。不巧的是，他们的版本是V2.1的，而且因为要纳管上千个运维对象，采用而是分布式部署的模式，目前的hola 1.0.2有个BUG，无法从分布式部署的D-SMART里导出数据。于是我让他把今天发生故障的两个时点各生成一份“问题分析”报告，发过来。

从等待事件分析方面可以看出，排在前几位的都是GC相关的指标，其中也发现了AUD$这张表存在热点。

从IO上看，IOPS/IO吞吐量都不算太高。OS方面应该没有太大的IO压力。因为客户那边的安全限制，这个系统的所有操作系统层面的指标以及日志都没有采集，因此我们无法分析操作系统IO延时是否正常。

不过从报告中可以看出，几乎所有的数据库写IO指标都超标，而读IO指标没有一个是超标的。这就更让人费解了。

另外一个节点也出现了LOGON超时的现象，不过从问题分析报告上看，等待事件完全不同。排在前几位的是log file sync等与IO相关的指标。同时我们也发现系统中存在gcs log flush sync的现象。

从这些问题上看，AUD$写入延时加大并不是因而更像是插入数据的性能受到了其他方面的问题的影响。于是我让现场DBA把操作系统日志与数据库日志都发过来。

在出现GC争用的节点上，日志一切正常，而在出现Log file sync延时超时的节点上，我发现了多路径抖动的日志告警信息。自此，这个问题的脉络已经十分清晰了。因为节点2上的多路径抖动，导致了IO延时的不稳定，从而引发了AUD$插入数据的性能问题，最终导致了LOGON超时。

一个不经意的发现，排除了一个系统的严重隐患，这套系统每个月月底和月初是十分繁忙的，要做大量的数据写入和计算。幸亏问题在业务十分小的时候被发现了。否则月底肯定会出大问题的。而这个问题的发现过程也有很大的偶然成分。本来现场DBA认为已经解决了这个问题。要不是现场与后端的这个故障案例共享机制的存在，这个隐患很可能要到引发大问题的时候才会被发现。

而分析问题，大部分情况下，我们仅仅是从表象入手，问题暂时不重现就算搞定了。而如果分析这个问题的人缺少对数据库机理的深入理解，是很难从这些表象中发现深层次的问题的。而且实际上，在运维体系中，一线工程师也不可能放置如此高水平的DBA的。

正是因为这个原因，我们一直强调，工具不是万能的，一线驻场运维也不是万能的。必须形成一个良好的问题闭环分析生态，让高水平的专家、一线、二线运维人员、高质量的监控数据采集与分析工具相结合，形成一个完整的体系，才能够更为高效与准确的分析问题和解决问题。

而从表象与机理这个问题上，我一直强调问题溯源或者说根因溯源的重要性。以前与一些运维专家讨论过这个问题，一些互联网企业出身的人认为系统出问题，有高可用机制可以解决就行了，切掉有问题的部分组件自然就解决问题了。还有一些人认为出问题后尽快回复运行是关键，根因分析能做则做，不能做就算了，企业无法投入如此大的成本。

从某些场景和用户的角度来说，这些观点也都没错。不过并不是所有的企业都有互联网企业那么完备的高可用机制，也不是所有的系统都是重启一下就能解决问题的。因此问题溯源，问题闭环对于大部分企业来说，应该还是有价值的。目前无法全面开展的最主要问题还是成本太高，能力不足的问题。IT健康管理机制就是为了解决这种分散分析的成本问题的，通过一二三线联动，通过D-SMART丰富的数据采集与诊断报告，再加上最近推出的holadata数据交换工具。三线专家可以足不出户为全国的客户做服务，其效率提升是十分明显的。昨天的这个问题，算上在微信群里的讨论以及现场采集数据的时间，专家参与定位问题的时间也不过20分钟而已。

关键词： 这个问题 解决问题 操作系统 问题分析 可以看出