wait event監測效能瓶頸

會話等待事件檢視：v$system_event、v$session_event、v$session_wait。
會話等待事件是獨立於應用的，所以它可以作為很好的效能監測工具的基礎依據。任何一個應用具有很高的全表掃描的等待事件都意味著i/o有了問題。

v$system_event
用來檢視整個系統級效能情況，對每個事件總計了從系統啟動以來在所有會話中發生過的情況，這些資訊每次重啟後都會被重新計數。
event：列出了所有發生的事件的名稱。latch waits、db file scattered read、db file sequential read、enqueue wait 、buffer busy wait、log file parallel write、free buffer waits。
total_waits：從資料庫啟動到現在等待事件總的等待次數。
total_timeouts：總的等待超時的次數。
time_waited：總的等待時間，以1%秒為單位。資料庫啟動以來某個等待事件在所有會話中（包括已經結束和正保持 連線的會話）總的等待時間之和。
average_wait：平均等待時間，以1%秒為單位。資料庫啟動以來某個等待事件在所有會話中平均等待時間。

v$session_event
檢視會話級的統計。會話重新建立時資訊將被重置為0。

v$session_wait
包含了當前正處於連線狀態的會話的等待事件，提供了當前已經發生或正在發生的事件的可用資訊。例如：一個正在發生鎖存器競爭的會話，此時正在等待那個鎖存器。或者，一個會話正在等待對一個資料塊的訪問。
sid：會話的id。
seq#：會話的內部順序號。
event：描述事件的名稱。
p[1-3]：提供詳細資訊。
state：提供了wait_time和seconds_in_wait兩個欄位的解釋。

• waiting：會話正在等待這個事件。
• waited unknown time ：由於timed_statistics設定為false，而導致不能得到關於時間的資訊。
• waited short time：表示會話發生了等待，但是等待事件非常小，不超過一個時間單位，所以沒有記錄。
• waited known time：一旦會話等待了資源然後得到了，那麼狀態將從waiting進駐waited known time。

*記住記錄在v$session_event中的等待事件記錄在當前等待的資源沒有等到之前是不會更新的。所以如果一個等待事件等待的事件非常長，那麼將很明顯的看到，在v$session_wait中的統計資訊將持續增加而相應v$session_event中的資訊保持不變。

發現系統變慢時，首先透過v$system_event從系統級進行收集，不僅僅要看累計的系統等待事件資訊，更重要的時一段時間內等待的時間增量。然後透過產看v$session_wait檢視，可以判斷具體問題。例如，如果發生i/o競爭，原因是由於對索引的訪問還是大量的全表掃描等等。如果命中率低，不要著急看看有沒有相關的等待事件，如果沒有就不用擔心。相反，如果命中率很高，卻存在大量的等待，原因有可能資料快取記憶體區過大，超過了實體記憶體的大小，帶來了大量的分頁交換。


帶有函式或者表示式的where語句，欄位上的索引是不會被用到的，會引起全表掃描。

總結：
瞭解應用的需求，確定為什麼要使用to_char函式遮蔽status欄位索引的使用。
調整收集到的sql語句書寫，減少全表掃描的發生，從而減少相應的i/o操作
考慮在索引上使用nologging，減少表中資料維護相應的索引維護產生的重做日誌。
減少重做日誌檔案所在磁碟上無關緊要的i/o操作，如果必要，將重做日誌檔案移動到新的磁碟上。
從長遠考慮，增加重做日誌檔案組的個數和組員檔案的大小以防止其他重做日誌相關的等待事件的發生。