AWR報告分析
1.1 看CPU的負載情況
DBTime:表示CPU花費在處理Oralce非空閑等待和運算上的時間
DB TIME= DB CPU + Non-Idle Wait + Wait on CPU queue
Elapsed：表示本AWR報告由多久的快照間隔生成的
負載情況：DBTime / Elapsed * CPUs 這個比值越小 說明DB負載壓力越小
1.2看事務的繁忙程度、軟硬解析
Load Profile 主要用來顯示當前系統的一些指示性能的總體參數，部分介紹如下
列Per Second：平均每秒
列Per Transaction：平均每個事務
如圖，平均每秒的事務數Transactions是75，非常小，說明系統壓力非常小，一般來說Transactions不超過200都是正常的，或者200左右都是正常的，超過1000就是非常繁忙了，
再看看平均每秒的日志尺寸是4位數的，平均每個事務的日志尺寸是5位數的，說明了系統訪問不是很頻繁，而單個業務是比較復雜的，
如果反過來，平均每秒日志尺寸比平均每秒事務日志尺寸大很多，說明系統訪問很頻繁，而業務比較簡單，不需要響應很久
- Redo Size ：用來顯示平均每秒的日志大小和平均每個事務的日志大小，有時候可以結合 Transactions 每秒事務數，分析當前事務的繁忙程度。
- Parses：解析次數，包括軟解析 + 硬解析，軟解析優化得不好幾乎等於每秒SQL執行次數， 即執行解析比1:1。理想狀態是解析一次到處運行。
- Hard Parses：硬解析次數，最好小於每秒20次，否則就要考慮優化相關SQL。
- Transactions: 事務數量
1.3 看命中率指標
efficiency percentages是一些命中率指標。Buffer Hint、Library Hint等表示SGA(System global area)的命中率；
Buffer Nowait : Buffer Nowait的這個值一般需要大於99%** 否則可能存在爭用，可以在后面等待事件中進一步確認。
表示在內存獲得數據的未等待比例。在緩沖區中獲取Buffer的未等待比率。
Buffer Hit :如果此值低於80%，應該給數據庫分配更多的內存
表示進程從內存中找到數據塊的比率，監視這個值是否發生重大變化比這個值本身更重要。對於一般的OLTP系統，數據塊在數據緩沖區中的命中率，通常應在95%以上。
Redo NoWait ：表示在Log 緩沖區獲得Buffer的未等待比例。如果太低可考慮增加Log Buffer。當redo buffer達到1M時就需要寫到redo log文件，所以一般當redo buffer設置超過1M，不太可能存在等待buffer空間分配的情況。當前，一般設置為2M的redo buffer，對於內存總量來說，應該不是一個太大的值。
In-memory Sort：在內存中排序的比率，如果過低說明有大量的排序在臨時表空間中進行。考慮調大PGA(10g)。如果低於95%，可以通過適當調大初始化參數PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE來解決，注意這兩個參數設置作用的范圍時不同的，SORT_AREA_SIZE是針對每個session設置的，PGA_AGGREGATE_TARGET則時針對所有的sesion的。
Library Hit ：如果Library Hit Ratio低於90%，可能需要調大Shared pool區。
表示Oracle從Library Cache中檢索到一個解析過的SQL或PL/SQL語句的比率，當應用程序調用SQL或存儲過程時，Oracle檢查Library Cache確定是否存在解析過的版本，如果存在Oracle立即執行語句；如果不存在Oracle解析此語句，並在Library Cache中為它分配共享SQL區。低的Library Hit Ratio會導致過多的解析，增加CPU消耗，降低性能。
Soft Parse：小於<95%,需要考慮綁定，如果低於80%，那么就可以認為sql基本沒有被重用。
軟解析的百分比(Softs/Softs+Hards)，近似當作sql在共享區的命中率，太低則需要調整應用使用綁定變量。sql在共享區的命中率，
Latch Hit：要確保>99%，否則存在嚴重的性能問題。當該值出現問題的時候，我們可以借助后面的等待時間和latch分析來查找解決問題。
Latch是一種保護內存結構的鎖，可以認為是Server進程獲取訪問內存數據結構的許可。要確保Latch Hit>99%，否則意味着Shared Pool latch爭用，可能由於未共享的SQL，或者Library Cache太小，可使用綁定變更或調大Shared Pool解決。
Parse CPU to Parse Elapsd：解析實際運行時間/(解析實際運行時間+解析中等待資源時間)，越高越好。如果該比率為100%，意味着CPU等待時間為0，沒有任何等待。
Non-Parse CPU ：SQL實際運行時間/(SQL實際運行時間+SQL解析時間)，太低表示解析消耗時間過多。如果這個值比較小，表示解析消耗的CPU時間過多。
Execute to Parse：是語句執行與分析的比例，如果要SQL重用率高，則這個比例會很高。該值越高表示一次解析后被重復執行的次數越多。
1.4 看等待事件
Top 10 Foreground Events by Total Wait Time，等待事件是衡量數據庫優化情況的重要指標，通過觀察Event和%DB time兩列就可以直觀看出當前數據庫的主要等待事件
1.5 看TOP SQL統計
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。
參考AWR深度好文章: http://www.askmac.cn/archives/performance-tuning-oracle-awr.html
https://www.cnblogs.com/cocowool/p/quick_view_of_oracle_awr_report.html
https://www.cnblogs.com/mzq123/p/10741208.html