关于Oracle统计中关于操作系统的统计说明，oracle10个/11g的新特点

《Oracle大型数据库系统在AIXUNIX上的实战详解》集中讨论98, 还是继续大大大前天的话题——对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/