遭遇大量CF类型的enqueue [转]

http://xueji03.itpub.net/post/37595/465890

发现一台正式环境io偏高，抓了个statspack，命中率什么的都较为理想，突出事件是enqueue，遂直接找Enqueue activity部分查看，确定为CF类型：

Eq Requests Succ Gets Failed Gets Waits Time (ms) Time (s)
-- ------------ ------------ ----------- ----------- ------------- ------------ CF 7,900 7,866 34 991 298.22 296

再check视图v$enqueue_stat：

SQL> select * from v$enqueue_stat where cum_wait_time>0 order by inst_id,cum_wait_time;

以现CF类型的enqueue最近发生得很频繁：

1 CF 12894072 1895049 12879213 14835 29183985

google网上案例，发现有insert 带blog字段表sql所导致的例子，如: http://logzgh.itpub.net/post/3185/224769

目前暂时未抓取到sql，准备写一个procedure去监视一下并抓取到导致enqueue的sql语句。通过owi来监控db这事情挺早就已经准备做，事情太多，这回不能够再拖了。

另外，metalink上297845.1这一篇文档可以参考一下的。还有另外二个链接：

http://lcmlsj.itpub.net/post/22187/271326

http://litterbaby.itpub.net/post/16841/276328

最新回复

看你的lob是不是nocache的，如果是这个会导致大量CF.

大量并发改变nocache类型的LOB会导式大量跟新controlfile中的unrecoverable_time，这样会导致CF锁。

一般处理办法是设置一个event（忘了是什么了,你查一下)屏蔽掉unrecoverable_time的记录，不过这样rman中的report unrecoverable就不启作用了。

不过可以提高lob的效率~