WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!
昨晚快要睡觉了，一个电话过来，说一个比较重要的数据已经出了点问题，说是归档满了，报ORA-00257错误，数据库不能登录，比较紧急，听到这个电话后，我知道是什么回事了：这个数据库每晚0点做备份，但是这个数据库的asm磁盘组剩余空间比较小，只剩下75g，且每天的归档是往asm磁盘组上放的，今天可能是有什么操作产生了大量的并删除归档日志信息，还不到0点就将这70多g的空间用完了。连忙打车赶到现场，很快着手删除过旧的归档日志，很快数据库就能访问了，问题解决，但是临走前再看了一眼alert_log日志，发现有如下信息：
Mon Dec 19 20:23:31 CST 2011
>>> WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! pid=251
System State dumped to trace file /home/oracle/admin/emspda/udump/emspda1_ora_11803.trc
Mon Dec 19 20:45:22 CST 2011
>>> WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! pid=1066
System State dumped to trace file /home/oracle/admin/emspda/udump/emspda1_ora_20829.trc
Mon Dec 19 22:26:16 CST 2011
>>> WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! pid=1061
System State dumped to trace file /home/oracle/admin/emspda/udump/emspda1_ora_32726.trc
Mon Dec 19 22:36:43 CST 2011
这是一个rac的数据库，数据库版本10.2.0.5
没有其他的信息可供查询，通过分析这个时间段awr报告，发现数据库中有个奇怪的sql：SELECT ORA_TQ_BASE$.NEXTVAL FROM DUAL，造成数据库产生enq: SQ - contention大量的等待时间，看到这个等待事件后，第一反应就是这个sequence的cache太小，特别是在rac环境中，通过查询oracle技术支持网站，发现这个是oracle的一个bug，这个bug已经在10.2.0.5中解决，且我们的数据库版本也是10.2.0.5，但是还是报这个错，也许产生这个问题和归档满了有关系，磁盘组没有空间了，系统表空间剩余的空间很小，导致数据字典争用，也可以通过调大这个sequence的大小解决这个问题，下面是具体的bug信息见：
Bug 6027068 - Contention on ORA_TQ_BASE sequence [ID 6027068.8]
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/12129601/viewspace-713659/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
最新文章
- 关于HBase协处理器导致问题的研究
- ORA-00600: 内部错误代码, 参数: [ktspScanInit-l1], [], [], [], [], [], [], []
- ORA-12012: error on auto execute of job "ORACLE_OCM"."MGMT_CONFIG_JOB_2_2"
- ORA-00600: 内部错误代码, 参数: [qertbFetchByRowID], [], [],
- ORA-00600: internal error code, arguments: [kcbgtcr_13], [], [],
- PL/SQL:ORA-00980同义词转换不再有效
- ORA-31693;ORA-31617;ORA-19505;ORA-27037
- ORA-00600: internal error code, arguments: [1433], [60], [], [], [], [], [], []
- ORA-01031,ORA-01031错的分析与处理
- Fatal NI connect error 12170
