共計 5594 個字符，預計需要花費 14 分鐘才能閱讀完成。
這期內容當中丸趣 TV 小編將會給大家帶來有關如何進行 ORACLE 的 AWR 報告分析，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
1、什么是 AWR？
AWR (Automatic Workload Repository) 是自動負載信息庫的英文縮寫，AWR 報告是 Oracle 10g 以后版本提供的一種性能收集和分析工具，能提供一個時間段內整個系統資源使用情況的報告，通過報告可以了解一個系統的整個運行情況，生成的報告包括多個部分。
AWR 每小時對 v$active_session_history 視圖 (內存中的 ASH 采集信息，理論為 1 小時) 進行采樣一次，并將信息保存到磁盤中，并且保留 7 天，7 天后舊的記錄才會被覆蓋。這些采樣信息被保存在 wrh$_active_session_history 視圖 (寫入 AWR 庫中的 ASH 信息，理論為 1 小時以上) 中。而這個采樣頻率（1 小時）和保留時間（7 天）是可以根據實際情況進行調整的，這就給 DBA 們提供了更加有效的系統監測工具。
2、什么情況下會用到 AWR？
DBA 對數據庫運行狀態及狀況的監控了解、測試過程中發現數據庫出現瓶頸但無法定位到具體原因時，可以借用 AWR 報告進行分析定位。
數據庫出現性能問題，一般都在三個地方：IO、內存、CPU，這三個地方又是息息相關的。假設這個三個地方都沒有物理上的故障，當 IO 負載增大時，肯定需要更多的內存來存放，同時也需要 CPU 花費更多的時間來過濾這些數據。相反，CPU 時間花費多的話，有可能是解析 SQL 語句，也可能是過濾太多的數據，倒不一定是和 IO 或內存有關系。
CPU：解析 SQL 語句，嘗試多個執行計劃，最后生成一個數據庫認為是比較好的執行計劃，但不一定是最優的。因為關聯表太多的時候，數據庫并不會窮舉所有的執行計劃，這會消耗太多的時間，oracle 怎么知道這條數據是你要的，另一個就不是你要的呢，這是需要 cpu 來過濾的。
內存：SQL 語句和執行計劃都需要在內存保留一段時間，還有取到的數據，根據 LRU 算法也會盡量在內存中保留，在執行 SQL 語句過程中，各種表之間的連接，排序等操作也要占用內存。
IO：如果需要的數據不在內存中，則需要到磁盤中去取，就會涉及到物理 IO 了，還有表之間的連接數據太多，以及排序等操作內存放不下的時候，需要用到臨時表空間，也會消耗物理 io 了。
這里說明下，ORACLE 分配的內存中 PGA 一般只占 20%，對于專用服務器模式，每次執行 SQL 語句、表數據的運算等操作，都在 PGA 中進行的，也就是說只能用 ORACL 分配內存的 20% 左右，如果多個用戶都執行多表關聯，而且表數據又多，再加上關聯不當的話，內存就成為瓶頸了，所以優化 SQL 很重要的一點就是，減少邏輯讀和物理讀。
3、如何生成 awr 報告？
第一步，登錄 ORACLE 數據庫服務器，記住當前目錄或者切換至 AWR 想要保存的目錄；
第二步，SQLplus 用戶名 / 密碼 @服務連接名，連接 oracle 數據庫實例，如下圖所示；
第三步，執行 @?/rdbms/admin/awrrpt;，會出現提示，
可以生成以下幾種類型 AWR 報告，大部分情況下都是生成本實例的 AWR 報告
@?/rdbms/admin/awrrpt; 本實例 AWR 包括
@?/rdbms/admin/awrrpti; RAC 中選擇實例號
@?/rdbms/admin/awrddrpt; AWR 比對報告
@?/RDBMS/admin/awrgrpt; RAC 全局 AWR 報告
輸入生成 AWR 報告的格式是 html 的，如下圖所示：
輸入開始值與結束值：（輸入天數后會列出，snap 值）
輸入 AWR 報告的名稱：名稱自定義 回車后就開始自動生產 AWR 報告，如下圖所示：
結束后就可以去指定目錄下照 AWR 報告文件，文件為 test_awr.lst，如下圖所示：
4、分析 AWR 報告
AWR 報告內容很豐富這里選其中一小部分來講解，分析 AWR 報告前先了解一下 Oracle 的硬解析和軟解析，首先說一下 Oracle 對 SQL 的處理過程。當你發出一條 SQL 語句交付 Oracle，在執行和獲取結果前 Oracle 對此 SQL 將進行幾個步驟的處理過程：
1、語法檢查(syntax check)
檢查此 SQL 的拼寫是否語法。
2、語義檢查(semantic check)
諸如檢查 SQL 語句中的訪問對象是否存在及該用戶是否具備相應的權限。
3、對 SQL 語句進行解析(prase)
利用內部算法對 SQL 進行解析，生成解析樹 (parse tree) 及執行計劃(execution plan)。
4、執行 SQL，返回結果(execute and return)
其中，軟、硬解析就發生在第三個過程里。
Oracle 利用內部的 hash 算法來取得該 SQL 的 hash 值，然后在 library cache 里查找是否存在該 hash 值；
假設存在，則將此 SQL 與 cache 中的進行比較；
假設“相同”，就將利用已有的解析樹與執行計劃，而省略了優化器的相關工作。這也就是軟解析的過程。
當然，如果上面的 2 個假設中任有一個不成立，那么優化器都將進行創建解析樹、生成執行計劃的動作。這個過程就叫硬解析。
創建解析樹、生成執行計劃對于 SQL 的執行來說是開銷昂貴的動作，所以，應當極力避免硬解析，盡量使用軟解析。
打開 AWR 報告頭如下圖所示：
顯示 SGA 中每個區域的大小，可用來與初始參數值比較。
shared pool 主要包括 library cache 和 dictionary cache。library cache 用來存儲最近解析（或編譯）后 SQL、PL/SQL 和 Java classes 等。library cache 用來存儲最近引用的數據字典。發生在 library cache 或 dictionary cache 的 cache miss 代價要比發生在 buffer cache 的代價高得多，因此 shared pool 的設置要確保最近使用的數據都能被 cache。
上圖包含了 Oracle 關鍵指標的內存命中率及其它數據庫實例操作的效率，其中 Buffer Hit Ratio 也稱 Cache Hit Ratio，Library Hit ratio 也稱 Library Cache Hit ratio。同 Load Profile 一節相同，這一節也沒有所謂“正確”的值，而只能根據應用的特點判斷是否合適。在一個使用直接讀執行大型并行查詢的 DSS 環境，20% 的 Buffer Hit Ratio 是可以接受的，而這個值對于一個 OLTP 系統是完全不能接受的。根據 Oracle 的經驗，對于 OLTPT 系統，Buffer Hit Ratio 理想應該在 90% 以上。
Buffer Nowait 表示在內存獲得數據的未等待比例，在緩沖區中獲取 Buffer 的未等待比率，Buffer Nowait 的這個值一般需要大于 99%。否則可能存在爭用，可以在后面的等待事件中進一步確認。
Buffer Hit 表示進程從內存中找到數據塊的比率，監視這個值是否發生重大變化比這個值本身更重要。對于一般的 OLTP 系統，如果此值低于 80%，應該給數據庫分配更多的內存。數據塊在數據緩沖區中的命中率，通常應在 95% 以上。否則，小于 95%，需要調整重要的參數，小于 90% 可能是要加 db_cache_size。一個高的命中率，不一定代表這個系統的性能是最優的，比如大量的非選擇性的索引被頻繁訪問，就會造成命中率很高的假相（大量的 db file sequential read），但是一個比較低的命中率，一般就會對這個系統的性能產生影響，需要調整。命中率的突變，往往是一個不好的信息。如果命中率突然增大，可以檢查 TOP buffer get SQL，查看導致大量邏輯讀的語句和索引，如果命中率突然減小，可以檢查 TOP physical reads SQL，檢查產生大量物理讀的語句，主要是那些沒有使用索引或者索引被刪除的。
Redo NoWait 表示在 LOG 緩沖區獲得 BUFFER 的未等待比例。如果太低（可參考 90% 閾值），考慮增加 LOG BUFFER。當 redo buffer 達到 1M 時，就需要寫到 redo log 文件，所以一般當 redo buffer 設置超過 1M，不太可能存在等待 buffer 空間分配的情況。當前，一般設置為 2M 的 redo buffer，對于內存總量來說，應該不是一個太大的值。
Library Hit：表示 Oracle 從 Library Cache 中檢索到一個解析過的 SQL 或 PL/SQL 語句的比率，當應用程序調用 SQL 或存儲過程時，Oracle 檢查 Library Cache 確定是否存在解析過的版本，如果存在，Oracle 立即執行語句；如果不存在，Oracle 解析此語句，并在 Library Cache 中為它分配共享 SQL 區。低的 library hit ratio 會導致過多的解析，增加 CPU 消耗，降低性能。如果 library hit ratio 低于 90%，可能需要調大 shared pool 區。STATEMENT 在共享區的命中率，通常應該保持在 95% 以上，否則需要要考慮：加大共享池；使用綁定變量；修改 cursor_sharing 等參數。
Latch Hit：Latch 是一種保護內存結構的鎖，可以認為是 SERVER 進程獲取訪問內存數據結構的許可。要確保 Latch Hit 99%，否則意味著 Shared Pool latch 爭用，可能由于未共享的 SQL，或者 Library Cache 太小，可使用綁定變更或調大 Shared Pool 解決。要確保 99%，否則存在嚴重的性能問題。當該值出現問題的時候，我們可以借助后面的等待時間和 latch 分析來查找解決問題。
Parse CPU to Parse Elapsd：解析實際運行時間 /(解析實際運行時間 + 解析中等待資源時間)，越高越好。計算公式為：Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。即：解析實際運行時間 /(解析實際運行時間 + 解析中等待資源時間)。如果該比率為 100%，意味著 CPU 等待時間為 0，沒有任何等待。
Non-Parse CPU：SQL 實際運行時間 /(SQL 實際運行時間 +SQL 解析時間)，太低表示解析消耗時間過多。計算公式為：% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。如果這個值比較小，表示解析消耗的 CPU 時間過多。與 PARSE_CPU 相比，如果 TOT_CPU 很高，這個比值將接近 100%，這是很好的，說明計算機執行的大部分工作是執行查詢的工作，而不是分析查詢的工作。
Execute to Parse：是語句執行與分析的比例，如果要 SQL 重用率高，則這個比例會很高。該值越高表示一次解析后被重復執行的次數越多。計算公式為：Execute to Parse =100 * (1 – Parses/Executions)。本例中，差不多每 execution 5 次需要一次 parse。所以如果系統 Parses Executions，就可能出現該比率小于 0 的情況。該值 0 通常說明 shared pool 設置或者語句效率存在問題，造成反復解析，reparse 可能較嚴重, 或者是可能同 snapshot 有關，通常說明數據庫性能存在問題。
In-memory Sort：在內存中排序的比率，如果過低說明有大量的排序在臨時表空間中進行。考慮調大 PGA(10g)。如果低于 95%，可以通過適當調大初始化參數 PGA_AGGREGATE_TARGET 或者 SORT_AREA_SIZE 來解決，注意這兩個參數設置作用的范圍時不同的，SORT_AREA_SIZE 是針對每個 session 設置的，PGA_AGGREGATE_TARGET 則時針對所有的 sesion 的。
Soft Parse：軟解析的百分比（softs/softs+hards），近似當作 SQL 在共享區的命中率，太低則需要調整應用使用綁定變量。 SQL 在共享區的命中率，小于 95%, 需要考慮綁定，如果低于 80%，那么就可以認為 SQL 基本沒有被重用。
TOP5 time Event 是 AWR 報告概要的最后一節，顯示了系統中最嚴重的 5 個等待，按所占等待時間的比例倒序列示。一個性能良好的系統，CPU Time 應該在 TOP 5 的前面，否則說明你的系統大部分時間都用在等待上。當我們調優時，總希望觀察到最顯著的效果，因此應當從這里入手確定下一步做什么。例如‘buffer busy wait’是較嚴重的等待事件，應當繼續研究報告中 Buffer Wait 和 File/Tablespace IO 區的內容，識別哪些文件導致了問題。如果最嚴重的等待事件是 I / O 事件，應當研究按物理讀排序的 SQL 語句區以識別哪些語句在執行大量 I /O，并研究 Tablespace 和 I / O 區觀察較慢響應時間的文件。如果有較高的 LATCH 等待，就需要察看詳細的 LATCH 統計識別哪些 LATCH 產生的問題。
在這里，log file parallel write 是相對比較多的等待，占用了 7% 的 CPU 時間。通常借助 AWR 報告尋找耗時比較長或資源使用比較高的 SQL 語句，按各種資源分別列出對資源消耗最嚴重的 SQL 語句，并顯示它們所占統計期內全部資源的比例，這給出我們調優指南。例如在一個系統中，CPU 資源是系統性能瓶頸所在，那么優化 buffer gets 最多的 SQL 語句將獲得最大效果。在一個 I / O 等待是最嚴重事件的系統中，調優的目標應該是 physical IO 最多的 SQL 語句。
這里列出了耗時比較長的 SQL，從高到低排序 TOP100，在 AWR 報告中點擊 SQL ID 連接即可跳轉到詳細的 SQL 語句的地方。
上述就是丸趣 TV 小編為大家分享的如何進行 ORACLE 的 AWR 報告分析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注丸趣 TV 行業資訊頻道。
