等待事件分析：在Oracle 10g中的等待事件有872個，11g中等待事件1116個。 我們可以通過v$event_name 視圖來查看等待事件的相關信息。
1.1 查看v$event_name視圖的字段結構：
SQL> desc v$event_name
Name
---------------------------
EVENT#
EVENT_ID
NAME
PARAMETER1
PARAMETER2
PARAMETER3
WAIT_CLASS_ID
WAIT_CLASS#
WAIT_CLASS
1.2 查看等待事件總數：
SQL> select count(*) from v$event_name;
COUNT(*)
----------
1118
1.3 查看等待事件分類情況：
SQL> SELECT wait_class#,
2 wait_class_id,
3 wait_class,
4 COUNT ( * ) AS "count"
5 FROM v$event_name
6 GROUP BY wait_class#, wait_class_id, wait_class
7 ORDER BY wait_class#;
WAIT_CLASS# WAIT_CLASS_ID WAIT_CLASS count
----------- ------------- ---------------------------------------------------------------- ----------
0 1893977003 Other 719
1 4217450380 Application 17
2 3290255840 Configuration 24
3 4166625743 Administrative 54
4 3875070507 Concurrency 32
5 3386400367 Commit 2
6 2723168908 Idle 94
7 2000153315 Network 35
8 1740759767 User I/O 45
9 4108307767 System I/O 30
10 2396326234 Scheduler 7
WAIT_CLASS# WAIT_CLASS_ID WAIT_CLASS count
----------- ------------- ---------------------------------------------------------------- ----------
11 3871361733 Cluster 50
12 644977587 Queueing 9
13 rows selected.
1.4 相關的幾個視圖：
V$SQLTEXT： 當數據庫出現瓶頸時，通常可以從V$SESSION_WAIT找到那些正在等待資源的SESSION，通過SESSION的SID，聯合V$SESSION和V$SQLTEXT視圖就可以捕獲這些SESSION正在執行的SQL語句。 (SQL層等待分析)
V$SESSION： 代表數據庫活動的開始，視為源起。
V$SESSION_WAIT： 視圖用以實時記錄活動SESSION的等待情況，是當前信息。 (會話層等待分析)
如： select event,total_waits from v$session_event where sid=### order by total_waits desc;
V$SYSTEM_EVENT 由于V$SESSION記錄的是動態信息，和SESSION的生命周期相關，而并不記錄歷史信息，所以ORACLE提供視圖V$SYSTEM_EVENT來記錄數據庫自啟動以來所有等待事件的匯總信息。通過這個視圖，用戶可以迅速獲得數據庫運行的總體概況。 (系統層等待分析)
如： select event,total_waits from v$system_event order by total_waits desc;
V$SESSION_WAIT_HISTORY： 是對V$SESSION_WAIT的簡單增強，記錄活動SESSION的最近10次等待。
V$ACTIVE_SESSION_HISTORY: 是ASH的核心，用以記錄活動SESSION的歷史等待信息，每秒采樣一次，這部分內容記錄在內存中，期望值是記錄一個小時的內容。
WRH#_ACTIVE_SESSION_HISTORY : 是V$ACTIVE_SESSION_HISTORY在AWR的存儲地。
V$ACTIVE_SESSION_HISTORY: 中的信息會被定期(每小時一次)的刷新到負載庫中，并缺省保留一個星期用于分析。
DBA_HIST_ACTIVE_SESS_HISTORY: 視圖是WRH#_ACTIVE_SESSION_HISTORY視圖和其他幾個視圖的聯合展現，通常通過這個視圖進行歷史數據的訪問。
1.5 常見的等待事件
1.5.1 db file scattered read
產生原因：
當PGA中無所需數據，數據塊以multiblock read的行式被讀取到SGA中時。如：FTS(full table scan)，IFFS(index fast full scan)
解決對策：
無需解決、考慮索引、考慮并行
1.5.2 DB File Sequential Read (單塊讀等待)
背景知識：
這里的sequential指的是將數據塊讀入到相連的內存空間中(contiguous memory space)，而不是指所讀取的數據塊是連續的。
產生原因：
a: 最為常見的是執行計劃中包含了INDEX FULL SCAN/UNIQUE SCAN,此時出現”db file sequential read”等待是預料之中的，一般不需要我們去特別關注
b: 當執行計劃包含了INDEX RANGE SCAN-(“TABLE ACCESS BY INDEX ROWID”/”DELETE”/”UPDATE”)， 服務進程將按照”訪問索引->找到rowid->訪問rowid指定的表數據塊并執行必要的操作”順序訪問index和table，每次物理 讀取都會進入”db file sequential read”等待，且每次讀取的都是一個數據塊;這種情況下clustering_factor將發揮其作用，需要我們特別去關注，本例中提及的解決方法對 這種情景也有效
c: Extent boundary,假設一個Extent區間中有33個數據塊，而一次”db file scattered read”多塊讀所讀取的塊數為8，那么在讀取這個區間時經過4次多塊讀取后，還剩下一個數據塊，但是請記住多塊讀scattered read是不能跨越一個區間的(span an extent)，此時就會單塊讀取并出現”db file sequential read”。這是一種正常現象，一般不需要額外關注
d: 假設某個區間內有8個數據塊，它們可以是塊a,b,c,d,e,f,g,h，恰好當前系統中除了d塊外的其他數據塊都已經被緩存在buffer cache中了，而這時候恰好要訪問這個區間中的數據，那么此時就會單塊讀取d這個數據塊，并出現”db file sequential read”等待。注意這種情況不僅于表，也可能發生在索引上。這是一種正常現象，一般不需要額外關注
e: chained/migrated rows即鏈式或遷移行，這里我們不介紹鏈式行的形成原因，chained/migrated rows會造成服務進程在fetch一行記錄時需要額外地單塊讀取，從而出現”db file sequential read”。這種現象需要我們特別去關注，因為大量的鏈式/遷移行將導致如FULL SCAN等操作極度惡化(以往的經驗是一張本來全表掃描只需要30分鐘的表，在出現大量鏈式行后，全表掃描需要數個小時)，同時也會對其他操作造成不那么 明顯的性能影響。可以通過監控v$sysstat視圖中的”table fetch continued row”操作統計來了解系統中鏈式/遷移行訪問的情況，還可以通過DBA_TBALES視圖中的CHAIN_CNT來了解表上的鏈式/遷移行情況，當然這 要求定期收集表上的統計信息;如果沒有定期收集的習慣，那么可以配合@?/rdbms/admin/utlchain腳本和analyze table list chained rows 命令來獲取必要的鏈式行信息
f: 創建Index entry，顯然當對表上執行INSERT操作插入數據時，雖然在執行計劃中你看不到過多的細節，但實際上我們需要利用索引來快速驗證表上的某些約束是否 合理，還需要在索引的葉子塊中插入相關的記錄，此時也可能出現”db file sequential read”等待事件，當然這還和具體的插入的方式有關系。這是一種正常現象，一般不需要額外關注
1.5.3 Direct Path Read
產生原因：
數據被直接讀取到PGA內存中時，發生的等待。如：排序數據由于內存不足，被寫到磁盤上(temp表空間數據文件)，然后重新讀取時。
解決辦法：
無需解決、增大內存排序區(PGA)、調整操作的并行度、改善磁盤I/O、
1.5.4 Direct Path write
產生原因：
數據從PGA內存中直接寫到磁盤上，發生的等待。 如：排序數據由于內存不足，被寫到磁盤上(temp表空間數據文件)
1.5.5 Log File Sync
產生原因：
用戶commit(rollback)時，lgwr需要將log buffer的數據寫到log file上面，發生的等待。
解決本法：
減少commit的頻率(錯誤的頻繁提交)、提高I/O性能、增加lgwr進程個數
1.5.6 buffer busy waits (熱快)
產生原因：
在SGA中讀取或修改緩沖區的會話必須首先獲取cache buffers chains鎖存器，并且遍歷這個緩沖區鏈，直到他發現必需的緩沖區頭。然后，他必須以共享模式或獨占模式獲取一個緩沖區鎖或緩沖區頭上的pin，這取決于他計劃的操作。一旦緩沖區頭被釘住，會話就釋放cache buffers chains鎖存器，并在緩沖區自身上執行計劃的操作。如果無法獲取一個pin，會話就在buffer busy waits等待事件上等待。這種等待時間不會應用于在會話的私有PGA中執行的讀取或寫入操作。
解決辦法：
1、出現此情況通常可能通過幾種方式調整：增大data buffer;
2、增加freelist，減小pctused;怎樣的目的是將一個block上可以使用的空間減少，這樣的話：一個block上的數據存放的較少，可以提高應用的訪問并發率，減少hot block的產生;
3、增加回滾段數目，增大initrans，考慮使用LMT, 確認是不是由于熱點塊造成(如果是可以用反轉索引,或者用更小塊大小);
3、可以建立block較小的表空間，見熱點對象移動到此表空間上去;
4、優化應用，優化索引，提高索引的命中率;
◎ Oracle會話正在等待釘住一個緩沖區。必須在讀取或修改緩沖區前將它釘住。在任何時刻只有一個進程可以釘住一個緩沖區。
◎ buffer busy waits表明讀/讀、讀/寫、寫/寫爭用。
◎ 采取的適當措施取決于P3參數中的原因碼。
A、如果等待處于字段頭部，應增加自由列表(freelist)的組數，或者增加pctused到pctfree之間的距離。
B、如果等待處于回退段(undo)頭部塊，可以通過增加回滾段(rollback segment)來解決緩沖區的問題;
C、如果等待處于回退段(undo)非頭部塊上，就需要降低驅動一致讀取的表中的數據密度,或者增大DB_CACHE_SIZE;
D、如果等待處于數據塊，可以將數據移到另一數據塊以避開這個"熱"數據塊、增加表中的自由列表或使用LMT表空間;
E、如果等待處于索引塊，應該重建索引、分割索引或使用反向鍵索引。
1.5.7 free buffer waits
產生原因：
server process無法找一個可用的內存空間。
(系統I/O成為瓶頸(或者性能不夠)、等待資源 latch爭用、SGA太小、SGA太大，dbwr無法快速的把臟數據刷到磁盤上)
解決辦法：
優化I/O、增加多個dbwr 進程、增大SGA
看文倉www.kanwencang.com網友整理上傳,為您提供最全的知識大全,期待您的分享，轉載請注明出處。
歡迎轉載：http://www.kanwencang.com/bangong/20170104/81429.html
文章列表
留言列表
