解析2

roothomes

=====  <<2>>  實(shí)例負(fù)載檔信息（來源于Statistic）
下面詳細(xì)說明 Load Profile 各項(xiàng)含義
Redo size:每秒產(chǎn)生的日志大小(單位字節(jié))，可標(biāo)志數(shù)據(jù)變更頻率, 數(shù)據(jù)庫任務(wù)的繁重與否。（redo size）
Logical reads:平?jīng)Q每秒產(chǎn)生的邏輯讀的block數(shù)。（session logical reads）Logical Reads= Consistent Gets + DB Block Gets
Block changes:每秒block變化數(shù)量，數(shù)據(jù)庫事物帶來改變的塊數(shù)量。（db block changes）
Physical reads:平均每秒數(shù)據(jù)庫從磁盤讀取的block數(shù)。（physical reads）
Physical writes:平均每秒數(shù)據(jù)庫寫磁盤的block數(shù)。（physical writes）
User calls:每秒用戶調(diào)用次數(shù)。（user calls）
Parses:每秒解析次數(shù)，包括fast parse，soft parse和hard parse三種數(shù)量的綜合。 軟解析每秒超過300次意味著你的"應(yīng)用程序"效率不高，調(diào)整session_cursor_cache。在這里，fast parse指的是直接在PGA中命中的情況（設(shè)置了session_cached_cursors=n）；soft parse是指在shared pool中命中的情形； hard parse則是指都不命中的情況。（parse count (total)）
Hard parses:每秒產(chǎn)生的硬解析次數(shù), 每秒超過100次，就可能說明你綁定使用的不好，也可能是共享池設(shè)置不合理。這時(shí)候可以啟用參數(shù)cursor_sharing=similar|force，該參數(shù)默認(rèn)值為exact。但該參數(shù)設(shè)置為similar時(shí)，存在bug，可能導(dǎo)致執(zhí)行計(jì)劃的不優(yōu)。（parse count (hard)）
Sorts:每秒產(chǎn)生的排序次數(shù)。（sorts (disk) + sorts (memory)）
Logons:每秒登陸的次數(shù)。（logons cumulative）
Executes:每秒執(zhí)行次數(shù)。（execute count）
Transactions:每秒產(chǎn)生的事務(wù)數(shù)，反映數(shù)據(jù)庫任務(wù)繁重與否。（user commits + user rollbacks）
% Blocks changed per Read：在每一次邏輯讀中更改的塊的百分比。
Rollback per transaction %:看回滾率是不是很高，因?yàn)榛貪L很耗資源 ,如果回滾率過高,可能說明你的數(shù)據(jù)庫經(jīng)歷了太多的無效操作 ,過多的回滾可能還會(huì)帶來Undo Block的競爭 該參數(shù)計(jì)算公式如下: Round(User rollbacks / (user commits + user rollbacks) ,4)* 100% 。
Recursive Call %:遞歸調(diào)用的百分比，如果有很多PL/SQL，那么這個(gè)值就會(huì)比較高。
Rows per Sort:平均每次排序操作的行數(shù)。