statspack安装使用和report 分析(2)

来源:未知 责任编辑:责任编辑 发表时间:2013-11-15 19:51 点击:

Per Second Per Transaction

Redo size: 431,200.16 18,627,847.04z

Logical reads: 4,150.76 179,312.72

Block changes: 2,252.52 97,309.00

Physical reads: 23.93 1,033.56

Physical writes: 68.08 2,941.04

User calls: 0.96 41.36

Parses: 1.12 48.44

Hard parses: 0.04 1.92

Sorts: 0.77 33.28

Logons: 0.00 0.20

Executes: 2.36 102.12

Transactions: 0.02  

Redo size:每秒产生的重做日志大小(单位字节),可标志数据变更频率, 数据库任务的繁重与否。本例中平均每秒产生了430K左右的重做,每个事务品均产生了18M的重做。

Logical reads:平次每秒产生的逻辑读,单位是block。

block changes:每秒block变化数量,数据库事物带来改变的块数量。

Physical reads:平均每秒数据库从磁盘读取的block数。

Logical reads和Physical reads比较:大约有0.55%的逻辑读导致了物理I/O,平均每个事务执行了大约18万个逻辑读,在这个例子中,有一些大的事务被执行,因此很高的读取数目是可以接受的。

Physical writes:平均每秒数据库写磁盘的block数。

User calls:每秒用户call次数。

Parses和Hard parses:每秒大约1.12个解析,其中有4%为硬解析,系统每25秒分析一些SQL,都还不错。对于优化好的系统,运行了好几天后,这一列应该达到0,所有的sql在一段时间后都应该在共享池中。

Sorts:每秒产生的排序次数。

Executes:每秒执行次数。

Transactions:每秒产生的事务数,反映数据库任务繁重与否。

% Blocks changed per Read: 54.27 Recursive Call %: 86.94

Rollback per transaction %: 12.00 Rows per Sort: 32.59  

% Blocks changed per Read:说明46%的逻辑读是用于那些只读的而不是可修改的块,该系统只更新54%的块。

Rollback per transaction %:事务回滚的百分比。计算公式为:Round(User rollbacks / (user commits + user rollbacks) ,4)* 100%。本例中每8.33个事务导致一个回滚。如果回滚率过高,可能说明数据库经历了太多的无效操作。过多的回滚可能还会带来Undo Block的竞争。

3.实例命中率

该部分可以提前找出ORACLE潜在将要发生的性能问题,很重要。

Instance Efficiency Percentages (Target 100%)

~~~~~~~~~~~~~~~~~~~~

Buffer Nowait %: 100.00 Redo NoWait %: 100.00

Buffer Hit %: 99.42 In-memory Sort %: 100.00

Library Hit %: 98.11 Soft Parse %: 96.04

Execute to Parse %: 52.57 Latch Hit %: 100.00

Parse CPU to Parse Elapsd %: 11.40 % Non-Parse CPU: 99.55

Buffer Nowait %:在缓冲区中获取Buffer的未等待比率,Buffer Nowait<99%说明,有可能是有热块(查找x$bh的tch和v$latch_children的cache buffers chains)。

Redo NoWait %:在Redo缓冲区获取Buffer的未等待比率。

Buffer Hit %:数据块在数据缓冲区中的命中率,通常应在90%以上,否则,小于95%,需要调整重要的参数,小于90%可能是要加db_cache_size,但是大量的非选择的索引也会造成该值很高(大量的db file sequential read)。如果一个经常访问的列上的索引被删除,可能会造成buffer hit 显著下降。如果增加了索引,但是它影响了ORACLE正确的选择表连接时的驱动顺序,那么可能会导致buffer hit 显著增高。如果命中率变化幅度很大,说明需要改变SQL模式。

In-memory Sort %:在内存中的排序率。

发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
用户名: 验证码:点击我更换图片
最新评论 更多>>

推荐热点

  • Table函数使用简介
  • Oracle数据库Constraint约束的常用操作及异常处理
  • Bulk Collect性能分析(zz)
  • export/import的使用
  • OCP043第十五讲 Database Security
  • ORACLE10gr2数据导入MySQL方案
  • oracle 让sys用户可以使用isqlplus
  • 在oracle数据库下使用iSQL*Plus DBA访问数据库
  • Oracle行列转换小结
网站首页 - 友情链接 - 网站地图 - TAG标签 - RSS订阅 - 内容搜索
Copyright © 2008-2015 计算机技术学习交流网. 版权所有

豫ICP备11007008号-1