案例:troubleshooting LCK PROCESS HANG CAUSING ENTIRE DATABASE TO HANG

本案例来自西区某客户,数据库版本为12.2,6节点rac,当时应用反应异常缓慢。十万火急,需要立马解决。当我接手时,故障已经持续了3个小时了。

当时查询gv$session时,发现大量会话的final blocking session都是6节点的LCK1进程,该进程等待事件为libcache interrupt action by LCK。由于时间紧急,果断的abort掉了6节点的实例,数据库立马恢复了正常。

当分析原因的时候,发现当时数据库hang得非常严重,连ash和awr都没有产生。但是从diag/dia0/lmhb trace中可以发现一些有价值的信息。

首先LCK是rac非常核心的进程,用于同步GES层面的一些实例级别的lock信息,比如row cache、library cache。而lmbh正好会监控这些核心rac核心进程。

从lmhb trace可以看到:

LCK1进程已经hang住了,并且持续了很久。并且lmhb中还记录了LCK1的process信息,包含了call stack。

从loadavg,包括当时cpu使用率,内存使用率来看,当时负载其实很低,并且LCK1进程处于R状态。call stack为:kglobscfix_callback()+64<-kglScanReferences()+222<-kglHandleMessage()+118<-kqlmbivg_cbk()+1647<-kqlmbivg()+391<-kqlmba()。负载很低的情况下,LCK1 hang住那么很可能是一个bug。

分析diag trace的systemtate dump,可以找到LCK1进程的session state dump信息。

可以看到当时LCK1已经以EXCL模式持有了两个mutex,还有一句Could not acquire mutex…Returning without dumping 。没见过,看着像还在请求其他mutex,并且失败。

搜索mos发现与Bug 30384121 – lck process hang causing entire database to hang (Doc ID 30384121.8)非常匹配,包括关键的call stack信息。

bug描述与trace发现的信息几乎完全匹配。基本可以确定就是这个bug引起的故障。

数据库的patch信息为:

而该bug将在12.2的202007这个ru中修复。

over!!!

 

 

 

 

此条目发表在Oracle, Oracle troubleshooting分类目录,贴了标签。将固定链接加入收藏夹。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注