概述：
AWR 全稱叫Automatic Workload Repository（自動負載信息庫）。是Oracle提供的性能收集和分析工具，進行Oracle性能調優的利器。能提供一個時間段內整個系統資源使用情況的報告，通過報告，可以瞭解系統的整個運行情況，就像一個人全面的體檢報告。
Oracle啟動後，後臺會有個進程去每小時採集一次系統的快照信息，AWR通過對比兩次快照(snapshot)收集到的統計信息，來生成報表數據。
信息採集來源為： V$active_Session_History視圖。該視圖可以展示最近活動會話的歷史記錄。並將採集到的信息保存8天。
快照由MMON和MMNL的進程自動地每隔固定時間採集一次。MMON進程負責執行多種和管理相關的後臺任務，MMNL負責執行輕量級且高頻率的管理相關的後臺任務。
1. WORKLOAD REPOSITORY report for
- 這是DB的一些基本信息，DB name，instance name, instance number, DB version以及是否是RAC安裝。
- 此表顯示抓取時間為2020/8/1 8:00:20至9:00:26，共計60.11分鐘。開始sessions（即連接數）是135個，結束是sessions是134個。
- Cursors/Session是指平均每個session open的cursors數量。
- 對於大多數系統，數據庫的工作負載總是集中在一段時間內。如果快照週期不在這一段時間內，或者快照週期跨度太長而包含了大量的數據庫空閒時間，所得出的分析結果是沒有意義的。這也說明選擇分析時間段很關鍵，要選擇能夠代表性能問題的時間段。
- DB TIME：代表了此統計期間的數據庫負載，是所前臺session花費在database調用上的總和時間（包括CPU時間、IO Time、和其他一系列非空閒等待時間）。如果 DB Time 接近於 Elapsed Time*cpu 數,表明數據庫比較忙,cpu 負載也許比較大
- cpu利用率為：DB Time /(Elapsed* NUM_CPUS)=657/(60*160) *100%=6.8%。
2. Load Profile
- 顯示數據庫負載概況，將之與基線數據比較才具有更多的意義，如果每秒或每事務的負載變化不大，說明應用運行比較穩定。單個的報告數據只說明應用的負載情況，絕大多數據並沒有一個所謂"正確"的值，然而Logons大於每Redo size：每秒產生的日誌大小(單位字節)，可標誌數據變更頻率, 數據庫任務的繁重與否。
- Redo size：每秒產生的日誌大小(單位字節)，可標誌數據變更頻率, 數據庫任務的繁重與否。
- Logical reads：每秒/每事務邏輯讀的塊數.平均每秒產生的邏輯讀的block數。
- Logical Reads= Consistent Gets + DB Block Gets
- Block changes：每秒/每事務修改的塊數
- Physical reads：每秒/每事務物理讀的塊數
- Physical writes：每秒/每事務物理寫的塊數
- User calls：每秒/每事務用戶call次數
- Parses：SQL解析的次數.每秒解析次數，包括fast parse，soft parse和hard parse三種數量的綜合。 軟解析每秒超過300次意味著你的"應用程序"效率不高，調整session_cursor_cache。在這裡，fast parse指的是直接在PGA中命中的情況（設置了session_cached_cursors=n）；soft parse是指在shared pool中命中的情形；hard parse則是指都不命中的情況。 Hard parses：其中硬解析的次數，硬解析太多，說明SQL重用率不高。每秒產生的硬解析次數, 每秒超過100次，就可能說明你變量綁定使用的不好，也可能是共享池設置不合理。這時候可以啟用參數cursor_sharing=similar|force，該參數默認值為exact。當該參數設置為similar時，存在bug，可能導致執行計劃的不優。 Sorts：每秒/每事務的排序次數
- Logons：每秒/每事務登錄的次數
- Executes：每秒/每事務SQL執行次數 Transactions：每秒事務數.每秒產生的事務數，反映數據庫任務繁重與否。 Blocks changed per Read：表示邏輯讀用於修改數據塊的比例.在每一次邏輯讀中更改的塊的百分比。 Recursive Call：遞歸調用佔所有操作的比率.遞歸調用的百分比，如果有很多PL/SQL，那麼這個值就會比較高。
- Rollback per transaction：每事務的回滾率.看回滾率是不是很高，因為回滾很耗資源 ,如果回滾率過高,可能說明你的數據庫經歷了太多的無效操作 ,過多的回滾可能還會帶來Undo Block的競爭 該參數計算公式如下: Round(User rollbacks / (user commits + user rollbacks) ,4)* 100% 。
- Rows per Sort：每次排序的行數
3.Instance Efficiency Percentages (Target 100%)
- Buffer Nowait %：session申請一個buffer(兼容模式)在db buffer cache中不等待的次數比例。
- Buffer Hit %：數據塊在數據緩衝區中的命中率，小於90%可能是要加db_cache_size，但這個指標即便99% 也不能說明物理讀等待少了，但是指標小於90%，那肯定是存在大量物理讀
- Library Hit %：申請一個library cache object例如一個SQL cursor時，其已經在library cache中的比例（表示Oracle從Library Cache中檢索到一個解析過的SQL或PL/SQL語句的比率），低的library hit ratio會導致過多的解析，增加CPU消耗。比例過小則需要增加shared pool大小
- Execute to Parse %：表示sql語句解析後被重複執行的命中率，如果該值偏小，說明分析（硬分析和軟分析）的比例較大，快速分析較少，其公式為 1-(parse/execute)
- Parse CPU to Parse Elapsd %：解析CPU時間和總的解析時間的比值(Parse CPU Time/ Parse Elapsed Time)【解析實際運行時間/(解析實際運行時間+解析中等待資源時間)】；若該指標水平很低，那麼說明在整個解析過程中 實際在CPU上運算的時間是很短的，而主要的解析時間都耗費在各種其他非空閒的等待事件上了（有時候Parse CPU to Parse Elapsd%會超過100%，這是由於四捨五入造成的，CPU Time是一點一點記錄，並累加的（按SQL Parse 中的每個Call）而Elapsed Time 是一段一段紀錄，並累加的（按SQL 一次parse）比如說，現在開始一個 parse , 中間有100次call, 本來每次應該是 0.8 微秒，但是，Oracle 記錄時每次計成是 1 微秒，結果，這一次的parse CPU 被記錄成 100 微妙。而Elapsed Time 紀錄的是整個的時間，等於 0.8 *100 + （wait time）,結果就可能小於 100 微妙。而最終結果就是 Parse CPU to Parse Elapsd% > 100%）
- Redo NoWait %：session獲取buffer 在redo buffer cache中不用等待的比例，redo相關的資源如redo space request爭用可能造成生成redo時需求等待。
- In-memory Sort %：排序在內存PGA中的比例。（不是workarea中所有的操作類型只是排序，所以現在越來越雞肋了），比例過小則需要增加PGA_AGGREGATE_TARGET值
- Soft Parse %：軟解析的百分比，softs/(softs+hards), 太低則需要調整應用使用綁定變量
- Latch Hit %：有申請不要等待的比例
- % Non-Parse CPU：非解析cpu比例，公式為 (DB CPU – Parse CPU)/DB CPU， 若大多數CPU都用在解析上了，則可能好鋼沒用在刃上了。
4.Top 10 Foreground Events by Total Wait Time
- DB file sequential read等待意味著發生順序I/O讀等待（通常是單塊讀取到連續的內存區域中），如果這個等待非常嚴重，應該使用上一段的方法確定執行讀操作的熱點SEGMENT，然後通過對大表進行分區以減少I/O量，或者優化執行計劃（通過使用存儲大綱或執行數據分析）以避免單塊讀操作引起的sequential read等待。通過在批量應用中，DB file sequential read是很影響性能的事件，總是應當設法避免。
- Log File Parallel Write事件是在等待LGWR進程將REDO記錄從LOG 緩衝區寫到聯機日誌文件時發生的。雖然寫操作可能是併發的，但LGWR需要等待最後的I/O寫到磁盤上才能認為並行寫的完成，因此等待時間依賴於OS完成所有請求的時間。如果這個等待比較嚴重，可以通過將LOG文件移到更快的磁盤上或者條帶化磁盤（減少爭用）而降低這個等待。
- Buffer Busy Waits事件是在一個SESSION需要訪問BUFFER CACHE中的一個數據庫塊而又不能訪問時發生的。緩衝區“busy”的兩個原因是：1）另一個SESSION正在將數據塊讀進BUFFER。2）另一個SESSION正在以排它模式佔用著這塊被請求的BUFFER。可以在“Segments by Buffer Busy Waits”一節中找出發生這種等待的SEGMENT，然後通過使用reverse-key indexes並對熱表進行分區而減少這種等待事件。
- Log File Sync事件，當用戶SESSION執行事務操作（COMMIT或ROLLBACK等）後，會通知 LGWR進程將所需要的所有REDO信息從LOG BUFFER寫到LOG文件，在用戶SESSION等待LGWR返回安全寫入磁盤的通知時發生此等待。減少此等待的方法寫Log File Parallel Write事件的處理。
- Enqueue Waits是串行訪問本地資源的本鎖，表明正在等待一個被其它SESSION（一個或多個）以排它模式鎖住的資源。減少這種等待的方法依賴於生產等待的鎖類型。導致Enqueue等待的主要鎖類型有三種：TX（事務鎖）, TMD（ML鎖）和ST（空間管理鎖）。
5.Wait Classes by Total Wait Time
6.Host CPU
7.Instance CPU
8.IO Profile
9.Memory Statistics
10. Cache Sizes
- Buffer Cache也叫數據庫緩衝區高速緩存，是SGA中用來緩存已從數據文件中檢索到的數據塊的副本。是緩存最常用的段，以便儘可能減少訪問數據時物理磁盤I/O的次數。基本上Buffer Cache越大越好。
- Shared Pool主要包括library cache和dictionary cache。library cache用來存儲最近解析（或編譯）過的SQL、PL/SQL語句及它們對應的hash值和執行計劃等。library cache用來存儲最近引用的數據字典。發生在library cache或dictionary cache的cache miss代價要比發生在buffer cache的代價高得多。因此shared pool的設置要確保最近使用的數據都能被cache。
- Std Block Size是數據塊大小。
- Log Buffer是重做日誌緩衝區大小。
11. Shared Pool Statistics
- Memory Usage %：對於一個已經運行一段時間的數據庫來說，共享池內存使用率，應該穩定在75%-90%間，如果太小，說明Shared Pool有浪費，而如果高於90，說明共享池中有爭用，內存不足。
- 這個數字應該長時間穩定在75%～90%。如果這個百分比太低，表明共享池設置過大，帶來額外的管理上的負擔，從而在某些條件下會導致性能的下降。如果這個百分率太高，會使共享池外部的組件老化，如果SQL語句被再次執行，這將使得SQL語句被硬解析。在一個大小合適的系統中，共享池的使用率將處於75%到略低於90%的範圍內.
- SQL with executions>1：執行次數大於1的sql比率，如果此值太小，說明需要在應用中更多使用綁定變量，避免過多SQL解析。在一個趨向於循環運行的系統中，必須認真考慮這個數字。在這個循環系統中，在一天中相對於另一部分時間的部分時間裡執行了一組不同的SQL語句。在共享池中，在觀察期間將有一組未被執行過的SQL語句，這僅僅是因為要執行它們的語句在觀察期間沒有運行。只有系統連續運行相同的SQL語句組，這個數字才會接近100%。
- Memory for SQL w/exec>1：執行次數大於1的SQL消耗內存的佔比。這是與不頻繁使用的SQL語句相比，頻繁使用的SQL語句消耗內存多少的一個度量。這個數字將在總體上與% SQL with executions>1非常接近，除非有某些查詢任務消耗的內存沒有規律。在穩定狀態下，總體上會看見隨著時間的推移大約有75%～85%的共享池被使用。如果Statspack報表的時間窗口足夠大到覆蓋所有的週期，執行次數大於一次的SQL語句的百分率應該接近於100%。這是一個受觀察之間持續時間影響的統計數字。可以期望它隨觀察之間的時間長度增大而增大。
總結：
AWR的引入，為我們分析數據庫提供了非常好的便利條件。曾經有這樣的一個比喻——“一個系統，就像是一個黑暗的大房間，系統收集的統計信息，就如同放置在房間不同位置的蠟燭，用於照亮這個黑暗大房間。Oracle，恰到好處地放置了足夠的蠟燭(AWR)，房間中只有極少的燭光未覆蓋之處，性能瓶頸就容易定位。而對於蠟燭較少或是沒有蠟燭的系統，性能優化就如同黑暗中的舞者。”
分享到:
