常见等待事件：
1 buffer busy waits
db file scattered read：和全表扫描或者fast full index scan有关，因为可能没有连续的内存，所有会将这些块分散的读入到buffer cache中。
db file sequential read：是由于执行对索引，回滚（undo）段，和表（当借助rowid来访问），控制文件和数据文件头的单块读操作SQL语句（用户和递归）引起的。
buffer busy wait：对于这个等待事件，很是有名，当缓冲器以一种非共享方式或者如正在被读入到缓冲区时（其实就是当会话需要访问某个buffer cache中的数据库块，而这个块此时被其他会话占用），就会出现这个等待。而这里的其他会话，其实可能是正在将数据文件中的块读入buffer cache，如果buffer cache的某个块正在更改，那他会有一个标记，表示此块正在修改，此块不共享。当出现该等待时，可以检查v$waitstat（SELECT * FROM V$waitstat WHERE COUNT>0;），确定等待发生在什么位置？
1）如果等待位于段头，则表示段头的空闲列表freelist的块比较少，如果使用assm：auto segment space management) 管理，则不太会出现这种情况。进程访问段头的原因有2个，1是获取或者修改process freelist信息，扩展高水位标记，因为段头里记录着freelists的信息，如果在freelists产生争用，那就更加freelist即可。反正就是啥争用我们就加啥就行。但如果是因为调整高水位线而频繁的访问freelist，那就增大next extend的大小。
2）如果等待位于undo段头，可以增加回滚段的数量来解决问题。
3）如果等待位于undo block，则需要增加提交的频率，使block尽快被重用，或者使用更大的回滚段，或者加大db_cache_size的大小。一般是由于读写同时进行而导致的，读进程需要到undo segment中去获取一致性数据，。解决办法就是错开这种操作。
4）如果等待位于data block，表示有hot block。解决方法：将频繁访问的表或者数据移动到另一个数据块，或者让每个块中储存少量的数据，这就需要调整pctfree的值了；优化sql，减少过多无用的数据块扫描；增加initrans。可以采用降低程序并发度的方法解决，但这种一般我们dba控制不了。
5）如果是索引块，可以重建索引，分割索引，使用反向索引。

当进程需要读取buffer cache时，具体步骤如下：
1）获得cache buffers chains latch，遍历那条buffer chain直达找到需要的buffer header。
2）根据需要进行操作（读或写），它需要在buffer header上获得一个共享或者独占模式的buffer pin或者buffer lock。如果是读就是共享，写的话就是独占
3）如果进程获得buffer header pin，它会释放获得的cache buffer chains latch，然后执行对bufferblock的操作。
4）如果无法获得buffer header pin，它就会在buffer busy waits事件上等待。为了保证数据的一致性，同一个时刻一个block只能被一个进程pin住进程存取。

诊断buffer busy waits事件的过程中，获得如下信息很有帮助：
1）获得产生buffer busy waits事件的等待原因编号，这可以查p3来得到。根据p1和p2最终定位到哪个段。
2）获得产生这个等待事件的sql，通过sid来查
3）获得等待的块的类型以及所在的segment。

2 free buffer
 表示buffer中已经没有可用空间，引起的原因可能是dbwr写的太慢，也可能是bufffer cache太小。
3 log file sync
 当提交或者回滚时，lgwr将会话的redo记录从日志缓冲区写到logfile中，用户的进程必须等待这个写的动作完成，在每次提交时都会有这个等待事件，只是我们要考虑的时会不会因为这个等待事件而影响db的性能，如果没有在top中发现，那一般不用太关心。解决方法就是减少提交频率。
4 log file switch
 表示归档速度不够快，所有的提交请求都在需要等待”日志文件切换“的完成。可以增加logfile 组。
5 db file parallel write
 文件被dbwr并行写时发生。解决方法就是提高io性能呗。虽然dbwr是后台进程，但如果它的写过于缓慢就肯定会影响sp进程。如果产生大量的db file paraller write的话，那可能是io引起的，在确认os支持异步io的前提下，可以修改disk_asynch_io为true。目前我们的生产系统就是true
6 direct path read
 直接路径读取是将数据块直接读入到pga中，一般用于排序，并行查询操作，这个等待可能是由于io造成的，使用异步io或者限制排序在磁盘上可能会降低这个等待。当排序在临时表空间中完成，并从临时表空间中读取结果时，会发生此等待事件。使用hash jion时，将不适合位于内存中的散列分区刷新到临时表空间中。为了查明匹配sql谓词的行，会话会在direct path read等待事件上等待。
7 direct path write
 系统等待确认所有未完成的异步io都写入磁盘时会发生该等待事件。oracle直接从pga写数据到数据文件或者临时文件，在并行dml操作时可能会发生，或者在磁盘排序时可能会发生。解决方法就是调整io
8 control file parallel write
 当更新所有ctlfile时，可能会出现。一般是由于ctlfile所在的磁盘io有问题。
9 library cache pin
 当有会话运行plsql，view等，又有另一个会话正要重新编译这些对象时会发生这个等待事件。
10 library cache lock
 通常是由于多个ddl操作导致，就是一个会话在library cache object上添加一个排他锁后，另一个会话也想加，然后就出现了这个等待事件。