这是在某客户现场的一次即时分析,这个问题困扰了用户一段时间,数据库体现为严重的性能问题,导致应用出现大范围超时以及会话激增等问题,多次尝试 kill session 都无法彻底解决问题,重启后系统恢复正常。
拿到故障时刻的 AWR 报告,可以发现问题时刻,数据库的主要等待为:
Global transaction acquire instance locks 和 enq: TX - row lock contention。
Event | Waits | Time(s) | Avg wait (ms) | % DB time | Wait Class |
Global transaction acquire instance locks | 5,342 | 5,343 | 1000 | 74.09 | Configuration |
enq: TX - row lock contention | 5 | 1,437 | 287308 | 19.92 | Application |
DB CPU | 331 | 4.59 | |||
direct path read | 37,708 | 72 | 2 | 0.99 | User I/O |
log file sync | 7,817 | 12 | 2 | 0.16 | Commit |
其中 TX – row lock contention 等待十分常见,这个等待事件造成应用的阻塞也很容易理解,但是Global transaction acquire instance locks并不是常见等待,从字面上理解,是全局事务在尝试获取实例锁。这个等待在等待时间占比上,消耗了将近75%的DB TIME。
当然数据库中TOP 5中最严重的等待不一定是问题的根源,分析问题时刻的 ASH 信息,在问题时刻,最先出现的是全局事务获取锁的等待,随后开始出现行锁等待: