。Library cache pin / library cache lock：当会话试图将一个对象“钉”在库缓存中以更改或测试它时会发生该事件，必须得到一个钉确保对象不会被改变;P1代表库对象地址，P2代表加载锁的地址，P3为模式+名字空间(来自v$db_object_cache);等待时间：PMON为1S，其他进程为3S.

。Log buffer space：当进程必须等待日志缓冲中的空间可用时发生;未使用参数;等待时间：1S，如果必须等待日志切换则为5S.

。Log file parallel write：会话等待LGWR写日志缓冲块到重做组成员时发生;参数P1代表要写入的日志文件数，P2代表要写入的OS块数，P3代表I/O请求数量;等待时间：实际的延迟。

。Log file sequential read：当进程等待块从在线重做日志文件读取时会发生该事件;参数P1代表重做日志文件的相对序列号，P2代表开始读取的块号，P3代表读取的OS块数;等待时间：实际的延迟。

。Log file switch (archiving needed)：指示ARCH 跟不上LGWR.

。Log file switch (checkpoint incomplete)：文件归档前检查点必须完成，指示重做日志文件可能太小。

。Log file sync：参数P1代表需要同步的日志缓冲中的缓冲的数量;等待时间：1S.

。SQL*Net message from/to client：如果很大，可能指示网络有问题;P1：显示网络驱动器的类型，P2代表字节数，P3未使用。等待时间：实际的延迟。

。跟踪CPU和其他统计：V$SESSTAT / V$SYSSTAT，其中包含了

等待事件：根本原因分析

。需要收集等待事件统计历史;

。Trace 10046，会有很大的负载但是可以得到最小粒度的性能数据;

。Statspack，不能得到会话级别的数据;

。使用BEFORE LOGOFF TRIGGER收集历史数据—低负载(如果会话被KILL或挂起则没有任何数据)。建立表并保持大约7天的数据，可以归档这些数据进行长期比较。将等待事件和产生该事件的SQL语句(V$SQLTEXT)保存起来。

推断常用等待事件：找到以及修复?

诊断IO相关的等待事件

。在任何系统中I/O操作都是最慢的活动;

。与I/O相关的最常见的事件：

Oracle进程想要的块当前不在SGA中，查看V$SESSION_EVENT的TIME_WAITED和AVERAGE_WAIT列，从系统范围的事件来看时，这通常是TOP 5.

大量的等待时间通常是由于应用程序问题，当前应该小于1cs.

如果db files sequential reads的对象是索引，应用程序可能执行了大量的索引读。考虑使用全表扫描是否合适???检查聚簇因子;检查两个初始化参数(optimizer_index_cost_adj和optimizer_index_caching)的设置。

如果db files sequential reads的对象��表—记住索引读后的rowid访问是顺序的。检查V$SYSTEM_EVENT的average_wait，其为TOP 5并不指示系统有问题，如果没有出现在top 5中，则表明其他等待有问题，需要解决。如果AVGERAGE_WAIT特别大—检查磁盘热点，10G使用ASM平衡负载。

Oracle会话使用db_file_multiblock_read_count从磁盘读取块到SGA，多块I/O请求通常与全表扫描和索引快速全扫描相关。过高的该事件值通常是应用程序的问题，需要使用更多的单块读(索引扫描)代替多块读。

如果全表扫描时恰当的，考虑实施多块读减少等待时间。如果应用程序开始高效运行，突然开始产生db file scattered read waits，查看是否有索引被删除或无效。

可以使数据库倾向于全表扫描的优化器参数包括：db_file_multiblock_read_count，hash_area_size，optimizer_index_cost_adj;通常表很久未分析也会导致该等待事件增加，检查表的last_analyzed;如果表有大量链接行也会产生��问题。

通常是磁盘排序太多，检查V$STATNAME，v$sesstat;决定内存排序的参数包括：sort_area_size，pga_aggregate_target;目标是尽可能的减少排序，使用UNION ALL代替UNION，哈希连接代替排序接合，嵌套循环代替哈希连接。

直接写来自SORT， CTAS， HASH， INDEX， 以及运行在并行模式的sqlldr;直接路径写的调整方法和直接路径读一样;首先调整对直接路径读和写影响最大SQL语句。

该事件属于DBWR进程。该事件如果很大意味着I/O问题，没有该事件的用户会话可能显示‘free buffer wait’，‘write complete wait’;检查系统是否支持asynch_io(HP仅在RAW上支持)，如果是则使用它，否则考虑使用多DBWRs.

该事件属于LGWR.这是一个系统范围的事件，用户会话可能指示‘log file sync’;查看v$system_event的time_waited和average_wait列，如果average is > 1cs，则系统可能正在经历较低的吞吐量;该事件的修复同Db file parallel write;不幸的是不能使用多个LGWRs;检查日志文件所在的位置是否有冲突，对某些操作使用NOLOGGING.

该事件通常是大量日志切换的征兆。增加日志文件的大小。

诊断锁相关的等待事件

。锁与闩的区别是：闩的唯一目的是探测排他访问内存结构，闩保护内存对象。锁的目的是：1.当资源在兼容模式时，允许多个进程共享资源;2.当资源在不兼容模式时强制排它访问。锁保护数据库对象，一共有6种模式：null， row share， row exclusive， share， row share exclusive以及exclusive.

查看V$SYSTEM_EVENT表的TOTAL_WAITS列，闩可以通过V$LATCH监控。在高并发的系统中，闩冲突时很常见的，应该被预计。5种最常见的闩等待为：shared pool， library cache， cache buffers chains， cache buffers lru chain， row cache objects.