ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 对Oracle性能统计中的数据解释

对Oracle性能统计中的数据解释

原创 Linux操作系统 作者:wenpingblog 时间:2010-01-24 19:22:59 0 删除 编辑

《Oracle大型数据库系统在AIXUNIX上的实战详解》集中讨论19, 还是继续大大大前天的话题——对Oracle性能统计中的数据解释


从前面得到的统计数据,我们可以看出这样一个问题:当大量数据摆在你面前,很多数据表现出模棱二可的状态,你如何从中找到能反映出问题的数据,并确保其是对的?没有别的分方法,只有再去印证其他数据或统计,交叉检查、互相印证正确性。

 

下面是一些常见误解和易被想当然的若干点:

 

关于命中率的想当然:

很多时候,命中率可以给我们一些提示,并用来表明问题,例如,数据高速缓存命中率、SQL软解析比率等。但他们能够确定问题所在位置吗?不能贸然的下结论说这里就是瓶颈!正确的态度是:这是一个提示,可以用来佐证“某个问题”是瓶颈。

 

带有时间信息的等待事件:

 

当我们将Oracle的TIMED_STATISTICS 参数值设置为true(这就是默认值)时,等待事件的统计值中将包含时间信息。我们知道,统计数据的绝对值是没有意义的,我们比较的是可对比时间段内的不同或者增量。很多时候这个统计没有意义。例如,经过统计我们发现某一个等待事件的值相比其他等待事件是很高的,那么,瓶颈就是它吗?不一定!这个需要分为二种情况。其一,如果这个等待事件的时间统计累积值占据了整个DB time的大多数,则他很有可能就是瓶颈所在。但是,如果该等待事件累积时间很高,但和整体DB time相比,却只占了其中很小部分,则该等待事件可能说明不了任何问题。

 

特别说明:如果初始化参数STATISTICS_LEVEL 设置为TYPICAL(默认值)或者ALL ,则时间统计自动打开。如果STATISTICS_LEVEL 设置为BASIC ,则我们必须手工将TIMED_STATISTICS设置为TRUE ,才能实现包含时间统计数据的收集。

 

另外,如果我们明确设置了DB_CACHE_ADVICE、TIMED_STATISTICS或者TIMED_OS_STATISTICS ,则我们为STATISTICS_LEVEL设置的参数值失效。


Oracle统计数据能否反映事实?

 

当查看统计数据时,我们要考虑统计数据的真实度,也就是说,该数据能否反映这个系统真正的问题。例如,当统计数据说明系统每秒处理10个事务时,我们不说说这个系统载荷很轻。为什么呢?因为统计期间可能发生的半夜,这的时间段根本就没有业务产生。反之,我们看到数据缓存命中率很低,也许我们也不能说应用系统内存使用有问题。原因也很简单:统计期间,可能系统刚开机不久。

 

那什么数据才是真实的?这里有一个同样模糊的回答:经过你综合考虑过的统计数据是真实的!

 

没有时间统计等待事件的可用性

 

如果系统TIMED_STATISTICS 参数设置为false,也就是不进行时间统计(在生产系统上这是普遍存在的设置,因为设置该参数为真则本身就会给系统带来负的性能影响),那么含有时间信息的等待事件的时间统计不可用。这时,我们只能简单地对等待事件发生数量进行排序,掌握那个等待事件发生次数最多、次多、再次多…。发生次数最多的等待事件是主要瓶颈吗?也许是,是因为它发生的次数很多。不是主要瓶颈吗?有可能,因为等待次数最多的等待时间未必最长。所以,在可能的情况下,激活时间统计(设置TIMED_STATISTICS 参数为true)很有帮助。在Oracle中,该参数默认为true。

 

空闲等待事件

 

Oracle使用等待事件来表明一个Oracle服务器进程是否是空闲的。一般而言,这些等待对于性能调整问题没什么用处。

 

汇总过的统计数据

 

在我们使用“率”这个增强型统计的时候,例如,数据缓存命中率的时候,要注意经过汇总的数据可能带来误解。什么是“率”,分子分母间除的操作。我们获取某一个“率”,例如:50%,它说明了什么呢?可能是50/100,也可能是50000/100000。这完全是二个数量级之间的差异。因此,同样的比率,解读确是不同的。一个可能是:我需要查询100个数据块,其中50个可以来源于数据缓存,命中率50%。另一个解释是:我要访问100000个数据块(100000*8K≈800M),其中50000个块在数据缓存中(≈400M)!显然,就第一种解读来说,50%的命中率是不需要调整的,但就第二种解读来说,50%命中率可能不能接受,要么去改SQL语句(甚至连带进行应用业务上的调整),要么去改索引结构,优化SQL执行路径。总之,要有所为了。

 

因此,就统计数据而言,不应该局限在某个或某组统计数据中洋洋自得,并据此认为已经找到问题根源,实际情况是:可能还有距离!

 

未完,待续, 文平

参见Oracle联机文档中的“性能”那本书,以及 http://www.usedb.cn/

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/22363020/viewspace-625882/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
暂无介绍

注册时间:2009-08-17

  • 博文量
    39
  • 访问量
    398740