原文：http://jonathanlewis.wordpress.com/2006/12/27/analysing-statspack-5/
作者：Jonathan Lewis
前些天，有人给我发了封邮件，附上了一份10g版本的statpack报告，因为开发人员抱怨系统很慢，但是从statpack的报告上又完全看不出有什么高负载的迹象。
报告头信息显示，机器有4颗cpu，30分钟的快照的信息显示系统非常的空闲
To paraphrase Cary Millsap：如果你不能从汇总的数据中推断一些有用的信息，那么面对开发人员时你只能说：“你认为系统慢--证明给我看”， 然后再跟踪一下他们的行为。
不过，也会有很多情况，汇总的数据也会表现出来一些迹象，至少在一定程度上让你有机会做一个相对好的猜测。
看下面的信息，第一部分是”TOP SQL by cpu”。第二部分是“Instance Activity”；
从上面的信息可以看出两个问题，4个相似的delete语句可能被一个delete_something的过程所调用，（一个接一个的，可能是执行一个cursor，然后进行循环操作）。
接着再看tablescans和物理读：13,368个s的短表tablescans，和110M个blocks扫描。因为仅仅只有一个长表的扫描，和46,000个物理读，所以基本可以推断出大部分的“table scan blocks gotten“来自于短表的扫描，这意味着每次大约8,000 blocks。简单的计算得出每次短表扫描大约640,000行数据。
所以，当前系统有大约13,368次代价非常高的表扫描，并且delete_something过程占了大约8,600个。考虑到每次delete操作仅仅一行，却耗费了大量的开销。
可以打赌，开发所谓的系统慢的情况，肯定是指这个过程比较慢，毕竟，系统好像在这个时间段仅仅只有这个任务在运行。
似乎目标表有结构性的问题，可能类似于缺少索引这样的情况，或者说是索引存在，但是统计信息误导了，也或是绑定变量传入的类型不一致导致了隐式转换，使索引变得不可用。
无论怎么样，汇总的数据还是给出了一些有价值的信息，帮助问题的定位和解决。
警示：
尽管粗略的检查statpack报告得出了极其明显的资源占用，但还是有其它的地方看起来开销比比较大（比如最后一个sql语句）。可能我的分析是正确的，但跟具体开发的抱怨已经关系不大了。
另一方面，定位这个问题其实不需要很久，可以很容易的拿着这个statpack报告跟开发一起review是什么代码表现这么差。