甲骨文等待事件之询问:CF - contentio

排队是一种保护共享资源的锁定机制,避免因并发操作而损坏数据,排队采用排队机制,即FIFO(先进先出)来控制资源的使用。在任何需要读取控制文件的动作时,就会发生等待事件询问:CF -争用,CF锁被用来串行化controlfile事务,在读和写控制文件的时候使用该锁。通常该锁的分配时间非常短,比如在下面事件中会分配该锁,那么也就可能发生询问:CF -竞争等待事件:

检查点

重做日志文件的切换

重做lofileg的归档

执行实例恢复

操作重做日志文件

热备开始和结束

nolog事物的DML操作

如果某个事物设置了nolog属性,那么如下动作更容易产生该等待事件:

直接负载(SQL *装载机)

direct load插入

CREATE TABLE……选择

创建指数

ALTER TABLE……移动分区

ALTER TABLE……分割分区

改变指数……分割分区

改变指数……重建

改变指数……重建分区

插入、更新和删除在lob NOCACHE nolog模式存储了

查询该等待事件的持有人

选择l。席德,p。程序中,p。pid, p。spid, s。用户名、s。终端,s。模块,年代。行动,年代。事件,年代。wait_time, s。seconds_in_wait, s。州

v $锁l, v会话年代美元,美元过程p

l。sid=id

和s。paddr=p。addr

和l。类型=癈F”

和l。lmode祝辞=5;

查询该等待事件的服务员

选择l。席德,p。程序中,p。pid, p。spid, s。用户名、s。终端,s。模块,年代。行动,年代。事件,年代。wait_time, s。seconds_in_wait, s。州

v $锁l, v会话年代美元,美元过程p

l。sid=id

和s。paddr=p。addr

和l。类型=癈F”

和l。请求祝辞=5;

原因分析及解决办法:

如果持有人是后台进程,比如lgwr, ckpt, arcn等,那么检查重做日志大小,切换频次,检查fast_start_mttr_target的设置,检查归档路径是否可用。

如果是持有人是前台进程,那么大都是由于nolog的事物上正在发生DML或者DDL,此时由于nolog属性,那么甲骨文需要向控制文件中记录不可恢复的SCN,典型的是伴随询问:CF -争用的通常还有控制文件并行写,这个会话在写的过程中持有CF锁,其它会话如果也要更新控制文件的话,那么就要等待了。


甲骨文等待事件之询问:CF - contentio