数据库的等待事件，发现前几名是：

log file parallel write

db file scattered read

log file sync

db file sequential read

SQL*Net more data to client

发现前面的4项都是影响到数据库性能的问题：

log file sync：

这个等待时间是指等待oracle的前台的commit和rollback操作进程完成，有时候这个等待时间也会包括等待LGWR进程把一个会话事务的日志记录信息从日志缓冲区中写到磁盘上的重做日志文件中。因此当前台进程在等待这个事件的时候，LGWR进程同时也在等待事件log file parallel write。

理解什么造成这个等待事件的关键在于：对比这个等待事件和log file parallel write等待事件的平均等待时间：

l 如果他们的等待时间差不多，那么就是重做日志文件的I/O引起了这个等待事件，则需要调整重做日志文件的I/O，

l 如果log file parallel write等待事件的平均等待时间明显小于log file sync等待事件的等待时间，那么就是一些其他写日志的机制在commit和rollback操作时引起的等待，而不是I/O引起的等待。例如重做日志文件的latch竞争，会伴随出现latch free或者LGWR wait for redo copy等待事件

在V$SESSION_WAIT中，这个等待事件有3个参数：

P1	代表在日志缓冲区中需要被写入到重做日志文件中的缓存数量，写入的同时会确认事务是否已经被提交，并且保留提交信息到实例意外中断前，因此必须等待LGWR将P1数量的缓存写入重做日志文件为止。
P2	无用
P3	无用

如果这个等待事件在整个等待事件中占了比较大的比重，可以从3个方面来进行调整

1. 调整LGWR进程时期具有更好的磁盘I/O吞吐量，例如不要将日志文件放在RAID5的磁盘上

2. 如果存在很多执行时间很短的事务，可以考虑将这些事务合并成一个批量事务以减少提交的次数，因为每次提交都需要确认相关的日志写入重做日志文件，因此使用批量事务来减少提交的次数是一种非常行之有效的减少I/O的方法

3. 产看是否有一些操作可以安全的使用NOLOGGING或者UNRECOVERABLE选项，这样可以减少日志文件的产生

Log file parallel write

这个等待事件出现在党LGWR后台进程从日志缓冲区写日志信息到磁盘上的重做日志文件的时候。只有启用了异步I/O的时候，LGWR进程才会并行写当前日志组内的充作日志文件，否则LGWR指挥循环顺序逐个的写当前日志组重做日志文件。LGWR进程不得不等待当前日志组所有的重做日志文件成员全部写完，因此，决定这个等待事件的等待时间长短的主要因素是重做日志文件所在磁盘的I/O读写速度。

如果是当前LGWR进程写的速度不够快导致这个等待事件，可以通过查看一些和重做日志相关的统计值来判定当前的LGWR进程是否效率低下，具体的可以看 redo writes, redo blocks written, redo write time, rdo wastage, redo size等统计值，这些都是和LGWR进程性能直接相关的一些统计值。

在V$SESSION_WAIT中，这个等待事件的3个参数：

P1	代表正在被写入的重做日志文件组中的重做日志文件号
P2	代表需要写入重做日志组中每个重做日志文件的重做日志block数量
P3	代表I/O请求次数，需要被写入的block会被分成多次分别请求

如果这个等待事件占用比较多的时间，可以做如下调整

1． 采用UNRECOVERABLE/NOLOGGING操作尽量减少重做日志的产生

2． 在保证不会同时对市重做日志文件的前提下，尽量减少重做日志组中的成员个数，减少每次写重做日志文件的时间

3． 除非在备份情况下，否则不要在江表空间置于热备份的模式下，因为在表空间处于热备的模式下会产生更多的重做日志文件

4． 对于使用LogMiner、Logical Standby或者Streams，在能够满足要求功能的前提下，尽量使用最低级别的追加日志以减少重做日志的产生

5． 尽量将同一个日志组内的重做日志文件分散到不同的硬盘上，减少并行写重做日志文件时产生的I/O竞争

6． 不要将重做日志文件置于RAID5的磁盘上，最好放在裸设备上。

7． 如果设置了归档模式，不要将归档日志的目的地设置为存放重做日志的磁盘上，避免引起I/O竞争

关于Log的这2个问题的总结

通过上述对Log这2个问题的描述，以及产生的原因，除了Log file sync可能有其他方面的因素引起的（Latch），主要还是磁盘和使用习惯

1． 磁盘由于这些都是写磁盘所引起的，所以只有从减少写磁盘（指数据库本身的角度，和下列提到的用户操作习惯不一样）和加快写磁盘来减少这些等待时间

a) 尽量不要在RAID5的磁盘上保存重做日志文件，RAID5写的速度属于比较慢的

b) 在安全性保证的基础上，减少重做日志组成员的个数

c) 同一个日志组中的不同成员放在不同的磁盘上，加速写的速度。

d) 对可以采用NOLOGGING/UNRECOVERABLE的操作，使用这些选项减少log的产生

e) 有归档的，不要将归档的和在线重做日志放在一个磁盘上

2． 使用习惯如果用户不断的进行commit或者rollback，这样必定引起一次log日志的写操作。因此可以通过一些统计信息判断是否每次的日志的写操作数据量很小，这样通过调节用户的操作，将大量的数据更新合并到一个事务中来，这样增加每次日志的操作量，减少对日志的不断调用，提高LGWR的写的效率。

db file scattered read

这是一个非常常见的等待时间。当oracle从磁盘上读取多个block到不连续的高速缓存区的缓存中就会发生这个等待事件，Oracle一次最多能够读入的block数量由初始化参数DB_FILE_MULTIBLOCK_READ_COUND决定，这个时间一般伴随着全表扫描或者Fast Full Index 扫描一起出现。

在V$SESSION_WAIT中，这个等待事件的几个参数：

P1	代表oracle的文件号
P2	代表从这个文件中开始读取的block号
P3	代表从这个block开始需要读取的block数量

一般从这个3个参数，就可以回头查询到是在读取数据库的哪个对象，然后分析对这个对象的操作来进行优化Sql语句。

如果这个等待事件占的比重比较厉害，可以通过以下方法来调整

方法一

找出执行全表扫描或者Fast Full index扫描的Sql语句，判断这些扫描是否是必要的，是否导致了比较差的执行计划，进行调整。

从oracle9i开始，提供了一个视图V$SQL_PLAN，可以通过它帮助我们找到那些全表扫描或者Fast Full Index扫描的Sql语句：

查找全表扫描的SQL语句

Select sql_text from v$sqltext t, v$sql_plan p Where t.hash_value=p.hash_value And p.operation=’TABLE ACCESS’ And p.option=’FULL’ Order by p.hash-value, t.piece;

查找Fast Full index 扫描的Sql语句可以这样；

Select sql_text from v$sqltext t, v$sql_plan p Where t.hash_value=p.hash_value And p.operation=’INDEX’ And p.option=’FULL SCAN’ Order by p.