1. CPU time
CPU time其實不是真正的等待事件。是衡量CPU是否瓶頸的一個重要指標。一般來講，一個良好的系統，CPU TIME 應該排在TOP 5 TIME Event的最前面。 當然這也是相對的， 如果不存在顯著的 latch wait 或過高的logical read 等, CPU time 占的比例高才是令人放心的。 也就是說CPU在高效率干活是好事，但是是否因為低效的設置或SQL而消耗CPU時間就需要注意了。
- NUM_CPU_SOCKETS 物理CPU的數目
- NUM_CPU_CORES CPU的核數
- NUM_CPUS 邏輯CPU的數目
2. Buffer busy waits (buffer busy wait / read by other session)
一個SESSION需要訪問BUFFER CACHE中的一個數據庫塊而又不能訪問時發生的一種latch等待(Buffer Cache的Latch競爭)。緩沖區“busy”的兩個原因是：
- 另一個SESSION正在將數據塊讀進BUFFER。--- read by other session 等待，一般來說本質上還是buffer cache過小或低效的SQL造成的；
- 另一個SESSION正在以排它模式占用着這塊被請求的BUFFER。---常見原因是數據庫中存在熱塊，一般來說無法通過提高硬件配置解決，可以在“Segments by Buffer Busy Waits”一節中找出發生這種等待的SEGMENT，然后通過使用reverse-key indexes並對熱表進行分區而減少這種等待事件，也可以嘗試考慮降低數據密度，修改表設計或者業務邏輯，讓修改分散，提高並發性。
Latch是用來保護SGA中的內存結構。Latch保證對共享數據結構的排它性訪問，以此來保證內存結構的完整性不受到損壞。在多個會話同時修改或者檢視(inspect)SGA中同一個內存結構時，必須串行化訪問以保證SGA中數據結構的完整性。 對數據庫中對象的保護，使用的lock而不是latch。Buffer Cache的Latch競爭經常是由於熱點塊競爭或低效的SQL語句引起； Shared Pool的Latch競爭通常是由於SQL的硬解析引起。
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操作。