Automatic Performance Diagnosis and Tuning in Oracle

一、摘要

现代数据库系统的性能调优需要大量的专业知识，非常耗费时间，而且经常被误导。调优的尝试往往缺乏一种对数据库有整体看法的方法。缺乏历史诊断信息来调查首次出现的性能问题，这加剧了整个调优过程，往往需要在正确诊断之前再现问题。
在本文中，我们描述了Oracle如何克服这些挑战，并提供了一种执行自动性能诊断和调整的方法。我们定义了一个名为 “数据库时间 “的新措施，它提供了一种通用的货币来衡量数据库中任何资源或活动的性能影响。我们解释了自动数据库诊断监控器（ADDM）如何自动诊断影响数据库总吞吐量的瓶颈，并提供可操作的建议来缓解它们。我们还描述了执行ADDM分析所需的性能测量类型。最后，我们展示了ADDM如何在Oracle 10g的可管理性框架中发挥核心作用，对数据库进行自治并提供全面的调优解决方案。

二、介绍

​ DBA需要大量的专业经验来进行数据库系统的问题诊断和调休，但更多的时候是通过加日志和复现来处理，这通常很花时间并且是毫无头绪的，并且对数据库的侵入性比较大，开销显著。另一个导致诊断困难的原因是因为数据库不同组件的性能往往有多个指标，比如Buffer 命中率、每秒事务数、平均IO延迟等等，所以更需要从整个数据库的视角上来看，实际操作中这个很难做到的。

​ 在Oracle 10g版本是，Oracle做了一个自动化的数据库诊断监视器(ADDM)来实现数据库的自动化诊断，并且提出调优建议，调优的主要目的是最大化总数据库的吞吐量。总理来说，ADDM要实现的目标有以下四个：

• 从整个数据库的视角上去看待问题，有数据库的整体视图
• 能够自动化分析性能问题，并且找到原因
• 在遇到性能问题(包括首次遇到)时，能够合理的提出建议
• 诊断的策略需要方便进行变化

三、相关工作

​ COMFORT项目使用了一个在线反馈控制回路来解决个别的调优问题，自动调优系统也被提出。一些人建议简化数据库功能对自动调优至关重要。Oracle之前的性能调优解决方案是Statspack，Oracle 9i和10g有自我优化功能。IBM DB2 8.1版和SQL Server 2000也有性能工具用于监控和实现个人目标。市面上的数据库有自动管理一些子组件的功能，也有让DBA更容易实现特定性能目标的工具，但没有一个（直到Oracle 10g）有自动识别问题的性能诊断和调优解决方案。

四、自动化性能诊断

数据库的各个组成部分的性能是用不同的指标来衡量的。例如，数据块缓冲区缓存的效率用缓冲区命中率的百分比来表示；I/O子系统用平均读写延迟来衡量；数据库的吞吐量用每秒的交易量来衡量。然而，使用这些指标，找到一个特定组件对整个数据库吞吐量的性能影响是非常困难的，甚至是不可行的。例如，如果平均I/O延迟变成两倍，确定每秒钟事务量会减少多少并不是一件小事。

这个项目的首要目标之一是定义一种通用的指标，可以用来衡量数据库内任何组件的性能影响。这样就有可能比较任何两个数据库组件的影响。例如，我们就可以比较由于数据块缓冲区缓存大小不足而造成的性能影响和由于SQL语句写得不好而造成的性能影响。为此，我们定义了一个叫做 “DB time”的衡量标准，它可以作为一种通用指标。

4.1 DB time

数据库时间被定义为在数据库内处理用户请求的时间之和。图1展示了一个单一用户提交请求的简单场景。用户的响应时间是指从发送请求的瞬间到收到响应的瞬间的时间间隔。该用户请求所涉及的数据库时间只是该用户在数据库内的响应时间的一部分。

图2说明了数据库时间，因为它是多个用户的总和，每个用户都在进行一系列的操作，导致对数据库的一系列请求。从图2可以看出，数据库时间与用户请求的数量和持续时间成正比，可以高于或低于相应的挂钟时间。

使用数据库时间作为衡量标准，人们应该能够衡量数据库的任何实体的性能影响。例如，一个大小不足的缓冲区缓存对性能的影响将被衡量为执行额外的I/O请求所花费的总的数据库时间，如果缓冲区缓存更大的话，这些时间是可以避免的。

数据库时间是对数据库所做工作总量的测量（类似于物理学中用来测量能量或所做工作的SI单位 “焦耳”），数据库时间的消耗率是数据库的平均负载，类似于操作系统的平均负载（以 “数据库时间”/秒测量，这个单位类似于物理学中用来测量功率的SI单位 “瓦特 “或 “焦耳/秒”）。ADDM的目标是减少在特定工作负载上花费的数据库时间，这类似于消耗更少的能量来执行相同的任务。识别对数据库时间贡献最大的组件，相当于找到一个单一的数据库组件，当它被调整时将提供最大的好处。换句话说，如果我们寻找方法来处理一组给定的用户请求，同时消耗最少的数据库时间，我们只是在寻找完成给定任务的最有效方法。
ADDM使用数据库时间来识别需要调查的数据库组件，也可以量化性能瓶颈。
数据库系统经常有一些模型或机制，比如后台进程或并行查询，其中数据库时间的定义更为复杂。在第5节中，我们讨论这些模型的数据库时间定义。

4.2 DBTime-graph 和 ADDM方法

自动性能调优的第一步是正确识别性能问题的原因。只有正确识别了性能问题的根源，才有可能探索出有效的调优建议来解决或缓解这个问题。ADDM从两个独立的维度来观察数据库的时间。

• 第一个维度是看数据库在处理用户请求的各个阶段所花费的时间。这个维度包括 “连接到数据库”，”优化SQL语句 “和 “执行SQL语句 “等类别。
• 第二个维度关注的是在处理用户请求时使用或等待各种数据库资源所花费的数据库时间。在这个维度中考虑的数据库资源包括硬件资源，如CPU和I/O设备，以及软件资源，如数据库锁和应用程序锁。

关于我们如何实际测量花在这里提到的各种类别的数据库时间的详细分析，请参考第4节。

为了进行自动诊断，ADDM在这两个维度下查看每个类别花费的数据库时间，并深入到消耗了大量数据库时间的类别。这个二维钻取过程可以用图3所示的有向环形图来表示，我们称之为 “DBTime-graph”。

应该注意的是，这个DBTime-graph并不是基于规则的诊断系统的决策树，在该系统中，一组规则被组织成决策树的形式，并且树被遍历以找到给定的特定数据集的目标或找到给定的特定目标的数据[BE03] 。DBTime-graph具有各种属性，使其区别于基于规则的决策树。

• 这个图中的每个节点都是由一个特定的数据库组件或资源所消耗的数据库时间量。
• 这个图中的所有节点都用相同的衡量标准–数据库时间来衡量。
• 只要在某一节点上花费的数据库时间是显著的，该节点的所有子节点都会被无条件地探查。
• 归属于一个特定节点的数据库时间应该完全包含在归属于其每个父节点的数据库时间中。

任何符合上述所有属性的节点都可以被添加到DBTime-graph中，使得它很容易随着技术的变化而维护，这与基于规则的诊断系统的决策树不同[BE03]。

性能问题往往将数据库的时间归结为一个维度的许多类别，而不是另一个维度。例如，一个CPU容量不足的数据库会减慢处理用户请求的所有阶段，这就是ADDM的第一个维度。

然而，从第二个维度可以看出，影响数据库的首要性能问题是CPU容量不足。这种从两个维度看数据库时间被消耗的地方，给了ADDM一个非常好的判断，可以放大到更重要的性能问题。

ADDM从根节点开始探索这个DBTime-graph，如果组件消耗的数据库时间很重要，则探索该节点的所有子节点。该图中的分支节点确定了通常是一些性能瓶颈的症状的性能影响。而终端节点则确定了特定的根源，可以解释沿着到达终端节点的路径上的所有重要症状。例如，在图3中，分支节点 “I/O容量 “将测量数据库在所有I/O请求中所花费的时间，这可能是由于各种瓶颈造成的重要现象。每当数据库在I/O请求中花费大量时间时，”I/O容量 “节点的所有子节点都会被探查，这就是本例中的两个终端节点。缓冲区缓存过大 “节点将寻找一个特定的根本原因，也就是看数据块缓冲区缓存是否过大，导致I/O请求数量过多。I/O带宽不足 “节点将寻找可能减慢所有I/O请求的硬件问题。

一旦终端节点确定了一个根本原因，它就会测量该根本原因对数据库时间的影响。然后，它探索可以解决或缓解所发现问题的方法。它使用第4节中讨论的各种测量方法来提出可操作的调整建议。节点还估计了建议的调优建议可能节省的最大数据库时间，这不一定等于归因于根本原因的数据库时间。

除了识别瓶颈之外，ADDM还识别出没有遇到任何性能瓶颈的关键组件。这个想法是为了防止DBA调整那些对整个数据库吞吐量影响不大的组件。

值得注意的是，ADDM不需要遍历整个DBTime-graph；它可以修剪不感兴趣的子图。之所以能做到这一点，是因为DBTime-graph的构造方式是：节点的数据库时间包含在归属于其父辈的数据库时间中。通过修剪和不遍历不感兴趣的子图，这些子图代表了不消耗大量数据库时间的数据库组件，ADDM分析的成本只取决于影响数据库的实际性能问题的数量。分析的成本并不取决于数据库的实际负载或ADDM可能诊断出的问题的数量。

DBTime-graph也使得ADDM非常容易适应新的要求，在不影响分析成本的情况下寻找新的性能问题的根源。显而易见，删除过时的终端节点也是非常简单的。

在分析结束时，ADDM报告了所识别的最主要的根本原因，根据每个根本原因所产生的性能影响进行排序，并提出了相应的调整建议。

五、工作负载测量

只有当适当的数据可用时，才能进行ADDM分析。在这一节中，我们将讨论一个系统应该收集的性能数据，以便能够进行ADDM分析。在这一节中，我们列出了ADDM提出的要求，并描述了我们在任何分析期收集的数据类型。关于数据如何存储和实际使用的细节，请参考第6节。

5.1 数据收集要求

我们的第一个也是最重要的要求是，我们为DBTime-graph中的每个节点收集ADDM需要的所有数据。ADDM需要以下操作的数据。

• 量化考虑中的数据库组件对数据库时间的影响。
• 寻找缓解根本原因问题的建议，并估计建议在数据库时间中的潜在收益。

我们的第二个要求是 “最小入侵原则”；它指出，为性能诊断而收集测量数据的行为不应导致性能的显著下降。显然，”显著 “的概念是主观的，是由商业考虑决定的–什么样的服务器开销是客户可以接受的，以获得ADDM分析的好处。我们进行的任何测量都有相关的成本。至少，我们需要增加一些计数器或内存中的变量。如果我们需要精确的时间，我们可能需要使用操作系统调用来获得当前时间。这种成本在某些情况下可能可以忽略不计，但在其他情况下可能会令人望而却步。

在第4.2到4.5节中，我们描述了我们为ADDM分析所收集的不同类型的数据。在所有情况下，我们都描述了数据的目的以及它如何符合最小入侵原则。

5.2 数据库时间测量

ADDM分析的首要任务是建立消耗大量数据库时间的主要组件。数据库服务器必须被测量，以测量ADDM感兴趣的特定操作中所花费的数据库时间。这个测量是一个累积的非递减的时间函数。ADDM分析总是在一个被称为 “分析期 “的特定时间区间内进行（例如，昨天上午10点到11点之间）。ADDM通过从分析期结束时的测量值中减去分析期开始时的测量值来发现在一个特定的操作上花费了多少时间。

我们维护不同粒度的测量值，所以ADDM分析可以从症状（例如，提交操作消耗了大量的数据库时间）到根本原因（例如，写到某个日志文件的I/O非常慢，可能是硬件问题）。我们需要在粗略的层面上保持测量，即所有提交操作所花费的时间。我们还需要更精细的粒度–每个日志文件的写I/O花费。

直接测量只能在通常需要大量时间才能完成的数据库操作上进行。如果我们试图测量众多短期操作的时间，我们很可能会违反最小入侵原则。关于哪些操作应该被测量的决定应该基于测量的成本（即开始和结束一个定时器需要多少时间）以及这种操作的预期长度和数量。例如，测量花在I/O操作上的总时间是合理的，因为I/O操作比启动和结束一个定时器要多花很多数量级的时间。另一方面，测量我们在常用信号的关键部分所花费的时间将是非常昂贵的。我们捕获短时操作的解决方案是使用采样。我们既使用基于频率的抽样，即从每N个发生的操作中抽出一个，也使用基于时间的抽样，这将在下一节详细讨论。

5.3 活动会话历史

ADDM通常需要对工作负载进行详细的描述，以便能够找到问题的根本原因并给出有效的建议。由于数据量非常大，而且会大大影响数据库的性能，所以不可能收集完整的系统操作痕迹。我们的解决方案是提供一个基于时间的系统中所有活动的样本。我们把这种抽样数据称为 “活动会话历史”（ASH）。

ASH是一个以固定时间间隔进行的样本集合。每个样本包含数据库服务器在采样时代表每个连接的用户（又称 “会话”）所做的事情的信息。我们只收集在采样时间内积极使用数据库的会话的数据。如果一个会话正在等待下一个用户命令，它就不会出现在ASH的特定采样时间内。

图4说明了一个工作负载，该图中的表格显示了所产生的ASH样本。ASH中的样本非常详细地描述了每个会话所执行的数据库操作。例如，当一个会话在等待I/O时，我们可以知道哪个数据库对象被读取，其中哪一部分被读取。这些细节使ADDM能够深入到非常具体的根本原因。

我们用于ASH采样的时间间隔应该比作为分析期的时间间隔至少短两个数量级。这可以确保我们至少有数百个特定会话状态的样本来分析。如果一个特定的操作在分析期间消耗了大量的数据库时间（比如超过数据库时间的几个百分点），那么这个操作很有可能会出现在ASH的大量样本中。这使得ADDM能够诊断出这种操作，即使我们不直接测量它们。ASH的采样频率应谨慎选择。如果采样过于频繁，可能会违反最小入侵原则。如果采样不频繁，ADDM可能无法找到问题的根本原因或有效的建议，因为可能没有足够的特定操作的样本。

ADDM使用ASH来寻找根本原因和有效建议。例如，假设我们从精确的数据库时间测量中发现，系统中竞争的主要来源是在处理表的空间分配的锁上。我们可以使用ASH来找到更细粒度的事件，比如 “哪些表经历了空间分配的争夺，以及用于这种争夺的SQL语句的类型是什么？” 我们也许能够确定一个特定的表由于INSERT语句而遭受争用，并推荐一个分区方案来缓解这个问题。虽然时间测量可能能够引导我们找到导致问题的具体锁的类型，或者有时找到具体的表，但只有ASH允许我们对争夺锁的SQL语句的类型进行交叉分析。没有ASH，ADDM不能推荐具体的解决方案：对特定的表进行分区。

5.4 系统配置

我们还收集了一些非数字性质的数据，或者是可以随时间减少的数据。这些数据通常是关于数据库设置的。对于这类数据，我们需要维护一个完整的变化日志。幸运的是，数据库设置并不经常变化，所以维护完整的变化日志的成本并不高。这种类型的数据对于给出修复特定问题的建议至关重要。这类数据的例子有。

• 内存组件的大小（如缓冲区缓存）。

• 系统使用的CPU的数量。

• 特殊的查询优化器设置。

  数据的确切性质取决于数据库服务器的实现，不在本文的讨论范围之内。

5.5 模拟

有时，估计数据库中某个特定区域的影响需要对各种可能的替代方案进行模拟。例如，我们可能因为缓冲区缓存的大小不足而对读I/O操作产生重大影响。数据库时间的测量是我们花在读I/O操作上的时间。然而，要发现缓冲区缓存是根本原因，我们必须确定我们花了时间来读取在某个时间点在缓冲区缓存中的数据块，并被移除以腾出空间给其他数据块。换句话说，我们需要确定，如果有一个无限的缓冲区缓存，可以节省多少读I/O操作。我们的解决方案是模拟当缓冲区缓存增加到不同大小时，可以节省多少数据库时间，并推荐一个给定资源的最佳设置。

六、其他模型中的数据库时间

第4.1节中对数据库时间的定义依赖于一个简单的计算模型。该模型的特点是有以下限制。

• 单一机器。这意味着我们没有一个分布式系统。相反，我们使用一台主机作为数据库服务器。
• 没有后台活动。这意味着所有的数据库工作都是在用户等待响应时完成的。
• 没有并行计算。每个用户连接都对应着数据库服务器中的一个计算线程。这意味着代表用户调用的工作不能同时使用一个以上的CPU，不能同时等待一个以上的事件，也不能同时等待一个事件和使用一个CPU。

大多数数据库服务器支持使用分布式系统、并行查询和背景活动的计算模型。因此，我们需要建立ADDM在这些假设被违反时的目标。

6.1 分布式系统

最简单的分布式系统有相同的组件。这意味着作为系统一部分的所有机器都是相同的机器，运行相同的软件，有相同的网络连接，并使用相同类型的I/O设备。在这种简单的情况下，我们需要做的就是将所有机器上观察到的数据库时间相加，得到分布式系统的总数据库时间。每一个细分的数据库时间（例如，等待I/O的时间）也要在所有机器上相加。
当机器之间存在差异时，情况就复杂得多了。在这种情况下，我们需要在机器之间找到一个共同的度量，而不仅仅是在同一服务器的不同区域之间。例如，如果两个CPU的计算速度不同，我们不能认为一台机器上的一秒钟CPU使用量等同于另一台机器上的一秒钟CPU使用量。我们仍然将不同机器上的所有数据库时间相加，因为这个数字仍然对应于用户等待数据库服务器响应所花费的总时间。我们只需要考虑到，将一个计算线程从一台机器移到另一台机器上，可能会导致数据库总时间的变化。例如，如果两台机器在移动之前和之后都没有CPU限制，那么将一个CPU重的计算从一个慢的CPU移动到一个快的CPU就会减少数据库时间。

6.2 背景活动

背景活动是Oracle服务器中的一个重要组成部分。例如，即使在事务提交之后，数据块也不需要被写入磁盘。只要把适当的日志记录写到磁盘上就足够了。因此，对表和索引的大部分写I/O是作为后台活动完成的；没有用户等待这些写的完成。

我们将背景活动视为一组计算线程。在这些线程中所花费的时间不计入数据库时间，因为没有用户在等待这些线程。然而，关于后台资源使用的统计数据必须被维护。当ADDM检测到一个资源被使用得太多时，一个可能的建议是减少使用该资源的后台活动。例如，如果I/O子系统被大量使用，以至于I/O响应时间非常慢，并且造成了大部分的数据库时间，我们可以考虑减少检查点的频率。

6.3 并行计算

我们在并行计算中遇到的第一个问题是如何测量数据库时间。并行计算意味着一个用户连接负责多个计算线程，这些线程可能使用多个CPU并等待多个事件或资源。由于数据库时间是对吞吐量的测量，我们必须将所有的计算线程所花费的时间都视为数据库时间的一部分。唯一的例外是当一个线程在等待属于同一个用户连接的另一个线程时。在这种情况下，我们认为等待时间是空闲的，我们不把它加入数据库时间。出现这种例外的原因是，我们试图衡量如果计算被序列化，同时保持相同的执行计划，数据库时间会是多少。在这种情况下，所有CPU的使用和对外部资源的等待仍然是计算的一部分。然而，线程之间的内部等待却从计算中消失了。
当我们需要减少一个请求的响应时间时，就会用到并行计算。正如并行算法的情况一样，为了获得更好的响应时间，要牺牲掉吞吐量。在许多情况下，一个特定用户请求的响应时间比整个系统的吞吐量更重要。ADDM建议数据库管理员，与串行计算相比，在并行计算上要多花多少数据库时间。在这种情况下，我们必须咨询优化器，找到最佳的串行执行计划，并将其与实际使用的并行执行计划进行比较。这是一种模拟，因为我们没有执行串行计划，不知道在数据库时间方面的确切成本。

6.4 总结

我们已经看到了分布式系统、后台活动和并行查询是如何使数据库时间的概念和ADDM分析的目标复杂化的。这些并不是我们在Oracle 10g中实现ADDM时遇到和解决的唯一复杂问题。然而，一个完整的清单不在本文的范围之内。总的原则仍然是一样的：找到一种通用的货币来衡量数据库的吞吐量，找到增加吞吐量的方法，并在用户体验中提高数据库的性能。

七、ADDM在自治数据库中的作用

ADDM是Oracle 10g中开发的用于自治数据库的可管理框架的核心部分（见[ORM10]）。这个框架通过提供必要的组件来实现一个全面的调整解决方案。ADDM是一个关键的组件，作为系统中各种调优活动的核心智能，比如SQL调优[ORQ10]或空间碎片分析[ORS10]，因为它对数据库系统有一个整体的看法，并确定影响整体吞吐量的首要问题。ADDM本身在很大程度上依赖于该框架，以便随时访问它所需要的性能测量。

Oracle 10g中的可管理性解决方案是以自治循环的三个阶段为中心的。观察、诊断和解决。该框架提供的每个组件在这些阶段中的一个或多个阶段中发挥着关键作用。这些阶段指的是一个特定的活动（例如：SQL调优周期），而且可能有许多这样的活动同时发生在不同的阶段。图5和下面的章节说明了主要组件之间的关系，以及它们如何与ADDM互动。

7.1 观察阶段

这个阶段在Oracle 10g中是自动和连续的，并且提供了分析所需的数据，以及作为分析的一部分所采取的行动的反馈。为了实现准确的系统性能监控和调整，所考虑的系统必须暴露出相关的测量和统计数据。可管理性框架允许对代码进行仪表化，以获得精确的时序信息，并提供一个轻量级的综合数据收集机制来存储这些测量数据，以便进一步进行在线或离线分析。

这个阶段的主要组成部分是 “自动工作负载库”（AWR）。它是Oracle10g的性能数据的持久性存储。数据库每小时从内存视图中抓取系统和性能数据，并将其存储在AWR中。每个集合被称为一个快照。任何一对快照都决定了一个可用于ADDM分析的分析期。AWR是自治的；它接受数据保留政策，并在遇到空间压力时主动清除数据。
快照机制和它所收集的全面数据一起解决了 “首次发生分析 “的要求。ADDM在每次拍摄快照时自动运行，分析期由最近的两个连续快照来定义。

7.2 诊断阶段

这个阶段的活动是指使用AWR或内存视图中的数据对数据库系统的各个部分进行分析。Oracle 10g引入了一组顾问，ADDM是其中之一，用于分析和优化其各自子组件的性能。特别值得注意的是，所有顾问为他们诊断的问题提供了数据库时间方面的影响。这允许在顾问的结果之间进行简单的比较。

ADDM在其分析过程中咨询这些顾问，这取决于这些顾问所需要的时间和资源。如果一个顾问可能需要大量的时间进行分析，ADDM会产生一个建议来调用那个特定的顾问。然后用户可以在适当的时候安排这项任务。

ADDM可以调用的顾问集包括

• SQL调整顾问：通过改善执行计划，执行基于成本的访问路径分析和SQL结构分析来调整SQL语句。
• 分段顾问：分析由于内部和外部碎片造成的对象的空间浪费。
• 内存顾问：持续监控数据库实例并自动调整各种内存池之间的内存利用率。

7.3 解决阶段

各种顾问在进行了分析后，作为输出提供了一组可以实施或应用于数据库的建议。每个建议都伴随着数据库时间的好处，如果建议被应用，工作负载将体验到这个好处。这些建议可以由数据库自动应用（例如，由内存顾问调整内存大小），也可以由人工启动。这是 “解决 “阶段。
将建议应用到系统中，关闭了该特定调整循环的迭代。建议对工作负载的影响将在未来的性能测量中被观察到。进一步的调整循环可以被启动，直到达到预期的性能水平。

8.实验和结果

测试和量化ADDM的结果并不是一件容易的事情。ADDM的价值在于帮助DBA管理其数据库的性能。检查ADDM是否符合任务要求，我们需要调查许多已经在生产或测试环境中适应Oracle 10g的客户。在Oracle 10g发布之后，进行这样的调查还为时过早。然而，我们在第8.1到8.3节中提供了三个真实的ADDM使用实例。

我们使用各种场景来衡量ADDM的有效性。

在最初的测试阶段，我们进行了盲测；性能调优专家被要求对运行中的系统进行分析并提出建议。在大多数情况下，ADDM产生了相当的结果，在某些情况下，ADDM的建议比专家的建议产生了更大的效益。

作为Oracle服务器技术组内部测试的一部分，我们进行了一些测试，在这些测试中我们引入了已知的 “常见故障 “和应用程序的低效率。当对这些测试中捕获的数据进行ADDM分析时，ADDM在所有情况下都能正确识别故障。

高负载压力测试是甲骨文公司数据库产品测试的一个组成部分，并对运行所有Oracle 10g可管理性功能的效果进行了测量。在典型的客户工作负载和高度调整的行业标准基准下，启用所有可管理性功能所带来的吞吐量减少约为3%。AWR和ADDM是其中的两项功能。在每次AWR快照后执行的ADDM运行都很及时，通常在10秒以内。

尽管Oracle 10g在2004年1月被宣布投入生产，但在此日期之前，一些内部生产系统已经运行了几个月的软件。在这段时间里，ADDM已经在这些系统上识别并正确诊断了一些性能问题。

8.1 高通公司的经验

高通公司Centauri应用程序从Oracle 8.1.7.4版本升级到10g RAC。在测试升级的时候，他们发现了明显的性能问题，测试人员报告说响应时间很差。DBA查看了ADDM建议，该建议强调了一个SQL（更新语句）导致了90%以上的系统负载。然后他们在该语句上运行了SQL Tuning Advisor，它建议创建一个索引。后来发现，建议的索引应该已经到位。索引的缺失是因为应用程序的一个补丁被应用到了生产系统中，而没有应用到升级后的测试系统中。识别索引使问题的诊断变得容易。

8.2 在Oracle Bug数据库中的经验

Oracle Bug数据库每天被成千上万的用户使用，它是第一批转移到Oracle 10g的生产系统之一。该系统在一台8个CPU的PARISC HP机器上运行。在升级到Oracle 10g之后，用户遇到了糟糕的性能。ADDM报告说，用户花了很大一部分时间来等待空闲的缓冲区等待，并建议检查I/O子系统的写入性能（这种类型的问题发生在缓冲区缓存被脏缓冲区填满时，更快的I/O应该可以解决问题）。当系统管理员检查I/O子系统时，他发现异步I/O的配置不正确，导致异步I/O请求失败，然后被同步执行，导致IO时间极慢。

8.3 Oracle应用程序QA测试的经验

一个应用开发部的DBA报告说，一个用户说，系统很慢。不幸的是，没有给出时间尺度或细节。由于系统的用户和调查慢的 DBA 分别在世界的两边，相隔 12 个时区，调查就更难了。
看一下ADDM报告，有几个一小时的时间段，在数据库中花费的时间明显增多。这两份ADDM报告显示，大部分时间都花在了解析上，而解析的原因是应用程序产生了大量的包含字面字符串值的SQL语句。(这个问题相当于Oracle使用许多类似的SQL语句而不是存储过程。这种配置的代价是在解析、优化和编译SQL语句上花费的时间，在Oracle的术语中，它被称为 “硬解析”）。ADDM的建议是修改应用程序，使用绑定变量而不是字面意思，或者改变数据库配置参数，自动将字面意思转换成绑定。当应用开发部就字面意义的使用进行接触时，发现这个QA系统运行的是一个 “已知的坏 “的应用程序的内部构建，升级到正确的构建后，这个问题就解决了。

九、结语

在本文中，我们描述了Oracle 10g是如何通过ADDM提供自动性能诊断和调整来提供全面的调整解决方案的。这解决了目前数据库管理员所面临的不断增加的性能调优挑战。我们定义了一个新的衡量标准，叫做 “数据库时间”，它允许对各种数据库组件的性能影响进行相互比较。我们还描述了准确的性能诊断需要哪些类型的性能测量，以及我们如何以一种对系统影响很小的方式获得这些测量。这个解决方案也避免了为了诊断问题而重现问题的需要。ADDM结合了系统的整体视图，通过使用数据库时间和二维DBTime-graph，它能够快速分离出影响系统吞吐量的性能瓶颈的根本原因。ADDM提供了具体的可操作的建议，并对缓解性能问题的收益进行了估计。在Oracle的各种工作负载和生产系统上运行ADDM的结果表明了我们的吞吐量调整方法的好处和实用性。

因为未来的工作的主要内容是做数据库的自动化诊断和调优，需要读一下Oracle的AWR、ASH的相关文章。偷个懒，就先看这一篇。

[BE03] D. G. Benoit. Automatic Diagnosis of Performance Problems in Database Management Systems, PhD Thesis, Queen’s University, Canada, 2003.