statspack中易被忽悠的地方

最近在做一个省的调优时发现该省的数据库总是不定期的出现业务堵塞，而且晚上出现的情况更加严重些。为了分析该情况，部署了一个statspack，每隔10分钟收集一次数据。

发现在发生堵塞的时候，statspack中top 5 event的第一位是enqueue：

收集了好几个堵塞时刻的statspack，第一位都是enqueue。于是，我们在继续去找statspack中关于enqueue部分，但是每次的statspack中的Enqueue activity 部分总是有所不同：

CF的enqueue是表示controlfile的enqueue，莫非是备份在作怪？那尝试把备份作业取消掉；SQ的enqueue是表说sequence的enqueue，难道是序列的cache不够大？那尝试把序列的enqueue加大。

再次收集了一天的数据，凌晨还是enqueue的event最高。在下面的Enqueue activity 看到的还是SQ、CF之类的，且等待时间都不是很长。

是什么原因造成了enqueue？难道不是SQ或者CF的原因吗？

为了弄清原因，我找了一个平时会发生业务堵塞的凌晨，登录了数据库查看数据库状态，发现数据库中存在大量的enqueue，通过计算：

发现都是TX的mode 6的enqueue。

知道了这个，后续的解决办法就好找多了。发现是一个长时间做全表扫描的大表，要很久才做commit造成。

问题是，我们在statspack上看到的第一位enqueue，要具体分析却不能通过statspack中的Enqueue activity 去看！

并且，我们虽然在Enqueue activity 中看到CF的等待，其实这个等待和引起系统堵塞的TX等待在statspack中对不上号。

我在另一个时间段的statspack中更加证实了我的猜想，statspack中top 5 event中如果有enqueue，和Enqueue activity无关。

这次statspack的时候，在做数据库全备份（其实从sbtwrite2 的等待也能看出是在做备份），在top 5 event中没有看到enqueue，但是在Enqueue activity中，我们看到CF和TC的等待比较高，但是却没在top 5 event中出现。且那时也没有业务堵塞。

为了验证我的猜想，我再次做了一个实验，多个做update的进程被一个没有commit进程堵塞，这几个进程，都是tx的enqueue，在top 5中确实有看到enqueue，但是在Enqueue activity中看到却没有关于TX的：

不过，幸运的是，如果是在10g环境中，top 5中就能帮我们指出是什么类型的enqueue了，我们上面的那个Enqueue activity所对应的top 5：

可以看到，在10g中的top 5中已经指出了enqueue的类型：enq: TX – row lock contention。