Oracle數據庫awr報告使用與分析

轉：https://www.cnblogs.com/zhaot1993/p/13530739.html

一 AWR報告生成

1、生成AWR(Automatic Workload Repository)報告：
sqlplus / as sysdba
SQL>@?/rdbms/admin/awrrpt.sql

2、修改采集時間和統計信息保留時間:
SQL>exec dbms_workload_repository.modify_snapshot_settings(interval=>30,retention=>7*24*60);
SQL>select * from dba_hist_wr_control;

3、手動執行一個快照：
SQL>exec dbms_workload_repository.create_snapshot;

4、創建一個AWR基線：
SQL>exec dbms_workload_repository.create_baseline(start_snap_id,end_snap_id,baseline_name);

二 AWR主要指標說明

指標	指標說明
redo size	單位bytes，redosize可以用來估量update/insert/delete的頻率， 大的redosize往往對lgwr寫日志和arch歸檔造成I/O壓力。
Logical Read	單位  次數*塊數， 邏輯讀耗CPU，主頻和CPU核數都很重要， 邏輯讀高則DBCPU往往高，也往往可以看到latch: cache buffers chains等待。
Block changes	單位次數*塊數 ， 描繪數據變化頻率
Physical Read	單位次數*塊數， 物理讀消耗IO，體現在IOPS和吞吐量等不同維度上；但減少物理讀可能意味着消耗更多CPU。 physical read包含了physical reads cache和physical reads direct
Physical writes	單位次數*塊數，主要是DBWR寫datafile，也有direct path write。 dbwr長期寫出慢會導致定期log file switch(checkpoint no complete) 檢查點無法完成的前台等待。  physical write 包含了physical writes direct +physical writes from cache
User Calls	單位次數，用戶調用數
Parses	解析次數，包括軟解析+硬解析； 軟解析每秒超過300次意味着”應用程序”效率不高，調整session_cursor_cache。
Hard Parses	萬惡之源，Cursor pin s on X， library cache: mutex X ， latch: row cache objects /shared pool…  硬解析最好少於每秒20次，每秒超過100次，說明綁定使用的不好，也可能共享池設置不合理。
W/A MB processed	單位MB  W/A workarea  workarea中處理的數據數量結合 In-memory Sort%， sorts (disk) PGA Aggr一起看
Transactions	每秒事務數，是數據庫層的TPS，可以看做壓力測試或比對性能時的一個指標，孤立看無意義。
% Blocks changed per Read	每次邏輯讀導致數據塊變化的比率；如果’redo size’, ‘block changes’ ‘pct of blocks changed per read’,三個指標都很高，說明系統正執行大量insert/update/delete;
Rollback per transaction %	事務回滾比率。  Rollback per transaction %= (rollback)/(transactions) 回滾率過高,說明數據庫經歷了太多的無效操作 ,過多的回滾還會帶來Undo Block的競爭。
Rows per Sort	平均每次排序涉及到的行數 ;  Rows per Sort= ( sorts(rows) ) / ( sorts(disk) + sorts(memory))
Buffer Nowait %	session申請一個buffer(兼容模式)不等待的次數比例，需要訪問buffer時立即可以訪問的比率； 一般大於99%，否則可能存在爭用。
buffer HIT%	高速緩存命中率，反映物理讀和緩存命中間的糾結，這個指標即便99% 也不能說明物理讀等待少了； 小於90%，可能要加db_cache_size； db_cache_size過小引起大量的db file sequential /scattered read等待事件； 與 buffer HIT%相關的指標有 table scans(long tables) 大表掃描， 此外相關的還有Buffer Pool Statistics 、Buffer Pool Advisory等。
Redo nowait%	session在生成redo entry時不用等待的比例，redo相關的資源爭用，小於90%,考慮增加log buffer； redo space request爭用可能造成生成redo時需求等待，需要關注是否有十分頻繁的 log switch ； 過小的redo logfile size 如果配合較大的SGA和頻繁的commit提交都可能造成該問題； 考慮增大redo logfile : 1~4G 每個，7~10組都是合適的，同時考慮優化redo logfile和datafile 的I/O。
In-memory Sort%	在內存中完成的排序比率 ；In-memory Sort% =  sort(memory) / ( sort(disk)+ sort(memory) ) 低於95%，通過適當調大初始化參數PGA_AGGREGATE_TARGET或SORT_AREA_SIZE。
Library Hit%	library cache命中率，合理值：>95% ，否則加大共享池，使用綁定變量，修改cursor_sharing等參數； 保持shared pool有足夠的Free Memory，且沒有過多的內存碎片； 保證SQL語句綁定變量和游標可以共享。
Soft Parse %	快照時間內軟解析次數和總解析次數 (soft+hard 軟解析次數+硬解析次數)的比值； 若指標很低，說明可能存在大量的hard parse硬解析； 大量的硬解析會消耗更多的CPU並產生解析爭用(此時可以考慮使用cursor_sharing=FORCE)； 通過設置 session_cached_cursors參數和反復重用游標可以讓解析更輕量級； 小於<95%,需要考慮綁定，低於80%，可以認為sql基本沒有被重用。
Execute  to Parse%	執行解析比 ，公式為 1-(parse/execute)，目標為100%； Execute to Parse和soft parse% 都很低 說明確實沒有綁定變量 ； 如果 soft parse% 接近99% 而Execute to Parse 不足90% 說明沒有執行； 解析比低， 需要通過靜態SQL、動態綁定、session_cached_cursor、open cursors等減少軟解析。 (Execute次數 - Parse次數)/Execute次數 x 100% 如偏小，說明解析(硬解析和軟解析)的比例過大，快速軟解析比例小。 根據實際情況，適當調整參數session_cursor_cache，提高會話中sql執行的命中率。 如為負數，通常說明shared pool設置或者語句效率存在問題，造成反復解析，reparse可能較嚴重, 或者是可能同snapshot有關，通常說明數據庫性能存在問題。
Latch Hit%	申請不要等待的比率，Latch Hit%:=  (1 – (Sum(misses) / Sum(gets))) Latch Hit>99%，否則Shared Pool latch爭用，可能未共享的SQL，或Library Cache太小， 可使用綁定變量或增大Shared Pool。
Memory Usage %	shared pool的空間使用率，穩定在75%-90% 太低，表明共享池設置過大， 一直很高，關注sga breakdown中的shared pool free memory， 推薦free memroy 至少300~500MB ，以避免隱患。
% SQL with executions>1	復用的SQL占總的SQL語句的比率， 如太小，在應用中更多使用綁定變量，避免過多SQL解析
% Memory for SQL w/exec>1	執行2次以上的SQL所占內存占總的SQL內存的比率
% Non-Parse CPU	CPU非分析時間在整個CPU時間的百分比，查詢實際運行時間/(查詢實際運行時間+sql解析時間) 太低，表示解析消耗CPU時間過多。

 

 

三 AWR報告分析

分析內容：

1、CPUs、Elapsed、DB Time

2、Load Profile

3、Instance Efficiency Percentages

4、Top 10 Foreground Events by Total Wait Time

5、SQL Statistics

6、Global Cache Load Profile

7、Global Cache Efficiency Percentages

8、Global Cache and Enqueue Services

四 SQL語句分析

1、SQL> explain plan for sql ；

2、SQL>select * from table(dbms_xplan.display_cursor（sql_id）);

3、SQL>@?/rdbms/admin/sqltrpt.sql sql_id

五 Oracle常見等待事件解決方法

Sequential Read：調整相關的索引和選擇合適的驅動行源

Scattered Read：表明出現很多全表掃描。優化code，cache小表到內存中。

Free Buffer：增大DB_CACHE_SIZE，增大checkpoint的頻率，優化代碼; oracle之檢查點（Checkpoint）;數據庫日志用來斷電回滾，日志通過buffer觸發IO寫入磁盤，這個觸發由檢查點來做。

Buffer Busy Segment header：增加freelist或者freelistgroups
Buffer Busy Data block：隔離熱塊；使用反轉索引；使用更小的塊；增大表的initrans
Buffer Busy Undo header：增加回滾段的數量或者大小
Buffer Busy Undo block Commit more：增加回滾段的數量或者大小
Enqueue–ST：使用本地管理的表空間或者增加預分配的盤區大小
Enqueue–HW：在HWM之上預先分配盤區
Enqueue–TX4：在表或者索引上增大initrans的值或者使用更小的塊
Log Buffer Space：增大LOG_BUFFER，改善I/O
Log File Switch：增加或者增大日志文件
Log file sync：減小提交的頻率；使用更快的I/O；或者使用裸設備
Write complete waits：增加DBWR；提高CKPT的頻率；
gc cr/current request：增加帶寬；隔離熱塊；增加LMS進程數；提高磁盤IO
gc cr multi block busy：在RAC層面將應用功能分離
gc buffer busy acquire/release：分區；反向索引；提高SQL效率；將不同應用功能數據分布在不同數據庫實例上
DFS lock handle：增大序列緩存，不使用排序選項

Latch Free：檢查具體的等待latch類型，解決方法如下

 

Library cache：使用綁定變量; 調整shared_pool_size.
Shared pool：使用綁定變量; 調整shared_pool_size.
Redo allocation：減小 redo 的產生； 避免不必要的commits.
Redo copy：增加 _log_simultaneous_copies.
Row cache objects：增加shared_pool_size
Cache buffers chain：增大 _DB_BLOCK_HASH_BUCKETS ； make it prime.
Cache buffers LRU chain：使用多個緩沖池；調整引起大量邏輯讀的查詢

 

TBL$OR$IDX$PART$NUM，這個BUG的主要影響范圍是 12.1.0.1 (Base Release) 和 11.2.0.4。詳情；

__EOF__