解析2

roothomes

=====  <<2>>  实例负载档信息（来源于Statistic）
下面详细说明 Load Profile 各项含义
Redo size:每秒产生的日志大小(单位字节)，可标志数据变更频率, 数据库任务的繁重与否。（redo size）
Logical reads:平决每秒产生的逻辑读的block数。（session logical reads）Logical Reads= Consistent Gets + DB Block Gets
Block changes:每秒block变化数量，数据库事物带来改变的块数量。（db block changes）
Physical reads:平均每秒数据库从磁盘读取的block数。（physical reads）
Physical writes:平均每秒数据库写磁盘的block数。（physical writes）
User calls:每秒用户调用次数。（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则是指都不命中的情况。（parse count (total)）
Hard parses:每秒产生的硬解析次数, 每秒超过100次，就可能说明你绑定使用的不好，也可能是共享池设置不合理。这时候可以启用参数cursor_sharing=similar|force，该参数默认值为exact。但该参数设置为similar时，存在bug，可能导致执行计划的不优。（parse count (hard)）
Sorts:每秒产生的排序次数。（sorts (disk) + sorts (memory)）
Logons:每秒登陆的次数。（logons cumulative）
Executes:每秒执行次数。（execute count）
Transactions:每秒产生的事务数，反映数据库任务繁重与否。（user commits + user rollbacks）
% 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:平均每次排序操作的行数。