本文面向沒有太多 Oracle 基礎知識，但是需要通過 AWR 報告來分析數據庫性能或排查問題人員，通過對 AWR 報告的簡介，了解其包含的主要信息，然后對一些能夠幫助我們分析定位問題的章節做一點稍微詳細的介紹。通過閱讀本文，期望使讀者能夠快速抓住閱讀 AWR 報告的重點，為分析判斷數據庫性能是否有問題提供幫助。
本文示例報告基於 Oracle 11.2.0.3.0 版本生成。
AWR報告簡介
AWR是Oracle 10g版本推出的特性，全稱叫做 Automatic Workload Repository 全自動負載信息庫 。Oracle啟動后，會有后台進程定時采集並保存系統快照信息，也可以手工創建快照。AWR通過對比兩個時間點的快照信息，生成該時間段的AWR報告，幫助DBA或開發人員了解 Oracle 數據庫的運行情況。Oracle 還提供了 ASH、ADDM等工具，本文不進行探討。
AWR報告結構
AWR報告基本分為四部分：
- 基本信息部分，包括了DB實例、主機的信息以及報告采集時間段的信息。
- Main Report部分，第一部分Report Summary被單獨放在了基本信息后面，其他的信息則放在整個報告較后的位置，個人覺得最重要的部分是SQL Statistcs。
- RAC statistics部分，包括RAC相關的統計信息。
- Wait Event Statistics部分。
基本信息
報告一開始部分為基本信息，顯示了DB實例、主機信息。DB Time 指標可以用來判斷數據庫是否繁忙，如果 Elapsed 時間乘以CPU個數小於DB Time 表示數據庫比較繁忙。
Report Summary
Report Summary 分為8個部分，最主要的是 Load Profile。
Load Profile 主要用來顯示當前系統的一些指示性能的總體參數，部分介紹如下：
- Redo Size ：用來顯示平均每秒的日志大小和平均每個事務的日志大小，有時候可以結合 Transactions 每秒事務數，分析當前事務的繁忙程度。
- Logical Read：邏輯讀耗CPU，主頻和CPU核數都很重要，邏輯讀高則DB CPU往往高，也往往可以看到
latch: cache buffer chains等待。 - Physical Read：物理讀消耗IO讀，體現在IOPS和吞吐量等不同緯度上。但減少物理讀可能意味着消耗更多CPU。
- Parses：解析次數，包括軟解析 + 硬解析，軟解析優化得不好幾乎等於每秒SQL執行次數， 即執行解析比1:1。理想狀態是解析一次到處運行。
- Hard Parses：硬解析次數，最好少於沒秒20次。
注意 Load Profile 中的指標提供了 Per second 和 Per transaction 兩個維度。Per second 主要是把快照抓到的值除以兩個快照之間的秒數。這是我們用來判斷性能的主要維度。Per transaction 是基於事務的維度，主要是把快照抓到的值除以兩個快照之間的事務數。
Instance Efficiency Percentages 是一些命中率指標。Buffer Hit、Library Hit 等表示SGA ( System global area )的命中率。Soft Parse 指標表示共享池的軟解析率，如果小於90%，就說明存在未綁定變量的情況。這些指標應當盡可能接近100%，如果過低一定是發生了性能問題。
- Buffer Nowait ** 表示在內存獲得數據的未等待比例。在緩沖區中獲取Buffer的未等待比率。Buffer Nowait的這個值一般需要大於99%**。否則可能存在爭用，可以在后面的等待事件中進一步確認。
- Buffer Hit 表示進程從內存中找到數據塊的比率，監視這個值是否發生重大變化比這個值本身更重要。對於一般的OLTP系統，如果此值低於80%，應該給數據庫分配更多的內存。數據塊在數據緩沖區中的命中率，通常應在95%以上。
- Redo NoWait 表示在Log 緩沖區獲得Buffer的未等待比例。如果太低可考慮增加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區。
- Latch Hit：Latch是一種保護內存結構的鎖，可以認為是Server進程獲取訪問內存數據結構的許可。要確保Latch Hit>99%，否則意味着Shared Pool latch爭用，可能由於未共享的SQL，或者Library Cache太小，可使用綁定變更或調大Shared Pool解決。要確保>99%，否則存在嚴重的性能問題。當該值出現問題的時候，我們可以借助后面的等待時間和latch分析來查找解決問題。
- Parse CPU to Parse Elapsd：解析實際運行時間/(解析實際運行時間+解析中等待資源時間)，越高越好。如果該比率為100%，意味着CPU等待時間為0，沒有任何等待。
- Non-Parse CPU ：SQL實際運行時間/(SQL實際運行時間+SQL解析時間)，太低表示解析消耗時間過多。如果這個值比較小，表示解析消耗的CPU時間過多。
- Execute to Parse：是語句執行與分析的比例，如果要SQL重用率高，則這個比例會很高。該值越高表示一次解析后被重復執行的次數越多。
- 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基本沒有被重用。
Main Report
- Report Summary 在上面一節已經說過，不再贅述。
- SQL Statistics 從
11個維度對SQL進行排序並給出了Top SQL的詳細內容，可以點擊查看具體的SQL內容，進一步分析調優方案。- SQL ordered by Elapsed Time。記錄了執行總和時間的 TOP SQL(請注意是監控范圍內該SQL的執行時間總和，而不是單次SQL執行時間 Elapsed Time = CPU Time + Wait Time)。
- SQL ordered by CPU Time。記錄了執行占CPU時間總和時間最長的TOP SQL(請注意是監控范圍內該SQL的執行占CPU時間總和，而不是單次SQL執行時間)。
- SQL ordered by Gets。記錄了執行占總 buffer gets (邏輯IO)的TOP SQL(請注意是監控范圍內該SQL的執行占Gets總和，而不是單次SQL執行所占的Gets)。
- SQL ordered by Reads。記錄了執行占總磁盤物理讀(物理IO)的TOP SQL。
- SQL ordered by Executions。記錄了按照SQL的執行次數排序的TOP SQL。該排序可以看出監控范圍內的SQL執行次數。
- SQL ordered by Parse Calls。記錄了SQL的軟解析次數的TOP SQL。
- SQL ordered by Sharable Memory。記錄了SQL占用library cache的大小的TOP SQL。Sharable Mem (b)：占用library cache的大小，單位是byte。
- SQL ordered by Version Count。記錄了SQL的打開子游標的TOP SQL。
- SQL ordered by Cluster Wait Time。記錄了集群的等待時間的TOP SQL。
- Top 10 Foreground Events by Total Wait Time，等待事件是衡量數據庫優化情況的重要指標，通過觀察Event和%DB time兩列就可以直觀看出當前數據庫的主要等待事件。
RAC statistics
這一部分涉及RAC運行的相關統計信息，對於初學者來說不太常用，本文暫不贅述。
Wait Event Statistics
其中 Time Model Statistics 幾個有用的指標解釋如下：
- parse time elapsed 與 hard parse elapsed time 需要結合起來看解析是否是主要矛盾，若是則重點是軟解析還是硬解析。
- sequence load elapsed time 序列爭用
- PL/SQL compilation elapsed time PL/SQL對象編譯的耗時
- connection management call elapsed time 數據庫連接建立和斷開的耗時
- failed parse elapsed time 解析失敗的耗時
