-
Recent Posts
Recent Comments
- yangtingkun on 非空字段空值对查询的影响
- Eric Zong on 非空字段空值对查询的影响
- Kamus on Oracle Ace Director
- 设置全局死锁优先级 | yangtingkun on RAC全局死锁检测时间
- ORA-600(krbounotread_noctx)错误 | yangtingkun on ORA-600(krboReadBitmap_badbitmap)错误
Archives
- December 2020
- February 2019
- December 2018
- November 2018
- October 2018
- July 2018
- June 2018
- May 2018
- July 2016
- July 2013
- June 2013
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
Categories
Meta
Tag Archives: 9.2.0.8
9iRAC环境遭遇library cache lock和library cache load lock等待
客户数据库版本为9208 RAC FOR AIX,客户反应系统缓慢,检查告警日志,发现大量Library cache lock和Library cache load lock等待。 由于客户的原因,这个问题只是远程协助的方式帮忙检查了一下,因此没有留下任何的操作记录,这里只是简单描述一下问题。 客户反应数据库操作响应变慢,平时一个执行很快的基于主键的UPDATE操作也变得异常缓慢,且执行计划本身并未发生改变。 登录数据库后检查两个节点上的告警日志,并未发现任何异常报错。分别检查两个实例的等待信息,发现除了上面提到的大量Library cache lock和Library cache load lock以外,还有明显的gc等待。 但是随后发现,查询V$SESSION和GV$SESSION的结果居然没有区别,接着查询GV$INSTANCE视图,发现只有当前的实例存在,而此时恰好连接另一个节点的工具出现了断连,以至于我一度以为另外一个节点上的实例已经DOWN掉,但是随后重新登录到该节点上,发现数据库实例仍然存在,而且登录到数据库实例中也可以进行任何正常的操作。不过发现在当前节点所有的GV$视图都只会返回当前实例的信息,这与另外一个节点的情况完全一样。显然两个节点间的通信出现了问题,当前节点已经不清楚另外一个节点的状态的。 现在再去分析那些等待信息已经没有太多的意义了,因为整个数据库已经处于不正常的状态。不难推断,当前数据库的异常是由于节点间的通信异常导致。由于9i使用的操作系统的CLUSTER,还没有Oracle的clusterware,剩下只能由操作系统或硬件维护人员去进一步跟踪了。 最终数据库和系统在夜间闲时进行了重启操作,重启后数据库恢复正常,GV$视图的结果也恢复了正常。
Posted in ORACLE
Tagged 9.2.0.8, cluster, gv$instance, library cache load lock, library cache lock, RAC
Leave a comment