love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客

Phone:18180207355 提供专业Oracle/MySQL/PostgreSQL数据恢复、性能优化、迁移升级、紧急救援等服务

Windows Oracle Rac instance ecvited due to lck0 hung

本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客

本文链接地址: Windows Oracle Rac instance ecvited due to lck0 hung

某网友反馈其一套windows 经常出现实例驱逐,从日志来看能看到如下信息:

此时查看问题节点的alert log信息就非常明显直观了,看上去也非常常见:

典型的ipc send timeout,然后出现通信错误,最终出现instance member kill。

在分析节点1的lgwr trace发现也出现了error 10054,与前面的alert log中ora-27300 error一致:

进一步分析节点2的日志中发现lck 进程在故障时间点表现异常,出于hung状态:

根据该时间点推算,实际上lck0进程在10:49:27开始出于not moved状态,其中从10:49:46开始等待’libcache interrupt action by LCK’。

通过检查diag dump发现该进程在等待IV lock:

根据时间点倒推5分47秒,差不多也在10:49:30之前,开始出现enq:iv – contention. 对于该等待,我们通常知道极有可能是因为rac节点两边cpu 数量不一致等,到ges进程数据不一致进而引发该问题,mos方面也有一些bug。

然而这里经过确认不存在cpu不一致的情况。同时从存活节点的diag来看,在10:50之后开始出现不少session hung的情况,这应该也是因为节点1 lck0 hung的缘故导致。 通过该查看该进程的history event可以看到p1,p2的情况:

而这里p1表示type+mode,p2表示lock reason。根据16进制转换大致理解为 synchronize library cache object invalidation。

由此我不得不怀疑在该时间段是否存在DDL等操作,进而引发了该问题。

由于该系统压力并不大,而且硬件配置不低,每个实例session在200-500之间,存储为全闪。因此我认为Bug的可能性较大。

其中mos也提到了一个bug,据说在11.2.0.4和12.2 fix。不过我认为11.2.0.4版本中仍然存在该问题。

Leave a Reply

You must be logged in to post a comment.