匪夷所思：罕见的 Oracle 全局事务锁等待事件分析

悠悠 2022-04-17 04:56 217阅读 0赞

这是在某客户现场的一次即时分析，这个问题困扰了用户一段时间，数据库体现为严重的性能问题，导致应用出现大范围超时以及会话激增等问题，多次尝试 kill session 都无法彻底解决问题，重启后系统恢复正常。

拿到故障时刻的 AWR 报告，可以发现问题时刻，数据库的主要等待为：

**Global transaction acquire instance locks **和 **enq: TX - row lock contention。**

<table> 
 <tbody> 
 <tr> 
 <td> Event </td> 
 <td> Waits </td> 
 <td> Time(s) </td> 
 <td> Avg wait (ms) </td> 
 <td> % DB time </td> 
 <td> Wait Class </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> Global transaction acquire instance locks </td> 
 <td style="vertical-align:top;"> 5,342 </td> 
 <td style="vertical-align:top;"> 5,343 </td> 
 <td style="vertical-align:top;"> 1000 </td> 
 <td style="vertical-align:top;"> 74.09 </td> 
 <td style="vertical-align:top;"> Configuration </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> enq: TX - row lock contention </td> 
 <td style="vertical-align:top;"> 5 </td> 
 <td style="vertical-align:top;"> 1,437 </td> 
 <td style="vertical-align:top;"> 287308 </td> 
 <td style="vertical-align:top;"> 19.92 </td> 
 <td style="vertical-align:top;"> Application </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> DB CPU </td> 
 <td style="vertical-align:top;">&nbsp;</td> 
 <td style="vertical-align:top;"> 331 </td> 
 <td style="vertical-align:top;">&nbsp;</td> 
 <td style="vertical-align:top;"> 4.59 </td> 
 <td style="vertical-align:top;">&nbsp;</td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> direct path read </td> 
 <td style="vertical-align:top;"> 37,708 </td> 
 <td style="vertical-align:top;"> 72 </td> 
 <td style="vertical-align:top;"> 2 </td> 
 <td style="vertical-align:top;"> 0.99 </td> 
 <td style="vertical-align:top;"> User I/O </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> log file sync </td> 
 <td style="vertical-align:top;"> 7,817 </td> 
 <td style="vertical-align:top;"> 12 </td> 
 <td style="vertical-align:top;"> 2 </td> 
 <td style="vertical-align:top;"> 0.16 </td> 
 <td style="vertical-align:top;"> Commit </td> 
 </tr> 
 </tbody> 
</table>

其中 TX – row lock contention 等待十分常见，这个等待事件造成应用的阻塞也很容易理解，但是Global transaction acquire instance locks并不是常见等待，从字面上理解，是全局事务在尝试获取实例锁。这个等待在等待时间占比上，消耗了将近75%的DB TIME。

当然数据库中TOP 5中最严重的等待不一定是问题的根源，分析问题时刻的 ASH 信息，在问题时刻，最先出现的是全局事务获取锁的等待，随后开始出现行锁等待：

[原文链接][Link 1]

[Link 1]: http://click.aliyun.com/m/1000023637/