使用Statspack的几个误区_数据库

使用Statspack的几个误区

发表于：2007-06-08来源：作者：点击数：标签：

使用Statspack的几个误区作者: Fenng Statspack 是 Oracle 提供的一个实例级的Tuning工具。很多DBA都喜欢用这个工具来进行数据库的优化调整。不过在交流中发现很多朋友对这个工具的的运用还有一些问题。下面就其中比较容易出问题的几个方面进行一下简

使用Statspack的几个误区

作者: Fenng

Statspack 是 Oracle 提供的一个实例级的Tuning工具。很多DBA都喜欢用这个工具来进行数据库的优化调
整。不过在交流中发现很多朋友对这个工具的的运用还有一些问题。下面就其中比较容易出问题的几个方面进
行一下简单的分析。

关于快照的采样时间间隔问题

我们知道，Statspack的report实际上也就是对比两个快照 (Snapshot，也就是数据库当前状态 ) 得出的结
果。

一般情况下，专家建议生成Statspack报告的快照时间间隔为15-30分钟。

试想，一个人去医院看病，医生对其测量体温，一般也就是5-10分钟左右就可以了，为什么是这麽长的时间？
因为5-10分钟这段时间基本可以近似的得到你的体温。如果时间过短，可能达不到既定的目的，测到的体温会
偏低，时间过长，甚至长达几个小时的话(假设有这种情况)，病人可能都昏迷几次了 ;) 。

对生成Statspack报告的快照时间间隔也是这样，如果两个Snap Time时间过短，数据库的一些主要周期性
事务可能还没有运行，信息收集不完全。如果间隔过长，数据一样会有偏差。

假设如下的情况：系统一直正常，但是最近几天有用户反映，在A时间段应用程序执行很慢。B时间段正常，而
A时间段有一个主要的事务X运行（也是用户使用到的事务）。 B时间段有另外一个比较消耗资源的事务Y在运
行。A和B时间段的跨度比较大。本来你的快照如果覆盖A时间段内就已经能够的收集到比较准确的数据了，但
不巧的是，你的Report 所用的两个Snap ID的时间跨度太长，从而把B时间段内的统计数据也收集了进来。
Statspack 经过比较，“认为”事务Y是对系统有主要影响(这也会在Report上体现出来)，而你，经过分析，认
为Y才是罪魁祸首，接下来，你不遗余力的对Y进行了tuning......

问题出现了！调整了B之后，用户继续报告，A时间段内系统不但没有变快，反而变得更慢，甚至不可忍受。这
种情况是很危险的，可能会对系统造成不同程序的损害。在比较严格的环境中，这已经构成了一次比较严重的
事故。

或许你也要承认，Statspack的快照的采样时间间隔还真需要重视呢......

这是一个Oracle　8.1.7.0.1　版本下的Statspack报告：


  
                 Snap Id     Snap Time      Sessions 
                 ------- ------------------ -------- 
  Begin Snap:        637 04-Aug-03 11:59:33       25 
    End Snap:        646 04-Aug-03 16:29:06       25 
     Elapsed:                 269.55 (mins)

从中可以看到快照637和快照646之间为269.55 (mins)。这么长的时间跨度，即使数据库在一定时间间隔内
有问题，在这里的体现也会有偏差。　

下面的这个Statspack 报告的时间有点不靠谱了：

 
                                                                   Snap Length
Start Id    End Id       Start Time             End Time          (Minutes)    
--------  --------  --------------------  --------------------  -----------   
     314      1053  11-Dec-03 18:07:13    19-Dec-03 10:53:02      11,085.82

原文转自：http://www.ltesting.net

软件测试 > 测试开发技术 > 软件测试开发语言 > 数据库 >