ITPub博客

首页 > 数据库 > Oracle > Statspack报告分析—第二部分:Load Profile 负载情况

Statspack报告分析—第二部分:Load Profile 负载情况

Oracle 作者:we6100 时间:2016-01-24 12:17:38 0 删除 编辑

Statspack报告分析第二部分:Load Profile 负载情况

这一部分统计了数据库的负载情况,需要和以前的Statspack的报告进行比较,分析数据库的负载情况是否有所变动。这里的统计数据基本上以每个事务和每秒钟。

[@more@]

Statspack报告分析第二部分:Load Profile 负载情况

这一部分统计了数据库的负载情况,需要和以前的Statspack的报告进行比较,分析数据库的负载情况是否有所变动。这里的统计数据基本上以每个事务和每秒钟。

Load Profile

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

Per Second Per Transaction

--------------- ---------------

Redo size: 21,023.07 5,799.08

Logical reads: 4,649.83 1,282.63

Block changes: 116.86 32.24

Physical reads: 23.56 6.50

Physical writes: 9.47 2.61

User calls: 14.75 4.07

Parses: 8.16 2.25

Hard parses: 0.87 0.24

Sorts: 44.17 12.18

Transactions: 3.63

Rows per Sort: 90.24

Pct Blocks changed / Read: 2.51

Recursive Call Pct: 92.80

Rollback / transaction Pct: 0.45

每秒钟的统计信息展示了在整个统计过程中变化的情况:

l 如果’redo size’, ‘block changes’, ‘pctof blocks changed per read’有显著的增涨,说明系统有更多的insers/updates/deletes操作

l ‘redo size’有增涨,而’transactions per second’没有增涨,说明事务的情况有所变化

同样,看每进程的统计变化情况也可以看出应用的变化。比较2个报告,需要考虑这2个报告的统计时间内系统是否工作在差不多的负载下,如果这2个报告是在完全不同的工作负载下,没有任何比较的意义。

高负载率

如果抛开基准线(baseline,很难来来判定一个系统是否处于非常繁忙的状态。系统处于不同的站点、不同的CPU数量和速度、不同的操作系统、不同的系统IO、不同的Oracle版本下,性能不一样。但是有一些通常的规则:

  • Hard parse 如果高于每秒100个,那么处于一个很高的水准。高级别的hard parse容易引起严重的系统性能问题,必须要解决的。高的hard parse通常会引起shared pool library cachelatch争用。检查latch free是否出现在前五位等待事件中,如果有,检查一下statspack报告中的latch这一节。
  • Soft parse 高的soft parse可能会大于每秒300次。不必要的soft parse也会限制应用的可测量性(scalability, 可以在session中,一个SQL语句只进行一次soft parse,而使用多次。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/27500440/viewspace-1981442/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2014-02-23

  • 博文量
    72
  • 访问量
    268580