1. CPU time
- 正常情况，在等待事件中排首位
- NUM_CPU_SOCKETS 物理CPU的数目
- NUM_CPU_CORES CPU的核数
- NUM_CPUS 逻辑CPU的数目
2. Buffer busy waits (Buffer busy wait / read by other session)
- 一般这2个等待事件可以归为一起处理，建议进行监控 。 可能是如下操作引起
- select/select --- read by other session: 由于需要从数据文件中将数据块读入 buffer cache 中引起，有可能是大量的逻辑/物理读; 或者过小的 buffer cache 引起
- select/update --- buffer busy waits / read by other session 由于更新某数据块后，需要在undo中重新构建过去时间的数据块，有可能伴生 enq:cr-contention 是由于大量的物理读/逻辑读造成
- update/update --- buffer busy waits 由于更新同一个数据块（非同一行，同一行是enq:TX-contention） 此类问题是热点块造成
- insert/insert --- buffer busy waits 由于freelist 争用造成，可以将表空间更改为ASSM管理，或者加大freelist
3. SQL*Net message from client 等等
这个等待事件基本上是最常见的一个等待事件。 当一个会话建立成功后，客户端会向服务器端发送请求，服务器端处理完客户端请求后，将结果返回给客户端，并继续等待客户端的请求，这时候会产生SQL*Net message from client 等待事件。
很显然，这是一个空闲等待，如果客户端不再向服务器端发送请求，服务器端将一直处于这个等待事件状态。
4. Db file sequential read / Db file scattered read
- 一般在等待事件中排在4、5位，Avg wait time平均单次等待时间应当小于20ms.
- db file sequential read 如果数据库执行索引查找(index block access or table block access by a rowid)，一般都是一个一个数据块读取的，读取的数据块在内存中是以连续的方式存放。db file sequential read 等待事件的P3参数一般都是1。
- db file scattered read 如果数据库执行全表扫描或者是全索引扫描， 一般都是同时读取多个块到内存中(Multi block I/O) ，为了性能和更有效的内存空间利用，oracle一般会把这些块分散在内存中。db file scattered read 等待事件的P3参数指出了每次I/O读取的块数。每次I/O读取多少个块，有参数db_file_multiblock_read_count控制。一般会从应用程序（SQL） 方面入手调整。
5. enq: TX - row lock contention
等待事件enq: TX - row lock contention中的enq是enquence的简写。enquence是协调访问数据库资源的内部锁。所有以“enq:”打头的等待事件都表示这个会话正在等待另一个会话持有的内部锁释放。
它的名称格式是enq:enqueue_type - related_details。这里的enqueue_type是TX，related_details是row lock contention。数据库动态性能视图v￥event_name提供所有以“enq:”开头的等待事件的列表。
虽然在awrrpt中看到大量enq: TX - row lock contention的等待，但这些是事后看到的信息。根据AWRRPT，我们无法只知道该等待事件的请求模式是什么，是6还是4。
如果数据库一出现enq: TX - row lock contention等待，可以去看v￥session和v￥session_wait等性能视图。
enq: TX - row lock contention 的产生有几种情况。
<1>In mode 6 ：A 会话持有row level lock，B会话等待这个lock释放。
不同的session更新或删除同一个记录。（This occurs when one application is updating or deleting a row that another session is also trying to update or delete. ）
解决办法：持有锁的会话commit或者rollback。
<2>In mode 4 : 唯一索引
表上存在唯一索引，A会话插入一个值（未提交），B会话随后也插入同样的值;A会话提交后，enq: TX - row lock contention消失。
解决办法：持有锁的会话commit或者rollback。
<3>in mode 4 : bitmap
源于bitmap的特性：位图索引的一个键值，会指向多行记录，所以更新一行就会把该键值指向的所有行锁定。
解决办法：commit或者rollback。
<4>其他原因
It could be a primary key problem; a trigger firing attempting to insert, delete, or update a row; a problem with initrans; waiting for an index split to complete; problems with bitmap indexes;updating a row already updated by another session; or something else.
6. Log file sync
这是一个用户会话行为导致的等待事件，会话发出的commit指令后，需要等待LGWR将这个事务产生的redo成功写入到磁盘之后，才可以继续进行后续的操作，这个等待事件就叫作log file sync。
如果此类事件频繁发生，可以判断为：
- commit 次数是否过多
- I/O 系统问题
- 重做日志是否不必要被创建
- redo log buffer 是否过大
7. Log file switch(archiving needed / checkpoint incomplete)
在归档模式下，这个等待事件发生在在线日志切换（log file switch）时，需要切换的在线日志还没有被归档进程（ARCH）归档完毕的时候。 当在线日志文件切换到下一个日志时，需要确保下一个日志文件已经被归档进程归档完毕，否则不允许覆盖那个在线日志信息（否则会导致归档日志信息不完整）。出现这样的等待事件通常是由于某种原因导致ARCH 进程死掉，比如ARCH进程尝试向目的地写入一个归档文件，但是没有成功（介质失效或者其他原因），这时ARCH进程就会死掉。 如果发生这种情况，在数据库的alert log文件中可以找到相关的错误信息。
当一个在线日志切换到下一个在线日志时，必须保证要切换到的在线日志上的信息（比如一些脏数据块产生的redo log）被写到磁盘上（checkpoint），这样做的原因是，如果一个在线日志文件的信息被覆盖，而依赖这些redo 信息做恢复的数据块尚未被写到磁盘上（checkpoint），此时系统down掉的话，Oracle将没有办法进行实例恢复。
如果系统中出现大量的log file switch（checkpoint incomplete）等待事件，原因可能是日志文件太小或者日志组太少，所以解决的方法是，增加日志文件的大小或者增加日志组的数量。
8. Library cache lock / Library cache pin
这类等待事件发生在不同用户由于并发操作同一个数据库对象导致资源争用的时候，比如当一个用户正在对一个表做DDL 操作时，其他的用户如果要访问这张表，就会发生library cache lock等待事件，它要一直等到DDL操作完成后，才能继续操作。
Library cache pin 和 Library cache lock 一样是发生在共享池中并发操作引起的事件。通常来讲，如果Oracle 要对一些PL/SQL 或者视图这样的对象做重新编译，需要将这些对象pin到共享池中。 如果此时这个对象被其他的用户特有，就会产生一个library cache pin的等待。
9. Direct path read / Direct path write
这类等待事件发生在会话将数据块直接读取到PGA当中而不是SGA中的情况，这些被读取的数据通常是这个会话私有的数据，所以不需要放到SGA作为共享数据，因为这样做没有意义。 这些数据通常是来自于临时段上的数据，比如一个会话中SQL的排序数据，并行执行过程中间产生的数据，以及Hash Join，merge join产生的排序数据，因为这些数据只对当前的会话的SQL操作有意义，所以不需要放到SGA当中。
当发生direct path read等待事件时，意味着磁盘上有大量的临时数据产生，比如排序，并行执行等操作。 或者意味着PGA中空闲空间不足。
与direct path read 正好相反，Direct path write是会话将一些数据从PGA中直接写入到磁盘文件上，而不经过SGA。这种情况通常发生在：
使用临时表空间排序（内存不足）
数据的直接加载（使用append方式加载数据）
并行DML操作。