行锁案例分析—enq: TX - row lock contention

今天遇到接到一个通知，让检查一下9点-10点数据库是否有性能问题。核心生产，不敢怠慢，感觉取个报告来瞅一瞅吧。

这是一个基于AIX系统的11.2.0.4的RAC。拥有64颗CPU。报告收集时间为9点-10点，60分钟。

这里我们注意到了一点，DB Time达到了4257，算一下，AAS也达到了70左右了，已经超过了CPU的数量，说明这个数据库在这个时间段还是挺繁忙的。下面来看看等待事件。

Top 10 Foreground Events by Total Wait Time

 

从上图的TOP 10等待事件看来，问题就出现了，TX锁问题严重，行锁最为明显，总的等待达到了217K。一个来自应用的行锁。

Wait Classes by Total Wait Time

这个wait classes的等待时间上来看，Application占比惊人的达到了85.3%，这已经是很高了。

现在找到了大致的方向，知道了是应用导致的行锁。后面就去看SQL吧。

SQL ordered by Elapsed Time

这里就大致能看出具体SQL的问题了，执行时间太长了。

Segments by Row Lock Waits

行锁的对象，查看到有UOS_CLSSERVER，WO_WORK_ORDER_ING，WO_WORK_ORDER，FAULT_ARCHIVES四个表以及IDX_SERVICE_ORDERID索引

现在已经确定了是应用的SQL导致的行锁，使数据库性能下降。

但是现在还有一个问题就是不能确定是否是以上查询的SQL，所以现在再取一个ASH报告

Top SQL with Top Events

这个看起来就非常的明显了，TOP 5的SQL全是 TX锁等待。四个update，一个delete语句，导致了数据库非常严重的行锁。

问题解决，把SQL提交至应用，让他们查看SQL是否存在问题。