使用Statspack的几个误区
2008-04-27 10:18
330 查看
使用Statspack的几个误区
作者:Fenng
Statspack是提供的一个实例级的Tuning工具。很多DBA都喜欢用这个工具来进行的优化调
整。不过在交流中发现很多朋友对这个工具的的运用还有一些问题。下面就其中比较容易出问题的几个方面进
行一下简单的分析。
关于快照的采样时间间隔问题
我们知道,Statspack的report实际上也就是对比两个快照(Snapshot,也就是数据库当前状态)得出的结
果。
一般情况下,专家建议生成Statspack报告的快照时间间隔为15-30分钟。
试想,一个人去医院看病,医生对其测量体温,一般也就是5-10分钟左右就可以了,为什么是这麽长的时间?
因为5-10分钟这段时间基本可以近似的得到你的体温。如果时间过短,可能达不到既定的目的,测到的体温会
偏低,时间过长,甚至长达几个小时的话(假设有这种情况),病人可能都昏迷几次了;)。
对生成Statspack报告的快照时间间隔也是这样,如果两个SnapTime时间过短,数据库的一些主要周期性
事务可能还没有运行,信息收集不完全。如果间隔过长,数据一样会有偏差。
假设如下的情况:系统一直正常,但是最近几天有用户反映,在A时间段应用程序执行很慢。B时间段正常,而
A时间段有一个主要的事务X运行(也是用户使用到的事务)。B时间段有另外一个比较消耗资源的事务Y在运
行。A和B时间段的跨度比较大。本来你的快照如果覆盖A时间段内就已经能够的收集到比较准确的数据了,但
不巧的是,你的Report所用的两个SnapID的时间跨度太长,从而把B时间段内的统计数据也收集了进来。
Statspack经过比较,“认为”事务Y是对系统有主要影响(这也会在Report上体现出来),而你,经过分析,认
为Y才是罪魁祸首,接下来,你不遗余力的对Y进行了tuning......
问题出现了!调整了B之后,用户继续报告,A时间段内系统不但没有变快,反而变得更慢,甚至不可忍受。这
种情况是很危险的,可能会对系统造成不同程序的损害。在比较严格的环境中,这已经构成了一次比较严重的
事故。
或许你也要承认,Statspack的快照的采样时间间隔还真需要重视呢......
这是一个Oracle 8.1.7.0.1 版本下的Statspack报告:
SnapIdSnapTimeSessions
---------------------------------
BeginSnap:63704-Aug-0311:59:3325
EndSnap:64604-Aug-0316:29:0625
Elapsed:269.55(mins)
从中可以看到快照637和快照646之间为269.55(mins)。这么长的时间跨度,即使数据库在一定时间间隔内
有问题,在这里的体现也会有偏差。
下面的这个Statspack报告的时间有点不靠谱了:
SnapLength
StartIdEndIdStartTimeEndTime(Minutes)
-------------------------------------------------------------------
314105311-Dec-0318:07:1319-Dec-0310:53:0211,085.82
11,085.82分钟?这么长时间内的数据采集分析,怕是绝大部分内容都是不能相信的了。
还要注意的是,我们说的时间间隔,是BeginSnap和EndSnap之间的间隔,而不是相邻两个Snap之间的
间隔。对于Snap收集的间隔,建议以不要影响性能为准,收集的太过于频繁,会对性能和存储都造成压力。
对于所谓的15-30分钟,不能墨守成规。具体的环境下应该加以调整。
以偏概全
Statspack从本质上说,是对系统的性能统计数据进行采样,然后进行分析,采样,就会有偏差。如何消除偏
差?统计学指出"差值随样品个数的增加而降低"。所以,只凭借一个Report文档就断定数据库的性能问题出
在某处,是比较武断的做法(个别情况除外)。还要DBA多创建Report,对比进行分析,会起到很好的效果。共2页 1
作者:Fenng
Statspack是提供的一个实例级的Tuning工具。很多DBA都喜欢用这个工具来进行的优化调
整。不过在交流中发现很多朋友对这个工具的的运用还有一些问题。下面就其中比较容易出问题的几个方面进
行一下简单的分析。
关于快照的采样时间间隔问题
我们知道,Statspack的report实际上也就是对比两个快照(Snapshot,也就是数据库当前状态)得出的结
果。
一般情况下,专家建议生成Statspack报告的快照时间间隔为15-30分钟。
试想,一个人去医院看病,医生对其测量体温,一般也就是5-10分钟左右就可以了,为什么是这麽长的时间?
因为5-10分钟这段时间基本可以近似的得到你的体温。如果时间过短,可能达不到既定的目的,测到的体温会
偏低,时间过长,甚至长达几个小时的话(假设有这种情况),病人可能都昏迷几次了;)。
对生成Statspack报告的快照时间间隔也是这样,如果两个SnapTime时间过短,数据库的一些主要周期性
事务可能还没有运行,信息收集不完全。如果间隔过长,数据一样会有偏差。
假设如下的情况:系统一直正常,但是最近几天有用户反映,在A时间段应用程序执行很慢。B时间段正常,而
A时间段有一个主要的事务X运行(也是用户使用到的事务)。B时间段有另外一个比较消耗资源的事务Y在运
行。A和B时间段的跨度比较大。本来你的快照如果覆盖A时间段内就已经能够的收集到比较准确的数据了,但
不巧的是,你的Report所用的两个SnapID的时间跨度太长,从而把B时间段内的统计数据也收集了进来。
Statspack经过比较,“认为”事务Y是对系统有主要影响(这也会在Report上体现出来),而你,经过分析,认
为Y才是罪魁祸首,接下来,你不遗余力的对Y进行了tuning......
问题出现了!调整了B之后,用户继续报告,A时间段内系统不但没有变快,反而变得更慢,甚至不可忍受。这
种情况是很危险的,可能会对系统造成不同程序的损害。在比较严格的环境中,这已经构成了一次比较严重的
事故。
或许你也要承认,Statspack的快照的采样时间间隔还真需要重视呢......
这是一个Oracle 8.1.7.0.1 版本下的Statspack报告:
SnapIdSnapTimeSessions
---------------------------------
BeginSnap:63704-Aug-0311:59:3325
EndSnap:64604-Aug-0316:29:0625
Elapsed:269.55(mins)
从中可以看到快照637和快照646之间为269.55(mins)。这么长的时间跨度,即使数据库在一定时间间隔内
有问题,在这里的体现也会有偏差。
下面的这个Statspack报告的时间有点不靠谱了:
SnapLength
StartIdEndIdStartTimeEndTime(Minutes)
-------------------------------------------------------------------
314105311-Dec-0318:07:1319-Dec-0310:53:0211,085.82
11,085.82分钟?这么长时间内的数据采集分析,怕是绝大部分内容都是不能相信的了。
还要注意的是,我们说的时间间隔,是BeginSnap和EndSnap之间的间隔,而不是相邻两个Snap之间的
间隔。对于Snap收集的间隔,建议以不要影响性能为准,收集的太过于频繁,会对性能和存储都造成压力。
对于所谓的15-30分钟,不能墨守成规。具体的环境下应该加以调整。
以偏概全
Statspack从本质上说,是对系统的性能统计数据进行采样,然后进行分析,采样,就会有偏差。如何消除偏
差?统计学指出"差值随样品个数的增加而降低"。所以,只凭借一个Report文档就断定数据库的性能问题出
在某处,是比较武断的做法(个别情况除外)。还要DBA多创建Report,对比进行分析,会起到很好的效果。共2页 1
相关文章推荐
- 使用Statspack的几个误区
- sizeof使用中的几个误区总结
- 电脑使用中的几个误区
- 几个字符串的误区,以及setlocale函数的使用
- 使用MVC模型的几个常见误区
- PROTEL软件使用的误区及几个不易搞清的概念
- 使用MVC模型的几个常见误区
- 电脑使用中的几个误区
- PROTEL软件使用的误区及几个不易搞清的概念
- 抄书:C语言中字符类型使用中的几个误区
- 使用MVC模型的几个常见误区 【转载】Li XianJing
- ios开发UI系列之使用AutoLayout的几个经典的布局技巧
- statspack安装,基本使用
- 随机数的使用的几个方法
- [转]NoSQL数据库Redis几个认识误区
- jquery easyui dialog的几个使用问题
- [转]web标准的几个误区
- 使用异常处理语句需要注意的几个问题
- 关于function中使用this的误区
- java.io 流的几个对象以及方法属性的使用