遭遇enq: RO – fast object reuse BUG

转自:http://www.dbaroad.me/archives/2010/01/enq_ro_fast_object_reuse.html

半夜被叫醒，唉，最近真是没休息好。。。
说是表分析很慢，检查了一下，发现表分析的进程等待事件是enq: RO – fast object reuse。TYPE为RO的，p这个真没见过。检查持有锁的会话，居然是CKPT进程。查看CKPT进程的等待事件，一般都是rdbms ipc message，也正常啊。

查询了v$locked_object、v$lock看看在分析的表是否有被锁住，发现没有。

既然跟CKPT进程有关，尝试了一些相关操作：
checkpoint、archivelog current、flush buffer cache

其中flush buffer cache似乎有一些作用，flush完后，enqueue消失，可过会又出现了。。。

当时还杂七杂八做了些查询，记不清了。最后还是到metalink上查了查，看看是不是有什么BUG。找到一个类似的：

Applies to: Oracle Server - Enterprise Edition - Version: 10.2.0.4 This problem can occur on any platform.   Symptoms * Database has been recently upgraded from 10.2.0.1 to 10.2.0.4. * There is 'enq: RO - fast object reuse' contention when gathering schema/table statistics in parallel using DBMS_STATS package (with DEGREE>1).     Cause Bug 7385253 10.2.0.4 RDBMS 10.2.0.4 BUFFER CACHE PRODID-5 PORTID-59 Abstract: DBWR IS CONSUMING HIGH CPU   The system state dumps shows that the CKPT background process is the one holding the needed RO enqueue although it is actually doing nothing.

版本相同，也是使用DBMS_STATS进行分析，DEGREE 10，看来是遇上了。将脚本里的DEGREE去掉,继续分析，正常了。

跟这个等待事件相关的BUG还挺多，什么truncate、drop partition table都有可能遇到。

后记：
分析脚本是一个表一个表地分析，等待是在分析到其中一个表时出现的。其间杀掉重启分析过几次，无效。去掉该表的分析，其它表的分析不受影响。后来，应用人 员向我反应，他们当时也在分析这张表，不过后来停了，汗，没发现。检查他们分析的会话，僵死在那了。不过单进程分析该表还是不受影响的。

— The End —