awr報表解讀

[img]

[list]

[*]redo size:每秒產生的日誌大小(單位位元組)，可標誌資料變更頻率, 資料庫任務的繁重與否

[*]logical reads:平決每秒產生的邏輯讀的block數。logical reads= consistent gets + db block gets.邏輯讀大小可以看出資料庫消耗的系統資源，特別是cpu資源的情況，邏輯讀越大的系統消耗cpu也越高。

[*]block changes:每秒block變化數量，資料庫事務帶來改變的塊數量。

[*]physical reads:平均每秒資料庫從磁碟讀取的block數。物理讀的值越高，說明系統對於i/o的負載越大，如果某個系統的物理讀突然變高。就要查查是不是某個應用走了全表掃瞄了。

[*]physical writes:平均每秒資料庫寫磁碟的block數。

[*]user calls:每秒使用者呼叫次數。

[*]parses:每秒解析次數，包括fast parse，soft parse和hard parse三種數量的綜合。軟解析每秒超過300次意味著你的"應用程式"效率不高，調整session_cursor_cache。在這裡，fast parse指的是直接在pga中命中的情況（設定了session_cached_cursors=n）；soft parse是指在shared pool中命中的情形；hard parse則是指都不命中的情況。硬分析的數量。

[*]hard parses:每秒產生的硬解析次數, 每秒超過100次，就可能說明你繫結使用的不好，也可能是共享池設定不合理。這時候可以啟用引數cursor_sharing=similar|force，該引數預設值為exact。但該引數設定為similar時，存在bug，可能導致執行計畫的不優。

[*]sorts:每秒產生的排序次數。

[*]logons:每秒登陸的次數。

[*]executes:每秒sql執行次數。

[*]transactions:每秒產生的事務數，反映資料庫任務繁重與否。

[*]% blocks changed per read：在每一次邏輯讀中更改的塊的百分比。

[*] rollback per transaction %:看回滾率是不是很高，因為回滾很耗資源 ,如果回滾率過高,可能說明你的資料庫經歷了太多的無效操作 ,過多的回滾可能還會帶來undo block的競爭該引數計算公式如下: round(user rollbacks / (user commits + user rollbacks) ,4)* 100% 。

[*] recursive call %:遞迴呼叫的百分比，如果有很多pl/sql，那麼這個值就會比較高。

[*]rows per sort:平均每次排序操作的行數。

[/list]

2.enq: tx - row lock contention

[quote]優化碰到的第乙個wait event

enq是一種保護共享資源的鎖定機制，乙個排隊機制，先進先出(fifo)

發生tx鎖的原因一般有幾個

1.不同的session更新或刪除同乙個記錄。

2.唯一索引有重複索引

3.點陣圖索引多次更新

4.同時對同乙個資料塊更新

5.等待索引塊**

通過資料系統檢視檢查果然是多個update的sql

select sid,username,event from v$session where stat in('waiting') and wit_class!='idle';

sid從上面的sql獲得

select sid,sql_text from v$session a,v$sql b where sid in(282,496) and (b.sql_id=a.sql_id or b.sql_id=a.prev_sql_id);

[/quote]

awr報表解讀

AWR報告解讀

AWR報告分析解讀

非流動資產（財務報表解讀）

awr報表解讀

AWR報告解讀

AWR報告分析解讀

非流動資產（財務報表解讀）

相關推薦