SQL> select event#,name,parameter1,parameter2,parameter3 from v$event_name where name = 'control file sequential read';
当数据库需要读取控制文件上的信息时,会出现这个等待事件,因为控制文件的信息是顺序写的,所以读取的时候也是顺序的,因此称为控制文件顺序读,它经常发生在以下情况。
(1)备份控制文件。
(2)RAC环境下不同实例之间控制文件的信息共享。
(3)读取控制文件的文件头信息。
(4)读取控制文件的其他信息。
这个等到事件的包含以下三个参数:
file#:要读取信息的控制文件的文件号。
block#:读取控制文件信息的起始数据块号。
blocks:需要读取的控制文件数据块数目。
====================================================================
请求控制文件的更新的进程直到更新结束为止,其间等待control file parallel write事件
SQL> select event#,name,parameter1,parameter2,parameter3 from v$event_name where name = 'control file parallel write';
这个等待事件包含三个参数:
files:Oracle要写入的控制文件个数。
block#:写入控制文件的数据块数目。
requests:写入控制文件请求的I/O次数。
一般环境下,因为更新控制文件的次数不多,因此不怎么发生control file parallel write等待现象。但如下情况下可能发生与控制文件相关的争用。
日志文件切换经常发生时:
日志文件过小时,将经常发生日志文件的切换。每当发生日志文件切换时,需要对控制文件进行更新,所以LGWR进程等待control file parallel write事件的时间将延长。
检查点经常发生时:
MTTR设定得过短或频繁发生人为的检查点时,CKPT进程等待control file parallel write事件的时间将延长。
nologging引起频繁的数据文件修改时:
对数据文件在nologging选项下执行修改工作时,为了修改unrecoverable SCN需要更新控制文件。这时,服务器进程将等待control file parallel write事件。
I/O系统的性能缓慢时:
最好是将控制文件位于独立的磁盘空间上,使用裸设备或direct I/O。
control file parallel write等待,通常与control file sequential read等待或enq: CF - contention等待一同出现的情况较多。enq: CF - contention等待是在多个会话为了同时更新控制文件获得CF锁的过程中发生的。control file parallel write、control file sequential read、CF - contention等待,全是因为过多的控制文件更新或I/O系统的性能问题引发的。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/31397003/viewspace-2152733/
,如需转载,请注明出处,否则将追究法律责任。