Oracle 10g自动工作负载信息库剖析

核心提示： 下面我们看看 CPU 时间是如何消耗的（以厘秒为单位），标准差加入到了我们的分析中，Oracle 10g自动工作负载信息库剖析(3)，它有助于确定平均数字是否反映了实际的工作负载，在第一条记录中，它主动地分析数据并生成建议，从而把您解放出来，平均值是每秒消耗 CPU 时间 3 厘秒，但标准

下面我们看看 CPU 时间是如何消耗的（以厘秒为单位）。标准差加入到了我们的分析中，它有助于确定平均数字是否反映了实际的工作负载。在第一条记录中，平均值是每秒消耗 CPU 时间 3 厘秒，但标准差是 9.81，这意味着平均值 3 不能反映工作负载。在第二个例子中，平均值为 28，标准差为 5.9，这更具有代表性。这种类型的信息趋势有助于了解几个环境参数对性能量度的影响。

使用统计数据

迄今为止，我们看到了 AWR 所采集的内容，现在让我们看看它将如何处理数据。

大多数性能问题并不是孤立存在的，而留有指示性的迹象，这些迹象将通向问题最终的根源。让我们使用一个典型的调整实践来说明这一点：您注意到系统很慢，于是决定查看等待的原因。您检查发现“缓冲区忙等待”非常高。问题可能出在哪里呢？有几种可能：可能有一个单调增加的索引，可能一个表太满了，以至于要求将单个数据块非常快速地加载到内存中，或其它一些因素。无论在哪种情况下，您都首先要确定存在问题的段。如果它是一个索引段，那么您可以决定重新构建它，把它修改为一个反向键索引，或把它转换成一个在 Oracle Database 10g 中引进的散列分区索引。如果它是一个表，您可以考虑修改存储参数来使它不那么密集，或者利用自动段空间管理把它转移到一个表空间中。

您的处理计划一般是有规律的，并且通常基于您对各种事件的了解和您处理它们的经验。现在设想相同的事情由一个引擎来完成，这个引擎采集量度并根据预先确定的逻辑来推出可能的计划。您的工作不就变得更轻松了吗？

现在在 Oracle Database 10g 中推出的这个引擎称为自动数据库诊断监控程序 (ADDM)。为了作出决策，ADDM 使用了由 AWR 采集的数据。在上面的讨论中，ADDM 可以看到发生了缓冲区忙等待，然后取出相应的数据来查看发生缓冲区忙等待的段，评估其特性和成分，最后为数据库管理员提供解决方案。在 AWR 进行的每一次快照采集之后，调用 ADDM 来检查量度并生成建议。因此，实际上您拥有了一个一天二十四小时工作的自动数据库管理员，它主动地分析数据并生成建议，从而把您解放出来，使您能够关注更具有战略意义的问题。