【丁原】需不需要关注statspack报表
上一篇 /
下一篇 2008-04-17 13:06:10
记得刚来公司面试时，七公和拖雷问我平时是否关注statspack报表，我的回答是很少看。我认识的很多dba也是不监控statspack报表的，可能主要原因是系统太小，根本就没有达到系统的瓶颈，而在数据库运行良好时，你很难会想去干点什么。我之前帮朋友进行数据库调优，也就是根据top 进程找出sql，根据v$sqlarea找到逻辑读，物理读比较大的sql进行调整，创建索引，数据库负载很快就下来了。那到底要不要看statspack报表，从statspack报表中能得到些什么呢？
正赶上这两天报表中有数据有比较大的变动，看报表的信息：
20080220的某个时间段物理读在564/s
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 496,489.45 2,780.34
Logical reads: 32,813.47 183.76
Block changes: 2,771.57 15.52
Physical reads: 564.20 3.16
Physical writes: 283.61 1.59
20080221的同一个时间段物理读猛涨到在1011/s。
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 489,101.56 2,728.04
Logical reads: 31,993.43 178.45
Block changes: 2,774.19 15.47
Physical reads: 1011.27 5.08
Physical writes: 291.96 1.63
-> End Disk Reads Threshold: 1000
CPU Elapsd
Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value
-------------- ------------ -------------- ------ -------- -------
743,374 2 371,687.0 22.7 68.91 2790.50 193894167
Module: java@admin2 (TNS V1-V3)
SELECT a.group_id count(*) counts FROM test_detail a, test_info b, test_entry c, ((select distinct entry_id from test_step where usaciton = 200 and next_id in (10, 238, 239, 120, 121, 122)
对比以上的报表，物理差不多涨了2倍左右，根据报表中抓到的sql语句，这个sql每个小时只执行两次确贡献200/s个物理读，这还不算把buffer cache其他的缓存数据给挤出去的那部分物理读。
好比OS的监控系统，statspack反映的是这个时间段的数据库运行性能指标，通过statspack你能很容易监测到数据库发生的变化，从而进行有效及时的调整。而Statspack看的久了，哪个sql该排在报表的哪个位置都是很清楚的，一有风吹草动很容易看出来，显然对数据库的调优有巨大帮助。
--EOF--
导入论坛
引用链接
收藏
分享给好友
推荐到圈子
管理
举报
TAG:
