Statspack报告分析—第二部分：Load Profile 负载情况
这一部分统计了数据库的负载情况，需要和以前的Statspack的报告进行比较，分析数据库的负载情况是否有所变动。这里的统计数据基本上以每个事务和每秒钟。
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 cache的latch争用。检查latch free是否出现在前五位等待事件中，如果有，检查一下statspack报告中的latch这一节。
- Soft parse ： 高的soft parse可能会大于每秒300次。不必要的soft parse也会限制应用的可测量性（scalability）, 可以在session中，一个SQL语句只进行一次soft parse，而使用多次。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/27500440/viewspace-1981442/ ，如需转载，请注明出处，否则将追究法律责任。
