Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time 361 54.14
log file sync 74,324 101 15.22
enqueue 729 88 13.28
db file sequential read 7,303 65 9.76
SQL*Net message from dblink 482 20 3.05
/* oracle等待事件是衡量oracle運行狀況的重要依據及指示，等待事件分爲兩類：空閒等待事件和非空閒等待事件, TIMED_STATISTICS = TRUE 那麼等待事件按等待的時間排序，= FALSE那麼事件按等待的數量排序。運行statspack期間必須session上設置TIMED_STATISTICS = TRUE。空閒等待事件是oracle正等待某種工作，在診斷和優化數據庫時候，不用過多注意這部分事件，非空閒等待事件專門針對oracle的活動，指數據庫任務或應用程序運行過程中發生的等待，這些等待事件是我們在調整數據庫應該關注的。
對於常見的等待事件，說明如下：
1) 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 秒的)運行的事物，可能很多是全表掃描操作(不管怎樣，這部分信息都是值得我們注意的)。
2) db file sequential read：該事件說明在單個數據塊上大量等待，該值過高通常是由於表間連接順序很糟糕（沒有正確選擇驅動行源），或者使用了非選擇性索引。通過將這種等待與statspack報表中已知其它問題聯繫起來(如效率不高的sql),通過檢查確保索引掃描是必須的，並確保多表連接的連接順序來調整。
3) buffer busy wait：當緩衝區以一種非共享方式或者如正在被讀入到緩衝時,就會出現該等待。該值不應該大於1%。當出現等待問題時，可以檢查緩衝等待統計部分(或V$WAITSTAT)，確定該等待發生在什麼位置：
a) 如果等待是否位於段頭(Segment Header)。這種情況表明段中的空閒列表（freelist）的塊比較少。可以考慮增加空閒列表(freelist，對於Oracle8i DMT)或者增加freelist groups(在很多時候這個調整是立竿見影的(alter table sp_item strorage(freelists 2))，在8.1.6之前，這個freelists參數不能動態修改;在8.1.6及以後版本，動態修改feelists需要設置COMPATIBLE至少爲8.1.6)。也可以增加PCTUSED與PCTFREE之間距離（PCTUSED-to-pctfree gap），其實就是說降低PCTUSED的值，儘快使返回freelist列表被重用。如果支持自動段空間管理（ASSM），也可以使用ASSM模式。
b) 如果這一等待位於undo header，可以通過增加回滾段(rollback segment)來解決緩衝區的問題。
c) 如果等待位於undo block上，我們需要增加提交的頻率；使用更大的回滾段，降低一致讀所選擇的表中數據的密度；增大DB_CACHE_SIZE。
d) 如果等待處於data block，表明出現了hot block，可以考慮如下方法解決： ①將頻繁併發訪問的表或數據移到另一數據塊或者進行更大範圍的分佈(可以增大pctfree值，擴大數據分佈，減少競爭)，以避開這個"熱點"數據塊。②也可以減小數據塊的大小，從而減少一個數據塊中的數據行數，降低數據塊的熱度，減小競爭；③檢查對這些熱塊操作的SQL語句，優化語句。④增加hot block上的initrans值。但注意不要把initrans值設置的過於高了，通常設置爲5就足夠了。因爲增加事務意味着要增加ITL事務槽，而每個ITL事務槽將佔用數據塊中24個字節長度。默認情況下，每個數據塊或者索引塊中是ITL槽是2個，在增加initrans的時候，可以考慮增大數據塊所在的表的PCTFREE值，這樣Oracle會利用PCTFREE部分的空間增加ITL slot數量，最大達到maxtrans指定。
e) 如果等待處於index block，應該考慮重建索引、分割索引或使用反向鍵索引。爲了防止與數據塊相關的緩衝忙等待，也可以使用較小的塊，在這種情況下，單個塊中的記錄就較少，所以這個塊就不是那麼"繁忙"。或者可以設置更大的PCTFREE,使數據擴大物理分佈，減少記錄間的熱點競爭。在執行DML (insert/update/ delete)時，Oracle向數據塊中寫入信息，對於多事務併發訪問的數據表，關於ITL的競爭和等待可能出現，爲了減少這個等待，可以增加initrans，使用多個ITL槽。在Oracle9i 中，引入了一個新概念:ASSM(Segment Space Management Auto)。通過這個新特性Oracle 使用位圖來管理空間使用。
4) latch free：當閂鎖丟失率高於0.5%時，需要調整這個問題。詳細的我們在後面的Latch Activity for DB部分說明。
5) Enqueue 隊列是一種鎖，保護一些共享資源，防止併發的DML操作。隊列採用FIFO策略，注意latch並不是採用的FIFO機制。比較常見的有3種類型的隊列：ST隊列，HW隊列，TX4隊列。
ST Enqueue的等待主要是在字典管理的表空間中進行空間管理和分配時產生的。解決方法：1）將字典管理的表空間改爲本地管理模式 2）預先分配分區或者將有問題的字典管理的表空間的next extent設置大一些。
HW Enqueue是用於segment的HWM的。當出現這種等待的時候，可以通過手工分配etents來解決。
TX4 Enqueue等待是最常見的等待情況。通常有3種情況會造成這種類型的等待：1）唯一索引中的重複索引。解決方法：commit或者rollback以釋放隊列。 2）對同一個位圖索引段（bitmap index fragment）有多個update，因爲一個bitmap index fragment可能包含了多個rowid，所以當多個用戶更新時，可能一個用戶會鎖定該段，從而造成等待。解決方法同上。3）有多個用戶同時對一個數據塊作update，當然這些DML操作可能是針對這個數據塊的不同的行，如果此時沒有空閒的ITL槽，就會產生一個block-level鎖。解決方法：增大表的initrans值使創建更多的ITL槽；或者增大表的pctfree值，這樣oracle可以根據需要在pctfree的空間創建更多的ITL槽；使用smaller
block size，這樣每個塊中包含行就比較少，可以減小衝突發生的機會。
6) Free Buffer：這個等待事件表明系統正在等待內存中的可用空間，這說明當前Buffer 中已經沒有Free 的內存空間。如果應用設計良好，SQL 書寫規範，充分綁定變量，那這種等待可能說明Buffer Cache 設置的偏小，你可能需要增大DB_BUFFER_CACHE。該等待也可能說明DBWR 的寫出速度不夠，或者磁盤存在嚴重的競爭，可以需要考慮增加檢查點、使用更多的DBWR 進程，或者增加物理磁盤的數量,分散負載，平衡IO。
7) Log file single write：該事件僅與寫日誌文件頭塊相關，通常發生在增加新的組成員和增進序列號時。頭塊寫單個進行，因爲頭塊的部分信息是文件號，每個文件不同。更新日誌文件頭這個操作在後臺完成，一般很少出現等待，無需太多關注。
8) 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的數據文件位於不同的磁盤中。
9) log buffer space：日誌緩衝區寫的速度快於LGWR寫REDOFILE的速度,可以增大日誌文件大小，增加日誌緩衝區的大小，或者使用更快的磁盤來寫數據。
10) logfile switch：通常是因爲歸檔速度不夠快。表示所有的提交(commit)的請求都需要等待"日誌文件切換"的完成。Log file Switch 主要包含兩個子事件:
log file switch (archiving needed) 這個等待事件出現時通常是因爲日誌組循環寫滿以後，第一個日誌歸檔尚未完成，出現該等待。出現該等待，可能表示io 存在問題。解決辦法:①可以考慮增大日誌文件和增加日誌組；②移動歸檔文件到快速磁盤；③調整log_archive_max_processes。
log file switch (checkpoint incomplete) 當日志組都寫完以後，LGWR 試圖寫第一個log file，如果這時數據庫沒有完成寫出記錄在第一個log file 中的dirty 塊時(例如第一個檢查點未完成)，該等待事件出現。該等待事件通常表示你的DBWR 寫出速度太慢或者IO 存在問題。爲解決該問題，你可能需要考慮增加額外的DBWR 或者增加你的日誌組或日誌文件大小。
11) log file sync：當一個用戶提交或回滾數據時，LGWR將會話得重做操作從日誌緩衝區填充到日誌文件中，用戶的進程必須等待這個填充工作完成。在每次提交時都出現，如果這個等待事件影響到數據庫性能，那麼就需要修改應用程序的提交頻率, 爲減少這個等待事件，須一次提交更多記錄，或者將重做日誌REDO LOG 文件訪在不同的物理磁盤上。
12) DB File Parallel Write：改善IO性能
13) Direct Path Read：一般直接路徑讀取是指將數據塊直接讀入PGA中。一般用於排序、並行查詢和read ahead操作。這個等待可能是由於I/O造成的。使用異步I/O模式或者限制排序在磁盤上，可能會降低這裏的等待時間。
14) direct path write：直接路徑寫該等待發生在，系統等待確認所有未完成的異步I/O 都已寫入磁盤。對於這一寫入等待，我們應該找到I/O 操作最爲頻繁的數據文件(如果有過多的排序操作，很有可能就是臨時文件)，分散負載，加快其寫入操作。如果系統存在過多的磁盤排序，會導致臨時表空間操作頻繁，對於這種情況，可以考慮使用Local管理表空間，分成多個小文件，寫入不同磁盤或者裸設備。
15) control file parallel write：當server 進程更新所有控制文件時，這個事件可能出現。如果等待很短，可以不用考慮。如果等待時間較長，檢查存放控制文件的物理磁盤I/O 是否存在瓶頸。
多個控制文件是完全相同的拷貝，用於鏡像以提高安全性。對於業務系統，多個控制文件應該存放在不同的磁盤上，一般來說三個是足夠的，如果只有兩個物理硬盤，那麼兩個控制文件也是可以接受的。在同一個磁盤上保存多個控制文件是不具備實際意義的。減少這個等待，可以考慮如下方法:①減少控制文件的個數(在確保安全的前提下)。②如果系統支持，使用異步IO。③轉移控制文件到IO 負擔輕的物理磁盤。
16) control file sequential read
control file single write ：控制文件連續讀/控制文件單個寫對單個控制文件I/O 存在問題時，這兩個事件會出現。如果等待比較明顯，檢查單個控制文件，看存放位置是否存在I/O 瓶頸。
常見的一些IDLE wait事件舉例：
dispatcher timer
lock element cleanup
Null event
parallel query dequeue wait
parallel query idle wait - Slaves
pipe get
PL/SQL lock timer
pmon timer- pmon
rdbms ipc message
slave wait
smon timer
SQL*Net break/reset to client
SQL*Net message from client
SQL*Net message to client
SQL*Net more data to client
virtual circuit status
client message
SQL*Net message from client