概述

oracle等待事件是衡量oracle运行状况的重要依据及指示，等待事件分为两类：

空闲等待事件和非空闲等待事件。

空闲等待事件是oracle正等待某种工作，在诊断和优化数据库时候，不用过多注意这部分事件，非空闲等待事件专门针对oracle的活动，指数据库任务或应用程序运行过程中发生的等待，

视图v$session，v$session_wait，v$session_wait_history，v$session_event，v$system_event提供了等待哪些资源以及每种资源等待的时间（timed_statistics参数为TRUE）等信息。

V$EVENT_NAME视图包含所有为数据库实例定义的等待事件。

V$SYSTEM_EVENT视图显示自从实例启动后，所有Oracle会话遇到的所有等待事件的总计统计。

V$SESSION_EVENT视图包含当前连接到实例的所有会话的总计等待事件统计。该视图包含了V$SYSTEM_EVENT视图中出现的所有列。它记录会话中每一个等待事件的总等待次数、已等待时间和最大等待时间。SID列标识出独立的会话。每个会话中每个事件的最大等待时间在MAX_WAIT列中追踪。通过用SID列将V$SESSION_EVENT视图和V$SESSION视图结合起来，可得到有关会话和用户的更多信息。

V$SESSION_WAIT视图提供关于每个会话正在等待的事件或资源的详细信息。该视图在任何给定时间，只包含每个会话的一行活动的或不活动的信息。

V$SESSION_WAIT、V$SESSION_WAIT和V$SESSION_WAIT是3个重要的视图，它们提供了不同粒度级的等待事件统计和计时信息。

进行性能调优时，调查等待事件以及相关的计时数据，占用最多时间的事件常常是性能瓶颈的标志。

常见的等待事件和解决方法的一个快速预览

之前写的一个解决办法，不能发excel只能上图了，这里可以通过查询v$event_name查看所有的等待事件(wait events)。

查看前五等待事件

这里主要看前五的foreground wait events 和前5的Background Wait Events, 前台进程也会遇到db file sequential read ，后台进程也会遇到db file sequential read ，只不过 后台进程更多是一些 例如 log file parallel write(LGWR)、db file parallel write(DBWn) 的后台维护等待事件，同时后台进程的等待事件不计入DB TIME。

1、Foreground Wait Events

Foreground Wait Events 前台等待事件，数据主要来源于DBA_HIST_SYSTEM_EVENT

2、Background Wait Events

Background Wait Events 后台等待事件， 数据主要来源于DBA_HIST_BG_EVENT_SUMMARY

db file scattered read 文件分散读取

这个等待事件显示用户进程正在将缓冲区读取到SGA缓冲区缓存中，并等待物理I/O调用返回。db file scattered read进行离散读将数据读入多个不连续的内存位置。离散读是一个多数据块读，通常发生在索引快速全扫描和全表扫描。

相关sql：SELECT t.name,t.parameter1,t.parameter2,t.parameter3,t.wait_class FROM v$event_name t WHERE t.name = 'db file scattered read';

db file scattered read等待事件显示发生了全表扫描，当执行全扫描到缓冲区缓存，数据块被读取到物理位置不相邻的内存区域中，这种读取称为离散读调用，因为数据块在整个内存中是离散存放的。多块读（取决于DB_FILE_MULTIBLOCK_READ_COUNT数据块）由于全扫描到缓冲区缓存显示为等待‘db file scattered read’。

该事件通常与全表扫描或者fast full index scan有关。因为全表扫描是被放入内存中进行的进行的，通常情况下基于性能的考虑，有时候也可能是分配不到足够长的连续内存空间，所以会将数据块分散(scattered)读入Buffer Cache中。

该等待过大可能是缺少索引或者没有合适的索引(可以调整optimizer_index_cost_adj) 。这种情况也可能是正常的，因为执行全表扫描可能比索引扫描效率更高。当系统存在这些等待时，需要通过检查来确定全表扫描是否必需的来调整。因为全表扫描被置于LRU(Least Recently Used，最近最少适用)列表的冷端(cold end)，

对于频繁访问的较小的数据表，可以选择把他们Cache 到内存中，以避免反复读取。当这个等待事件比较显著时，可以结合v$session_longops 动态性能视图来进行诊断，该视图中记录了长时间(运行时间超过6 秒的)运行的事物，可能很多是全表扫描操作(不管怎样，这部分信息都是值得我们注意的)。

db file sequential read 文件顺序读取

这种等待事件是一种IO读请求相关的等待。与”db file scattered read“不同，因为”sequential read“是将数据读到连续的内存(注意：这里指的是读到相连的内存，不是说读取的是连续的数据块。同时一次”scattered read“可以读多个块，将他们分散到SGA的不同buffer)。这一事件通常显示与单个数据块相关的读取操作(如索引读取)。如果这个等待事件比较显著，可能表示在多表连接中，表的连接顺序存在问题，可能没有正确的使用驱动表;或者可能说明不加选择地进行索引。

IO是一种正常的活动，所以真正关心的是那些不必要的或明显缓慢的IO活动。如果花费在IO上的时间非常大，那么我们能够判断哪部分segement段，Oracle是需要从磁盘中获取的。可以查看ESTAT或STATSPACK报告中"Tablespace IO"和"File IO"节，可以得到一些关于哪些表空间/文件正在用于大部分IO请求，得到IO子系统处理速度的指标。如果花费在等待读的时间非常大，那么找出Oracle正在读哪些segment段是非常有帮助的。可以找到哪些文件正在被读。

找出哪些session正在读，并且通过trace跟踪他们来看IO是否正常，也是对此类等待事件的判断是有帮助的。下面的SQL可以找出哪些session值得跟踪：

SELECT sid, total_waits, time_waited FROM v$session_event WHERE event='db file sequential read' and total_waits>0 ORDER BY 3,2;

log file parallel write

这类事件从log buffer 写redo 记录到redo log 文件，主要指常规写操作(相对于log file sync)。如果你的Log group 存在多个组成员，当flush log buffer 时，写操作是并行的，这时候此等待事件可能出现。尽管这个写操作并行处理，直到所有I/O 操作完成该写操作才会完成(如果你的磁盘支持异步IO或者使用IO SLAVE，那么即使只有一个redo log file member,也有可能出现此等待)。这个参数和log file sync 时间相比较可以用来衡量log file 的写入成本。通常称为同步成本率。

改善这个等待的方法是将redo logs放到I/O快的盘中，尽量不使用raid5，确保表空间不是处在热备模式下，确保redo log和data的数据文件位于不同的磁盘中。

DB File Parallel Write

这类事件是文件被DBWR并行写时发生。解决办法：改善IO性能。

处理此事件时，需要注意

1）db file parallel write事件只属于DBWR进程。

2）缓慢的DBWR可能影响前台进程。

3）大量的db file parallel write等待时间很可能是I/O问题引起的。（在确认os支持异步io的前提下，你可以在系统中检查disk_asynch_io参数，保证为TRUE。可以通过设置db_writer_processes来提高DBWR进程数量，当然前提是不要超过cpu的数量。）

DBWR进程执行经过SGA的所有数据库写入，当开始写入时，DBWR进程编译一组脏块（dirty block），并且将系统写入调用发布到操作系统。DBWR进程查找在各个时间内写入的块，包括每隔3秒的一次查找，当前台进程提交以清除缓冲区中的内容时：在检查点处查找，当满足_DB_LARGE_DIRTY_QUEUE、_DB_BLOCK_MAX_DIRTY_TARGET和FAST_START_MTTR_TARGET阀值时，等等。

虽然用户会话从来没有经历过db file parallel write等待事件，但这并不意味着它们不会受到这种事件的影响。缓慢的DBWR写入性能可以造成前台会话在write complete waits或free buffer waits事件上等待。DBWR写入性能可能受到如下方面的影响：I/O操作的类型（同步或异步）、存储设备（裸设备或成熟的文件系统）、数据库布局和I/O子系统配置。需要查看的关键数据库统计是当db file parallel write、free buffer waits和write complete waits等待事件互相关联时，系统范围内的TIME_WAITED和AVERAGE_WAIT。

如果db file parallel write平均等待时间大于10cs（或者100ms），则通常表明缓慢的I/O吞吐量。可以通过很多方法来改善平均等待时间。主要的方法是使用正确类型的I/O操作。如果数据文件位于裸设备（raw device）上，并且平台支持异步I/O，就应该使用异步写入。但是，如果数据库位于文件系统上，则应该使用同步写入和直接I/O（这是操作系统直接I/O）。除了确保正在使用正确类型的I/O操作，还应该检查你的数据库布局并使用常见的命令监控来自操作系统的I/O吞吐量。例如sar -d或iostat -dxnC。

当db file parallel write平均等待时间高并且系统繁忙时，用户会话可能开始在free buffer waits事件上等待。这是因为DBWR进程不能满足释放缓冲区的需求。如果free buffer waits事件的TIME_WAITED高，则应该在高速缓存中增加缓冲区数量之前说明DBWR I/O吞吐量的问题。

高db file parallel write平均等待时间的另一个反响是在write complete waits等待事件上的高TIME_WAITED。前台进程不允许修改正在传输到磁盘的块。换句话说，也就是位于DBWR批量写入中的块。前台的会话在write complete waits等待事件上等待。因此，write complete waits事件的出现，一定标志着缓慢的DBWR进程，可以通过改进DBWR I/O吞吐量修正这种延迟。

篇幅有限，再写下去就变博客了...今天主要重点介绍这几个等待事件吧，大家有其他需要介绍的也可以在下方留言哦。后面会分享更多DBA方面的内容，感兴趣的朋友可以关注下！！