statspack系列5
原文：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是什么代码表现这么差。
最新文章
- Request.UrlReferrer
- salesforce 零基础开发入门学习（二）变量基础知识，集合，表达式，流程控制语句
- 在打开vs解决方案时，怎样让所以打开的项目自动折叠
- MongoDB丢数据问题的分析
- iOS Xcode 调试技巧 全局断点这样加才有意思
- [转]无IDE时编译和运行Java
- SrcollView分页加载数据（布局）
- poj1733 带权并查集
- 【Struts 1】Struts1的基本原理和简介
- RUST叫系统编程语言，而GO是网络编程语言
- Qt的Script、Quick、QML的关系与总结
- 《JAVASCRIPT高级程序设计》闭包
- 【Ubuntu Desktop】安装主流桌面
- PHP生成图片验证码、点击切换实例
- 从零开始搭建服务器部署web项目
- css之transform属性
- Sqlserver的身份验证模式
- ansible 远程以普通用户执行命令
- 【Socket】Socket网络编程常用的结构及函数小结
- 【java规则引擎】《Drools7.0.0.Final规则引擎教程》第4章 4.2 no-loop