我坚持每天看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过于频繁等
解决方法: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
未完待续