等待事件说明三

一、log buffer space

当数据库产生日志的速度比LGWR 的写出速度快，或者是当日志转换（log switch）太慢时，就会发生这种等待。这个等待出现时，通常表明redo log buffer 过小，为解决这个问题，可以增大日志文件的大小，或者增加日志缓冲器的大小。另外一个可能的原因是磁盘I/O 存在瓶颈，可以考虑使用写入速度更快的磁盘。

 

二、log file parallel write

log file parallel write（SYSTEM I/0类）

1.LGWR专属事件，将日志缓冲区中的重做信息写入到联机重做日志组的所有成员，LGWR在该事件上等待写入的完成。

2.写入时机：

>>每隔3秒写入一次

>>在提交或回滚时

>>在满足_LOG_IO_SIZE阈值时

>>在日志缓冲区有1MB的重做项时

>>由DBWR提交时

3.用户会话提交事务时，LGWR会等待该事件的完成，用户会话则等待log file sync事件。

 

该事件的等待表示重做日志所处的磁盘设备缓慢或存在争用。
SELECT s.event, s.time_waited, s.average_wait FROM v$system_event s WHERE s.event IN('log file parallel write','log file sync');
注：'log file parallel write'事件的平均等待时间大于10ms(1cs)，这通常表示存在缓慢的IO吞吐量。

如果该事件的等待时间过长，除了改进IO吞吐量外，
也可以设法降低重做的数量。

>> 只要有可能就使用NOLOGGING选项。

>> CTAS操作也应该使用该选项。

也可以以较高的回滚段使用率为代价的较低提交频率，来缓解一些IO需求，使用以下SQL查出谁在频繁提交数据：
SELECT sid,VALUE FROM v$sesstat s WHERE s.statistic# = (SELECT statistic# FROM v$statname WHERE NAME='user commits') ORDER BY VALUE;

SELECT b.NAME, a.VALUE, round(SYSDATE- c.startup_time) day_old FROM v$sysstat a, v$statname b, v$instance c WHERE a.statistic# = b.statistic# AND b.NAME IN('redo wastage','redo size');

注：由于LGWR不象DBWR那样能够有多个，所以尽可能将REDO放在IO快的磁盘结构上，不要放在象RAID5这样的磁盘上。

热备可能创建大量的重做项，从而增加log file parallel write等待事件，所以热备份应该在非高峰时间内运行，并且应该尽可能将表空间排除在热备份模式外。
注意不要同时使用过多的重做项堵塞LGWR。可以使用下需的查询来找到每次写入的平均重做日志块的数量，以及以字节为单位的LGWR IO平均大小：
SELECT round((a.VALUE/ b.VALUE) +0.5,0)ASavg_redo_blks_per_write,round((a.VALUE/ b.VALUE) +0.5,0) * c.lebsz AS avg_io_size   -- 字节为单位
FROM v$sysstat a, v$sysstat b, x$kccle c
WHERE c.lenum =1
AND a.NAME='redo blocks written'
AND b.NAME='redo writes'

注：x$kccle.lebsz字段包含每个日志块的大小。

 

三、log file single write

该事件仅与写日志文件头块相关，通常发生在增加新的组成员和增进序列号时。头块写单个进行，因为头块的部分信息是文件号，每个文件不同。更新日志文件头这个操作在后台完成，一般很少出现等待，无需太多关注。也可能表示checkpoint中的等待。

 

四、log file switch

　　当这个等待出现时，表示所有的提交(commit)的请求都需要等待"日志文件切换"的完成。

　　Log file Switch 主要包含两个子事件:

　　log file switch (archiving needed)

　　log file switch (checkpoint incomplete)

　　log file switch (archiving needed)

　　这个等待事件出现时通常是因为日志组循环写满以后，第一个日志归档尚未完成，出现该等待。出现该等待，可能表示io 存在问题。解决办法:

　　可以考虑增大日志文件和增加日志组

　　移动归档文件到快速磁盘

　　调整log_archive_max_processes .

　　log file switch (checkpoint incomplete)-日志切换(检查点未完成)

　　当你的日志组都写完以后，LGWR 试图写第一个log file，如果这时数据库没有完成写出记录在第一个log file 中的dirty 块时(例如第一个检查点未完成)，该等待事件出现。

　　该等待事件通常表示你的DBWR 写出速度太慢或者IO 存在问题。

　　为解决该问题，你可能需要考虑增加额外的DBWR 或者增加你的日志组或日志文件大小。

 

五、log file sync

当一个用户提交(commits)或者回滚(rollback),session的redo信息需要写出到redo logfile中.
用户进程将通知LGWR执行写出操作,LGWR完成任务以后会通知用户进程.
这个等待事件就是指用户进程等待LGWR的写完成通知.

对于回滚操作，该事件记录从用户发出rollback命令到回滚完成的时间.

如果该等待过多，可能说明LGWR的写出效率低下，或者系统提交过于频繁.
针对该问题，可以关注:
log file parallel write等待事件
user commits,user rollback等统计信息可以用于观察提交或回滚次数

解决方案:
1.提高LGWR性能
尽量使用快速磁盘，不要把redo log file存放在raid 5的磁盘上
2.使用批量提交
3.适当使用NOLOGGING/UNRECOVERABLE等选项

可以通过如下公式计算平均redo写大小：

avg.redo write size = (Redo block written/redo writes)*512 bytes

如果系统产生redo很多，而每次写的较少，一般说明LGWR被过于频繁的激活了.
可能导致过多的redo相关latch的竞争,而且Oracle可能无法有效的使用piggyback的功能.

 

六、SQL*Net message from/to client

某些情况下可以显示出网络传输的问题，但多数情况下可以忽略。

 

七、SQL*Net message from dblink

指出与分布式处理有关的等待，此事件是通过DBLINKS联机查找其他数据库时产生。

 

八、timer in sksawat

指出一个较慢的ARCH进程，这或者是由于数据库的多个组件争用，或者是由于没有执行归档的足够的I/O进程/从进程。

 

九、transaction

等待其它事务rollback，这些事务可能是异常中断或者手工rollback，因为一些锁没有释放，阻塞了其它会话。

 

十、undo segment extension

表示在等待回滚段的动态扩展。这表示可能事务量过大，同时也意味者可能回滚段的初始大小不是最优，minextents设置偏小或者回滚段的数目不是最佳。考虑减少事务，或者使用最小区数更多的回滚段。

 

十一、write complete waits

指示与写入磁盘的buffer有关的等待，这种写入可能由DB buffer cache的正常老化引起。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/669010/viewspace-664095/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/669010/viewspace-664095/