等待事件之日志等待事件解决办法

我坚持每天看3套rac的awr，总结了一下。 查找日志等待事件的SQL: 9i:select * from v$event_name where name like '%log%';(大概14个左右) 10g: select name,wait_class from v$event_name where name like '%log%';(大概35个左右) 11g: select name,wait_cl

我坚持每天看3套rac的awr，总结了一下。

查找日志等待事件的SQL:

9i:select * from v$event_name where name like '%log%';(大概14个左右)
10g: select name,wait_class from v$event_name where name like '%log%';(大概35个左右)
11g: select name,wait_class from v$event_name where name like '%log%'; (大概30个左右)

碰到比较多的是以下几个：

一、Log file switch(archiving needed)

即日志切换时，切换到目标日志组还未完成归档，那肯定要等待嘛。

可能原因：redo，archive分区I/O性能较差、归档写出缓慢、日志组数量设置不合理

解决方法: 1、增加日志组或日志组成员的大小

2、把archive log调整到IO性能较高的磁盘上，比如存储上

3、调整log_archive_max_processes参数

二、Log file switch(checkpoint incomplete)

说明日志切换时，切换到目标日志组时，那个日志组所保护的脏数据还没写入

可能原因：DBWn写出太慢、I/O存在问题

解决方法: 1、增加额外的DBWn

2、增加日志组或日志组成员大小

三、Log File Sync

可能原因:LGWR写出效率低下、commit过于频繁等

影像之匠PixPretty

商业级AI人像后期软件，专注于人像精修，色彩调节及批量图片编辑，支持Windows、Mac多平台使用。适用于写真、婚纱、旅拍、外景等批量修图场景。

206

查看详情

解决方法:1、提高LGWR写出效率，使用IO性能较好的磁盘

2、使用批量提交,(实时在线业务谨慎操作)

3、使用nologging/unreoverable选项（）

四、log file single write

产生原因:更新日志文件头时产生的等待

五、log file parallel write

产生原因:并行写入多个日志组成员的等待

六、log buffer space

产生原因:数据库产生的日志比LGWR写入的日志速度要快，或日志切换太慢

解决方法:1、增大log buffer

2、磁盘I/O存在瓶颈

备注一下：DB规划是redo分区，arch分区空间所占的硬盘尽量做RAID1

未完待续