等待事件  oracle7 開始引入

v$event_name 記錄當前資料庫支援的等待事件及其基本資訊

desc v$event_name

p1  p2  p3  不同等待事件引數其意義不同

wait_class（等待事件分類）

空閒等待     非空閒等待（調整資料庫的時候需要研究的）

v$system_wait_class  檢視顯示各類主要等待事件的等待時間和等待次數等資訊。分類統計。

V$SESSION   檢視記錄的是資料庫當前連線的Session資訊。
V$SESSION_WAIT   檢視記錄的是當前資料庫連線的活動Session正在等待的資源或
事件資訊。
V$SYSTEM_EVENT  

由於V$SESSION記錄的是動態資訊，和 Session 的生命週期相關，並不記錄歷史信
息， 所以 Oracle ᨀ供另外一個檢視 V$SYSTEM_EVENT 來記錄資料庫自啟動以來所有等待事
件的彙總資訊。 通過 V$SYSTEM_EVENT 檢視， 可以迅速地獲得資料庫執行的總體概況。

10g 開始 v$session_wait整合到v$session 中。還增加了blocking_session欄位。10gR2又增加了sql_trace相關資訊。

11gR1又增加了sql_exec_start  sql_exec_id  prev_exec_start  prev_exec_id等欄位

v$session_event  同一會話在其整個週期等待事件的累積，因為v$session，v$session_wait都是動態變化的。和會話的生命週期相關。

v$system_event  資料庫整體等待資訊的累積。

v$event_histogram  同一等待事件，不同等待時長的柱狀分佈圖。比如shared pool latch 10毫秒以內的等待有幾次，200毫秒以上的等待有幾次。

oracle 11g 實時sql監控   （通過在v$session中增加sql_exec_start等欄位實現）

11g之前，某個操作超過6s，會被記錄在v$session_longops檢視中

11g開始，超過5s的CPU或者IO等操作，會被記錄在v$sql_monitor檢視中，還包含一些sql執行的統計資訊，如buffer gets等。結合v$sql_plan_monitor檢視可以進一步查詢sql的執行計劃等資訊。每秒重新整理一次，接近實時。sql執行完畢，資訊不會被立即刪除，而是會在這兩個檢視中保留1分鐘。

根據session id獲取當前session正在執行的sql語句：

SELECT sql_text FROM v$sqltext a
WHERE a.hash_value = (SELECT sql_hash_value FROM v$session b WHERE b.SID = '&sid')
ORDER BY piece ASC;

v$session_wait_history  記錄session最近10次等待事件。可以檢視該session過去某個時間所經歷的等待事件，解決了現象消失後，無法獲取發生問題時系統正在經歷那些等待的問題。追溯。不是累積。 10g開始ASH  v$active_session_history 以v$session為基礎，每秒取樣一次，記錄活動session等待資訊，不活動的會話不記錄。由10g新引入的後臺程序MMNL完成。 ASH資訊儲存在shared pool記憶體中，存滿了，需要的時候可以被覆蓋。 oracle提供的ASH報告工具，可以以幾分鐘或者幾小時或者幾天為跨度，對資料庫提供概要分析。 記憶體中記錄的ASH的資訊畢竟是有限的，為了儲存歷史資料，這些資料最終要寫入磁碟。這些資訊就是AWR資訊。 oracle以固定的時間間隔（預設每小時一次）為其所有重要的統計資訊和負載資訊執行一次快照，並將這些資訊儲存在AWR中。這些資訊在AWR中保留給定的時間（預設為一週），然後被清除。AWR取樣工作由後臺程序MMON每60分鐘執行一次。ASH資訊同樣會被取樣寫出到AWR負載庫。 雖然ASH buffers 被設計為保留 1 小時的資訊，但是很多時候這個記憶體是不足夠的，當ASH buffers 寫滿之後，另外一個後臺程序 MMNL 將會主動將 ASH 資訊寫出。 由於資料量巨大， 把所有的 ASH 資料寫到磁碟上是不可接受的。一般是在寫到磁碟的時候過濾這個資料，寫出的資料佔取樣資料的10%，寫出時通過direct-path insert 完成，儘量減少日誌生成，從而最小化資料庫效能影響。

AWR報告  $ORACLE_HOME/rdbms/admin/awrrpt.sql AWR比較報告   $ORACLE_HOME/rdbms/admin/awrddrpt.sql AWR資訊的匯入匯出   awrextr.sql   awrload.sql oracle 10g   ADDM db file sequential read(資料檔案順序讀取)，與單個數據塊相關的讀取操作。大多數情況下是讀取一個索引塊或者通過索引讀取一個數據塊。 如果此等待事件比較顯著，可能是在多表連線中，表的連線順序存在問題，驅動表選擇錯誤。或者使用索引並非總是最好的選擇。 但是在一個編碼規範，調整良好的資料庫中，這個等待事件很大通常是正常的。——————定期的資料整理和空間回收是必須的。 db file scattered read  離散讀，將儲存上連續的資料塊離散的讀取到多個不連續的記憶體位置（併發，效能考慮），通常是多塊讀。  DB_FILE_MULTIBLOCK_COUNT 應用問題，或者索引缺失。 direct path read/write 直接路徑讀寫。直接路徑讀通常發生在oracle直接讀資料到程序PGA，而不經過SGA。通常是磁碟排序IO，在DSS系統中常見，OLTP中意味著應用有問題。   直接路徑寫通常發生在直接從PGA寫資料到資料檔案或臨時檔案，繞過SGA。直接路徑載入，並行DML，磁碟排序等。 存在過多的磁碟排序，會導致臨時表空間操作頻繁。 重要效能指標：記憶體排序率  in-memory-sort ratio  = sort(memory）/ sort(disk) + sort(memory) 9i之前，增加sort_area_size，9i開始，增加P_A_T，避免磁碟排序。同時檢查應用，避免過度排序。 並行操作也會direct path read/write。但並行不一定帶來效能提升。 10g開始  direct path read/write temp 日誌檔案相關等待： log file switch   日誌切換，在此期間所有DML處於停頓狀態，直至切換完成 兩個子事件   log file switch(archiving needed)   歸檔未完成，磁碟IO，log_archive_max_processes。                         log file switch (checkpoint incomplete)髒資料沒寫完，不能覆蓋日誌檔案，DBWR。 log file sync 使用者提交或回滾資料，LGWR將重做由緩衝寫入重做日誌的過程。LGWR寫出太慢，或者提交過於頻繁（LGWR過度啟用，系統產生redo很多，但每次寫的較少）。 log file single write 寫日誌檔案頭塊相關，通常發生在日誌切換或增加新的組成員期間。 log file parallel write 從log buffer寫redo到日誌檔案，主要指常規操作（相對於log file sync的commit操作）。 log buffer space 資料庫產生日誌的速度比LGWR的寫出速度快，或者日誌切換慢發生等待。通常表明log buffer設定過小，考慮增大buffer大小或者增加日誌檔案大小。或者磁碟IO出問題。 enqueue（佇列等待） 一種保護共享資源的鎖定機制。排隊機制，FIFO。 10g之前，是一組鎖定事件的集合。 10g之後，對於佇列等待進行了細分。 oracle的鎖按型別可以分為排它鎖（X)和共享鎖（S）。 oracle通過enqueue等待來記錄鎖定，通過latch free等待事件來記錄閂。 最重要，最常見的鎖定：TM  、  TX TX：事務鎖，在行級獲得。每行都存在一個鎖定為（lb-Lock Byte） ，用於判斷該記錄是否被鎖定，同時在資料塊的頭部存在一個稱為ITL的結構，用於記錄事務等資訊。只有排他模式，沒有共享模式。 TM：表級鎖，可以通過手工發出lock命令獲得，或者通過DML操作以及select for update獲得，表級鎖可以防止其他程序對錶加X排他鎖，防止在對資料修改時，其他任務通過DDL來修改表結構或者執行truncate、drop等操作。 當執行DML操作室，首先加TM鎖，如果能獲得鎖定，則繼續加TX事務鎖。 最常見的鎖定：MR與AE MR：介質恢復鎖（media recovery），使用者保護資料庫檔案，使得檔案在資料庫開啟，表空間online時不能執行恢復。 AE：11g開始，每個登入資料庫的會話都會獲得一個AE鎖。 ST：空間事務鎖，用於空間管理和字典管理的表空間的區間分配。 latch free（閂鎖釋放）： 低階排隊機制（序列），用於保護SGA中共享記憶體結構。快速獲取釋放的記憶體鎖，用於防止共享記憶體被多個使用者同時訪問。 v$latch  檢視記錄不同型別latch統計資訊 按獲取和等待方式不同進行分類：willing-to-wait （願意等待型別）  、     immediate（立即型別） willing-to-wait  ：如果所請求的latch不能立即得到，則等待一段很短時間再請求，一直重複此過程直到獲得latch。
immediate：所請求的latch不能立即得到，程序不再等待，繼續執行下去。
gets  、  misses 、 sleeps、  immediate_gets 、  immediate_misses 獲得         等待           休眠           立即獲得                         立即模式不成功 willing-to-wait （願意等待型別）模式時，如果沒有獲得latch，且系統存在多個CPU，則程序圍繞該latch進行自旋（spin），自旋的過程中，程序會一直持有CPU。如果直接採用sleep的方式，引起的上下文切換會非常昂貴。
immediate型別的latch通常是因為存在多個可用的latch，比如常見的redo copy latch。另外一個原因是latch有level的概念。 10g開始，latch被細分。 10g開始引入mutex機制，來代替傳統的latch機制。更輕量，所需指令數更少，佔用空間更小。使用更少的CPU資源獲得更好的效能。