10.重要的Oracle等待事件
以下各节列出的等待事件由于会增加响应时间，所以都对系统性能有很大的影响。这些事件(以及其他几个事件)由于过度的资源需求，或对表、联机重做口志文件等Oracle基本组件的过度争用，被认为是低效的耗时事件。
注解 查询SELECT name FROM V$EVENT_NAME 提供所有Oracle等待事件的完整列表。
•缓冲区忙等待
缓冲区忙等待发生在缓冲区高速缓存区中儿个进程试图访问相同缓冲区时。Oracle会话等待另一个会话从缓冲区到缓冲区高速缓存的读操作。这种等待还可能在缓冲区位于缓冲区高速缓存中，但另 一个会话正对其进行更改时发生。
注解 从Oracle Database 10.2版本开始，缓冲区忙等待被划分成几个事件：你可能只具有非常少的缓冲区忙等待，但具有大量其他会话等待的读操作(以前作为缓冲区忙等待来报告).
当这个等待发生时应该査看V$SESSION_WAIT视图，以准确地了解到什么类型的块导致此等待。
引起高缓冲区忙等待的两个常见原因是对属于表和索引的数据块的争用，以及对段头块的争用。如果使用字典管理的表空间或使用手动段空间管理的本地管理表空间时，应该进行以下工作：
如果等待主要是在数据块上，试一下増加PCTFREE参数以降低每个数据块中的行数。还可以增加INITRANS参数以减少來自竞争事务的争用。
如果等待主要发生在段头，可通过增加问题段的自由列表或自由列表组数目，或考虑增加表或索引的区尺寸来解决此问题。
减少由于段头争用引起的缓冲区忙等待的最好方法是使用具有ASSM的本地管理的表空间。ASSM还能处理表和索引中数据块的争用。
除了段头和数据块争用外，还可能会有回滚段头和回滚段块的争用。但是，如果使用AUM,只需保证在撤销管理的表空间中有足够的空间以满足回滚(撤销)头和块即可，让表、索引数据块以及段头作为主要的问题区。下面的查询清楚地显示，在数据库中，缓冲区忙等待在数据块上：
select class, count from v$waitstat
where count > 0
order by count desc;
如果即使采用了ASSM,仍不能解决数据块缓冲区等待，这可能是由于索引选择不当导致较大的索引范围扫描所引起的。可试一下使用全局散列分区索引，也可以根据具体情况调优SQL语句以减少这些等待。Oracle好像说明过，如果使用AUM而不是传统的回滚段，则两种类型的缓冲区忙等待(撤销块和撤销头)会自动消失。但是，实际情况并非如此，如下面来自一个AUM的数据库的例子所示：
偶尔，可能会遇到这样的情况，其中缓冲区忙等待突然变得很大，但似乎说不出什么原因。sar 实用程序(使用sar -d选项)会指示这一现象由高请求队列和服务时间导致。这通常发生在磁盘控制器被大量I/O塞满时。一般情况下，这时会看到过多的信息转储，如果信息转储阻塞了I/O子系统，应该做下面的工作：
移动信息转储目录到一个不太忙的文件系统中，并且此目录只存储转储信息。
使用下面的init.ora或SPFILE参数控制系统中的信息转储。设置这些参数的值可能会把信息转储的大小从千兆(G)(或更多)减少到兆(M)。
SHADOW CORE_DUMP = PARTIAL /* or NONE */
BACKGROUND_CORE_DUMP = PARTIAL /* or NONE */
分析信息转储，看是否可利用必要的Oracle和操作系统补丁集来调整它们。
•检查点完成
CHECKPOINT COMPLETED等待事件表示会话正等待某个检査点的完成。这可能发生在关闭数据库或正常的检査点过程中。
• Db File Scattered Read
db file scattered read等待事件表示数据库中正在进行全表扫描(或索引快速全扫描)。初始化参数DB_FILE_MULTIBLOCK_READ_COUNT设置Oracle一次读取的块数目。如果在参数文件中不给这个参数设置任何值，数据库将百动调优它。虽然Oracle一次读取多个块的数据，但它可能会把数据散放在不连续的高速缓存缓冲区中。如果没有多少全表扫描，并且全表扫描主要针对较小的表，则不用担心这个问题。
但是，如果这个事件是…个重要的等待事件，则需要作为一个与I/O有关的问题(数据库不能处理较多的物理I/O请求)研究它。有两个可能的解决方案，减少物理I/O的请求或者提高系统处理更多I/O的能力。可通过进一步分析，观察是否下面的某个方案能起作用。提高SGA的缓冲区高速缓存组件一般会降低物理I/O性能。不过，我们假定通过设置SGA_TARGET初始化参数，使用自动共享内存管理，在这种情况下数据库会设置最佳缓冲区高速缓存：
在关键的表上增加缺少的索引(这种情况在产品系统中不太可能出现)。
如果SQL语句得不出高效的执行计划，则优化它们。
如果不存在减少物理I/O的可能，那么除了增加系统中磁盘的数目外没有别的选择。还需要仔细将频繁使用的表和索引分布在所有磁盘上以减少系统中的热点。还可以使用V$FILESTAT视图，确定其中进行全表扫描或索引快速全扫描的数据文件。在V$FILESTAT视图中有下面两个列极为有用。
phyrds：完成的物理读取数目;
phyblkrd：物理块读取数目。
显然，phyrds的数目等于或接近于phyblkrds的数目，因为几乎所有的读取都是单块读取。如果phyrds列显示一个比phyblkrds列小得多的值，则说明Oracle正一次读取多个块，即正在进行全表扫描或索引快速全扫描。下面是V$FILESTAT视图上的一个样例查询：
SELECT file#, phyrds,phyblkrd
FROM V$FILESTAT
WHERE phyrds != phyblkrd;
• Db File Sequential Read
db file sequential read等待事件表示正在将单个块读入缓冲区高速缓存。这个事件在索引读操作或等待物理I/O调用返回时发生。一般情况下，这没有什么好担心的，因为数据库必须等待文件I/O。但是，如果这个统计数据极大，则需要研究一下磁盘的I/O。
如果磁盘排序很高，可以通过増加PGA_AGGREGATE_TARGET初始化参数的值来使它们降低。因为这个事件的每次出现都证明应用程序正在大量使用索引，与db file scattered read事件不同，在这种情况下，你没有什么好办法来减少物理I/O的要求。
增加磁盘的数目并在磁盘之上条带化索引可能是减少db file sequential read等待的最好办法了。如果对象不太大，可使用DEFAULT和KEEP缓冲池来将它们保留在内存中。但是，如果对象较大，则不能这样处理。在大多数系统中，出现了索引读取，它不一定是件坏事，因为大多数情形下为进行更快的数据检索，需要索引。
