什么是AWR?
一堆歷史性能數據，放在sysaux表空間上，AWR和sysaux都是10g出現的，是oracle調優的關鍵特性。
默認快照間隔1小時；10g保存7天；11g保存8天；
可以通過DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS修改
AWR核心是dbms_workload_repository包
@?/rdbms/admin/awrrpt 本實例
@?/rdbms/admin/awrrpti RAC中選擇實例號（在主機中想拉另一台oracle的awr報告）
基礎統計指標：
SQL和優化器指標
OS指標
等待事件類型
時間指標（oracle時間模型）
AWR小技巧
手動執行一個快照：
exec dbms_workload_repository.create_snapshot;
創建一個awr基線：
exec dbms_workload_repository.create_baseline(start_snap_id,end_snap_id,baseline_name);
@?/rdbms/admin/awrddrpt AWR比對報告
@?/rdbms/admin/awrgrpt RAC全局AWR
自動生成AWR HTML報告：
http://www.oracle-base.com/dba/10g/generate_multiple_awr_reports.sql
AWR報告分析可從以下幾點入手：
(1).Oacle主機資源開銷分析及負載情況
(2).oracle top信息分析 Top 10 Foreground Events by Total Wait Time
(3).sql開銷情況 SQL ordered by Elapsed Time
(4).oracle負載情況 Load Profile
(5).oracle實例效率分析 Instance Efficiency Percentages (Target 100%)
(6).oracle共享池分析 Shared Pool Statistics
AWR報告指標分析：
Oacle主機資源開銷分析及負載情況：
CPUs:32 邏輯cpu數
Elapsed快照監控時間：如果為了診斷特定時段性能問題則Elapsed不宜過長15分鍾~2、3個小時。如果是看全天負載那么可以長一些，最常見是60分鍾后者120分鍾。
DB Time：不包括Oracle后台進程消耗的時間，如果DB Time遠遠小於Elapsed時間，說明數據庫比較空閑。
DB Time= cpu time + wait time（不包含空閑等待） （非后台進程）
數據庫耗時17分鍾，共32個邏輯cpu：17/32=0.53，平均每個cpu耗時0.53分鍾
cpu利用率：0.53/60=0.008 0.8%利用率很小，說明cpu空閑
如果超過100%說明出現等待現象
oracle負載情況：
Redo size：每秒產生的日志大小(單位字節)，可標志數據變更頻率, 數據庫任務的繁重與否。
Logical reads：每秒/每事務邏輯讀的塊數.平決每秒產生的邏輯讀的block數。Logical Reads= Consistent Gets + DB Block Gets；
Block changes：每秒/每事務修改的塊數；
Physical reads：每秒/每事務物理讀的塊數；
Physical writes：每秒/每事務物理寫的塊數；
User calls：每秒/每事務用戶call次數；
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：每次排序的行數
Transactions：數據庫層的TPS（單獨看沒什么意義，可用作優化前后的對比值）。
parses：解析次數；軟解析加硬解析
Hard parses：硬解析 萬惡之源，會造成多種等待，不要超過每秒20次
結合Time Model Statistics查看
Hard parses（硬解析數）和hard parse (sharing criteria) elapsed time對應，看一眼Time Model Statistics，
即可知該系統是否是解析敏感的
注:
Oracle的硬解析和軟解析
提到軟解析(soft prase)和硬解析(hard prase)，就不能不說一下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的執行來說是開銷昂貴的動作，所以，應當極力避免硬解析，盡量使用軟解析。
oracle top信息分析：
db file scattered read等待事件是當SESSION等待multi-block I/O時發生的，通過是由於full table scans或index fast full scans。發生過多讀操作的Segments可以在“Segments by Physical Reads”和 “SQL ordered by Reads”節中識別（在其它版本的報告中，可能是別的名稱）。如果在OLTP應用中，不應該有過多的全掃描操作，而應使用選擇性好的索引操作。
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（空間管理鎖）。
sql開銷情況：
SQL ordered by Elapsed Time部分可以最准確定位到某個導致的性能問題。重點關注3個參數的值：
(1).Elapsed Time(S)表示sql執行的總時間。
(2).Executions表示sql執行次數。
(3).Elap per Exec(s): 執行一次SQL的平均時間，單位時間為秒。
oracle實例效率分析：
主要關注一下兩個參數：
(1).Buffer Nowait%：表示在內存獲得數據的未等待比例
(2).Parse CPU to Parse Elapsd %:解析總時間中消耗總CPU的時間百分比，該值越低表示實例越空閑。
由於實例在50%左右實例處於正常狀態。
Parse CPU to Parse Elapsd：說明在解析sql語句過程中，cpu占整個的解析時間比例。
解析實際運行時間/(解析實際運行時間+解析中等待資源時間)，越高越好。計算公式為：Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。即：解析實際運行時間/(解析實際運行時間+解析中等待資源時間)。如果該比率為100%，意味着CPU等待時間為0，沒有任何等待。
Shared Pool Statistics：
Memory Usage%維持在90以上，所以共享池沒有造成嚴重浪費。