•Direct Path Read和Direct Path Write
direct path read (直接路径读)和direct path write(直接路径写)事件是发生在绕过SGA缓冲区高速缓存，执行PGA的直接读或写时的等待。直接路径读表示排序在磁盘上而不是在内存中进行。它们也可能由繁忙的I/O系统所导致。如果采用自动PGA调优，不应该经常遇到这个问题。
Oracle自动进行PGA调优应该会减少由于较低的PGA内存分配而导致的磁盘排序。另一个解决方案是增加磁盘的数目，因为这个问题也会导致I/O系统不能满足増加的将块读入PGA的请求。当然，调优SQL语句本身以减少排序在这种情形下也不会有坏处。
•Free Buffer Waits
free buffer waits®常出现在数据库写进程较慢时。数据座写进程不能满足维护缓冲区高速缓存的请求。高速缓存中等待写到磁盘的脏缓冲区的数目比数据库写入进程每批可写的缓冲区的数目大.同时，会话必须等待，因为它们不能获得供写入的可用缓冲区。
首先，需要排除缓冲区高速缓存是否太小的问题，并利用操作系统工具检査服务器上的I/O数，特别是等待时间。检査数据库缓冲区高速缓存，并浏览一下Database Control的Memory Advisor将使你了解到各种内存组件的使用模式，以及缓冲区高速缓存是否低于最佳水平。如果缓冲区高速缓存低于最佳水平，可增加缓冲区高速缓存的尺寸。当然， 如果使用Automatic Shared Memory管理，数据库将会自动设置SGA的尺寸。
系统中出现大量free buffer waits的另-原因是数据库写进程的数目不够，不能完成实例需要完成的1：作亀。此时，可在默认的数据库写进程数目之上增加更多的写进程，使得主机上每8个处理器可以有一个数据库写进程。如果数据库执行了大量的数据修改，并且数据库写进程引发了等待事件，多数情况下，设置DB_WRITER_PROCESSES初始化参数为2-10之间的值，可以增加数据库写入进程的数目，从而减少这些等荐。Oracle建议对系统上每4个CPU使用一个数据库写进程。DB_WRITER_PROCESSES初始化参数不能动态更改，因此为更改数据库写进程的数目需要重启系统。
•Enqueue Waits
入队等待(enqueue)类似于锁，它们都是控制资源访问的内部机制。较高的入队等待指出大量的会话lE在等待其他会话持有的锁。可査询动态性能视图V$ENQUEUE_STAT査看哪些队列需要的等待时间最多。可使用V$ENQUEUE_STAT视图的cum_wait_time列来完成该工作。
请注意，使用本地管理的表店间消除了几种入队等待，如空事务(ST)入队等待。在有大量并发用户的系统中，最常见的入队等待是由于事务不常提交(或回滚)，使其他事务等待前面事务持有的锁而引起的。此外，可能存在有用的事务列表(ITL)槽太少的问题，这也显示为事务(TX)入队等待。本地管理的表空间能避免最常见的与空间有关的入队等待。
•Latch Free
闩是一种内部串行化机制，用来保护SGA中的共享数据结构。可将闩视为一种在极短时间内持有的锁。Oracle有几种类型的闩，每种类型保护对一组特定的数据的访问。在进程第一次尝试但不能取得闩时，闩空闲等待事件(latch free wait event)増加。
如果得不到闩，则请求它的进程保持循环并再次试图对其进行访问。这种循环增加了系统中的等待时间和CPU的使用。Oracle使用大约500个闩，但显示在等待统计数据中的两种最重要闩是shared pool latch (和库髙速缓存闩)和cache buffers LRU
chain,在实例中看到大量的闩空闲等待事件是很正常的。但如果这种事件所耗费的总时间很高时就应该注意了。
AWR报表中将显示髙闩等待，或者可以使用代码清单20-17所示的査询来获取闩命中率。
select
a.name
"Latch Name",
a.gets
"Gets (Wait)",
a.misses
"Misses (Wait)",
(1 -
(misses / gets)) * 100 "Latch Hit Ratio%"
from v$latch a
where a.gets != 0
union
select
a.name
"Latch Name",
a.gets
"Gets (Wait)",
a.misses
"Misses (Wait)",
100
"Latch Hit Ratio"
from v$latch a
where a.gets = 0
order by 1;
如果命中率不接近1，则应该调整实例中的闩争用。数据库只有一个共享池闩，它保护库高速缓存中内存的分配。库高速缓存闩控制出现在库高速缓存中的对象的访问。任何SQL语句、PL/SQL代码、过程、函数或程序包在执行前都需要获得这个闩。如果共享池和库高速缓存中闩命中率很高，通常是因为数据库中分析率很高。高分析率通常由以下因素引起：
Ø 共享池太小;
Ø 不能使用绑定变量;
Ø 使用不同的SQL语句，不能重用语句;
Ø 用户经常登录和退出应用;
Ø 不能保证每次执行后游标打开;
Ø 使用过大的共享池尺寸。
cache buffers LRU chain闩空闲等待是由高缓冲区高速缓存吞吐导致的，也可能是由全表扫描或是使用了无选择性的索引所引起，后者导致较大的索引扫描。无选择性索引也可能会导致另一种类型的闩空闲等待：cache buffer chain闩空闲等待。这些等待通常是由于出现热点块，因此需要研究出现这种情况的原因。如果看到较高的行高速缓存对象闩等待，表示存在字典高速缓存争用，需要增加共享池内存。
在多数实例中，闩等待容易显示为一个等待事件，DBA有时会在这些事件出现时，从等待事件列表中得到警告。与其他Oracle等待事件一样，我们应该问自己这样一个问题：“这些闩等待占总等待时间的很大比例吗？”如果答案是否定的，则无需担心，我们的目标不是消除实例中的所有等待，因为这做不到。
•Log Buffer Space
log buffer space等待事件表示某个进程等待日志缓冲区中的空间。不管是日志缓冲区太小还是重做信息写得过快，均使日志写入进程不能将其写到重做H志缓冲区。如果重做日志缓冲区已经很大，则需要研究保存重做日志文件的磁盘的I/O。
该磁盘可能存在争用，需要尽量减少I/O争用。这种类型的等待通常在日志缓冲区太小的时候出现，在这种情况下，需要増加日志缓冲区的尺寸。较大的日志缓冲区一般能降低重做日志I/O。请注意，这个参数的默认值可能高达几兆。如果有大量的超大事务，应该增加LOG_BUFFER初始化参数的值，不过太髙的值意味着不得不一次将大量的数据写到重做日志文件。
•Log File Switch
log file switch等待事件发生在由于日志文件一直没有归档而迫使一个会话等待日志文件切换的
时候。这类等待事件也可能由于日志文件切换正等待某个检査点的完成引发的。
如果问题不是由归档目标满所引起，则表示归档进程不能与重做日志归档的速度同步。在此情况下，需要增加归档进程(ARCn)的数目，以跟上归档工作的速度。ARCn的默认值为2。这是一个静 态参数，使用它不能立即解决速度下降问题。
还需要研究重做日志文件太小是否导致日志文件切换等待。如果日志切换被阻止，挂起了一个检查点的完成，显然是日志文件太小，从而很快被填满。在这种情况下，需要增加重做日志文件的尺寸。Oracle可联机添加和删除重做日志文件，可以考虑使用这种动态更改特性。
如果在V$SYSSTAT中看到很高的redo log space requests值，表示用户进程正等待重做日志缓冲区空间。这是由于H志写入进程找不到可用的重做日志文件来腾空日志缓冲区的内容。请重新设置重做日志的尺寸，目的是每15-30分钟进行一次日志切换。
•Log File Sync
如果服务器进程经常等待日志写进程完成从日志缓冲区到重做日志文件的写提交事务(重做)，则你将会在log file sync类中下看到大量的等待。这一般是过于频繁提交的结果，可采用批量提交而不是在每个事务后单个提交来减少这类等待事件。这类等待事件也可能由I/O瓶颈所引起。
•Idle Events
可对idle events类中的某些等待事件进行分组。它们中有一些只是指出Oracle进程正等待做某事，从某种意义上来说，它们可能是无害的。但它们不指出数据库瓶颈或Oracle资源争用。例如，系统可能等待客户机进程提供要执行的SQL语句。下面的清单给出某些常见的空闲事件。
Ø Rdbms ipc message：由后台进程(如日志写进程和PMON)使用，用于表示此进程空闲。
Ø SMON timer： SMON进程在此事件上的等待。
Ø PMON timer： PMON进程空闲事件。
Ø SQL*Net message form client：用户进程空闲事件。
在实例性能调优中，许多空闲事件应该忽略。但有的事件，如SQL*Net message from client事件，可能表示成用程序没有使用有效的数据库连接策略。在这种情况下，需要研究如何减少这些等待，避免频繁地登录和退出应用程序可以减少这些等待。
