公众号：杨建荣的学习笔记 · 作者：杨建荣 · 发布：2016-10-04 23:55:24 · 原文链接

黄金周里处理了一起紧急的问题，在外面幸亏有同事帮忙协助，等我赶回家去，赶紧继续处理。
首先问题是在晚饭时间左右开始发生，但是过了没多久又恢复了，所以这个问题暂时就没有引起太多关注，但是后面发现问题开始反复，而且数据库的负载开始急剧提升，后面也开始收到了不少的报警信息，一下子问题就变得紧急起来。
环境是10.2.0.3的数据库，在Solaris 10环境中。
当时的DB time情况如下，从负载来看，压力是非常大的，数据库几度出现了无响应的情况，这对于核心业务而言还是影响很大的。

这是一套很稳定的数据库，很稳定的说法主要是很少有变更，而且多年来系统一直表现稳定。
查看资源的使用情况如下，可以看到在问题发生时段，没有大批量的事务，没有大批量的资源消耗。

那看看等待事件，发现都是和锁相关的。根据wait class的指示是和并发相关的。如果看到如此的情况，而且很紧急，想必是很纠结的。

我们来看看问题时间段的SQL情况，看看是否因为SQL问题导致了严重的等待和锁争用。

这个地方就有一些误区，看SQL语句，默认会定位到top的几个SQL语句，细看所占的比例也蛮高，所以同事的注意力就集中在了SQL优化上，但是查看语句是一个很简单的查询，而且也是走了唯一性索引，那问题的症结在哪里呢。
可以从awrsqrpt的报告看出端倪，那就是存在大量的等待。其实执行的时间还是很短的。

那问题的原因怎么解释，到底在等待什么呢。这个需要对整个系统的架构和技术细节需要有一些了解。
首先现在的网卡使用了逻辑IP,如下所示。服务器存在两个物理网卡，现在对外使用的是一个网卡1（e1000g0）上绑定的一个逻辑IP，当然这么做也是有一些历史原因的。

而对系统的架构有一定的了解，会发现其实和另外一个数据库有一些关联。怎么解释呢，就是在问题发生的时候，另外一台数据库的负载也急剧提升。
我直接到另外一台服务器上查看发现存在大量的活跃会话，而在等待的就是下面的这样一个语句。看起来也没有什么问题，如果查看执行计划就会发现其实另外一台服务器中是使用了DB link来访问现在出问题的数据库。