Oracle 数据库 11g：真正应用测试与可管理性概述

. 引言

Oracle 数据库占据着市场主导地位，受到全球众多企业以及应用程序开发人员和数据库管理员的青睐。这些年来，企业已经开始依赖 Oracle 数据库来提供无可比拟的性能和可靠性。在数据库 10g 中，Oracle 提供了一个自我管理数据库，该数据库具有前所未有的可管理性，从而显著降低了管理成本。

Oracle 准备再在 Oracle 数据库 11g 中更上一层楼。数据中心为满足企业需求而快速发展和变化，Oracle 数据库 11g 正是专门针对数据中心环境设计的。利用 Oracle 数据库 11g，企业可以快速采用新技术，将风险降至低。此外，通过其自我管理功能，Oracle 数据库 11g 已在可管理性和故障诊断等方面取得了显著进展。

真正应用测试

现在，企业需要在硬件和软件上进行相当大的投资才能展开基础架构更改。例如，某个数据中心可能计划将数据库转移到一个诸如 Oracle Enterprise Linux 的低成本计算平台。过去，这需要企业为整个应用程序投入一套重复的硬件，包括 web 服务器、应用程序服务器和数据库，以便测试其生产应用程序。因此，企业发现发展其数据中心基础架构并实施对它的更改代价高昂。即使执行了昂贵的测试，后在生产系统中进行更改时还是会经常出现意想不到的问题。这是因为测试负载通常是模拟的，并不能完全准确地代表真实的生产负载。因此，数据中心管理人员并不原意采用新技术来使其企业适应不断变化的竞争压力。

Oracle 数据库 11g 的真正应用测试通过引入两个新的解决方案，即数据库重放和 SQL Performance Analyzer，直接解决了这些问题。

数据库重放

利用数据库重放，DBA 和系统管理员可以在测试环境中忠实地、准确地、真实地重新运行实际的生产负载，包括联机用户和批量负载。利用数据库重放可以捕获来自生产系统的全部数据库负载，因此只需在测试系统上重新创建生产负载即可真实地测试系统更改 — 通过一组脚本是永远也不能复制这些负载的。利用数据库重放，DBA 和系统管理员可以测试 数据库升级、补丁、参数、模式更改等

配置更改，如从单一实例转换到 RAC、ASM 等

存储、网络、互连更改

操作系统、硬件移植、补丁、升级、参数更改 降低测试基础架构成本

DBA 现在可以根据测试更改的需要来构建自己的测试基础架构，无需复制基础架构中的所有应用程序。有了数据库重放就不再需要重新创建中间层或 web 服务器层。因此，DBA 和系统管理员充满信心地快速测试和升级数据中心基础架构组件，因为他们知道更改已经在生产情形下得到了真实地测试和验证。

加快部署

数据库重放的另一个主要优势是它不需要 DBA 花几个月的时间来了解应用程序和开发测试脚本。只需点几下鼠标，DBA 即可轻松获得全部的生产负载来测试和做任何更改。这使得测试周期从好几个月缩减到几天或几周，从而使企业显著降低成本。

数据库重放由四个主要步骤组成：

1. 负载捕获

启用负载捕获之后，系统将跟踪转到 Oracle 数据库的所有外部客户端请求，并以二进制文件的形式（称为捕获文件）将其存储到文件系统上。Oracle 建议在捕获负载之前备份整个数据库。用户指定捕获文件的位置以及负载捕获的起始和结束时间。在该流程中，所有与外部数据库调用相关的信息都会写入捕获文件。

2. 负载处理

捕获到负载之后，需要对捕获文件中的信息进行处理。该处理过程将捕获的数据转换为重放文件，并创建重放负载所需的所有必要元数据。通常会将捕获文件复制到另一个系统进行处理。必须针对每个捕获的负载都执行一次该过程，才能重放这些负载。捕获的负载经过处理之后，可以在重放系统上反复重放。由于负载处理耗费时间并占用资源，因此通常建议在重放负载的测试系统上执行该步骤。

3. 负载重放

捕获的负载经过处理之后就可以重放了。然后一个名为重放客户端的客户端程序处理重放文件并提交对数据库的调用，时间和同步与在捕获系统中完全相同。根据所捕获负载的不同，您可能需要一个或多个重放客户端来恰当地重放负载。可以使用一个校准工具来帮助确定一个负载所需的重放客户端的数量。注意：由于包括 DML 和 SQL 查

询在内的所有负载都会得到重放，因此要做出可靠的分析报告，重放系统中的数据与生产系统（在该系统中捕获负载）中的数据完全相同是很重要的。

4. 分析和报告

大量报告供您对捕获和重放进行详细的分析。重放期间遇到的所有错误都会被记录下来。会显示任何由 DML 或查询返回的行中的差异。提供捕获和重放之间的基本的性能比较。对于高级分析，可使用 AWR

报告对捕获和重放之间的性能统计信息进行详细的比较。

图 1：数据库重放流程

11g

. Sql Performance Analyzer

影响 SQL 执行计划的更改会严重影响系统性能和可用性。因此，DBA 需要花

费大量时间来识别和修正由于系统更改而导致性能下降的 SQL 语句。SQL

Performance Analyzer (SPA) 可以预测和防止由环境更改导致的 SQL 执行性能问题。

SQL Performance Analyzer 通过在更改前后连续运行 SQL 语句来提供环境更改对 SQL 执行计划的影响的粒度视图和统计信息。SQL Performance Analyzer 生成的报告列出了由于系统更改带来的实际收益以及性能下降的 SQL 语句集。针对性能下降的 SQL 语句，会提供相应的执行计划详细信息以及调整建议。

SQL Performance Analyzer 已与现有的 SQL 调整集 (STS)、SQL Tuning Advisor 和 SQL 计划管理功能良好集成。SQL Performance Analyzer 使得评估更改对超大 SQL 负载（几千个 SQL 语句）的影响的这个手动的、耗费时间的

过程完全自动运行并得到了简化。DBA 可以使用 SQL Tuning Advisor 来修正在测试环境中回退的 SQL 语句，并生成新的计划。然后，这些计划会被播种到 SQL 计划管理基准中，并被重新导出到生产环境中。因此，使用 SQL

Performance Analyzer，企业能够以非常低的成本和高度自信心来验证对生产环境进行的系统更改实际上带来的终正面改进。

可以使用 SQL Performance Analyzer 进行的常见系统更改包括：　

数据库升级、补丁、初始化参数更改 对操作系统、硬件或数据库的配置更改 模式更改，如添加新索引、分区或物化视图 收集优化器统计信息 SQL 调整操作，例如，创建 SQL 概要文件

使用 SQL Performance Analyzer 涉及以下 5 个主要步骤：

1. 捕获您希望通过 SPA 分析的 SQL 负载。Oracle 数据库提供了多种将 SQL 负载从多个源（例如游标缓存和自动负载信息库）捕获到 SQL 调整集 (STS)

中的方法。这通常在生产系统上完成，然后将 STS 传送到测试系统，在其中进行 SPA 分析。

2. 在 SQL 调整集上执行 SPA，以衡量更改前负载的性能。

3. 进行更改，例如数据库升级或优化器统计信息刷新。

4. 再次在 SQL 调整集上执行 SPA，以衡量更改后负载的性能。

5. 比较 SQL 调整集的两次执行的性能，以识别出哪些 SQL 语句回退、改进或没有变化。

Oracle 数据库 11g 真正应用测试和可管理性概述 6

图 2 SQL Performance Analyzer 报告 该 SPA 比较报告显示建议的系统更改之后整体 SQL 负载的性能显著提

高，但有一些执行计划性能下降。SQL Performance Analyzer 在衡量影响时考虑 SQL 语句的执行次数。在几秒钟内完成但频繁执行的 SQL 语句可能比仅执行一次的运行时间较长语句对系统的影响更大。SPA 在预测整

体性能改进和性能下降时将这些因素都考虑在内。如果遇到任何性能下

降，SPA 允许用户使用 SQL Tuning Advisor 或 SQL 计划基准进行修正。SQL 计划基准是 Oracle 数据库 11g 中引入的一个新的计划稳定性功能。

选择正确的解决方案可以帮助 DBA 有效地理解和管理更改。数据库重放

旨在测试和改进系统性能，SQL Performance Analyzer 可以帮助 DBA 加

快 SQL 响应。利用 Oracle 11g 真正应用测试，数据库管理员可以轻松管理和执行对企业至关重要的更并且降低风险。

可管理性

Oracle 在数据库 10g 版本中引入了大量可管理性方面的创新。在该版本中，Oracle 继续在数据库的所有可管理性方面做出重大改进，使得 Oracle 11g 数据库的自我管理性能比以往任何时候都强。 面向 RAC 的 ADDM

Oracle 数据库 10g 引入了自动数据库诊断监视 (ADDM)，这一革命性的功能已帮助创建了第一个自我管理数据库。ADDM 使用集成的方法提供数据库级性能分析，包括存储器、系统资源、 空间、应用程序和 SQL 以及备份和恢复管理。ADDM 为 DBA 提供主动分析，可根据需要解决性能问题。

11g

Oracle 数据库 11g 通过为真正应用集群 (RAC) 数据库提供集群级性能分析，对 ADDM 进行了扩展。对于 RAC 环境，ADDM 分析 RAC 集群并报告影响整个数据库及其各个实例的问题。DBA 现在可以使用 ADDM 执行全局资源（例如高负载 SQL、全局缓存互连流量、网络延迟问题、实例响应时间中的异常、I/O 容量等）的数据库级分析。DBA 还可以限制在 RAC 集群的几个指定的实例上执行 ADDM 分析。利用适用于 RAC 的 ADDM，RAC 数据库的性能分析变得好像在单个实例数据库中进行那样简单。

在 Oracle 数据库 11g 中，DBA 可以使用指令过滤并仅显示感兴趣的内容来限制 ADDM 发现的内容。为了更好地理解随时间对发现内容的影响，每个发现的内容都有一个简化搜索的描述性名称、到近 24 小时内发现的内容出现次数的链接以及受影响的实例。

SQL 调整自动化

SQL 性能低下通常是由于数据库执行不当引起的。过去，许多 DBA 尝试了使用手动的 SQL 调整流程来解决该问题。SQL 手动调整是一个复杂的、反复的过程，它提出了许多挑战。这一工作不但非常耗时，而且需要熟知应用程序和查询计划的模式结构和数据使用模型。所有这些因素都使 SQL 调整成为一个既具挑战性、又占用资源的任务，因此对企业来说其成本极其高昂。

Oracle 10g 中引入了 SQL Tuning Advisor，可通过全面分析 SQL 语

句，使 SQL 调整过程自动进行。该分析输出的形式为建议，与建议同时输出的还有每条建议的理由及其预期的性能改进。这些建议涉及对象统计信息的收集、新索引的创建、SQL 语句的重新构建或 SQL 概要文件的创建。用户可以根据需要手动查看这些建议并实施。

在 Oracle 数据库 11g 中，SQL 调整过程得到了进一步增强，并可以自动运行以保持数据库以高的性能运行。现在，SQL Tuning Advisor 在系统维护时作为维护任务自动运行。在每次运行中，SQL Tuning Advisor 会自动选择系统中的高负载 SQL 查询，并生成优化这些查询的建议。

为验证这些建议，Oracle 数据库 11g 中的 SQL Tuning Advisor 会使用

SQL 概要文件建议的新计划对 SQL 语句进行测试。这极大地增强了 SQL 概要文件建议的准确性和可靠性。

可以将自动运行的 SQL Tuning Advisor 配置为自动实施 SQL 概要文件建议。如果您启用自动实施，SQL Tuning Advisor 将仅为性能提高至少为 3 倍的 SQL 语句创建 SQL 语句。其他类型的建议，如创建新索引或刷新优化器统计信息或重新构建 SQL，只能手动实施。DML 语句的优化不在自动运行的 SQL Tuning Advisor 考虑范围之内。默认情况下，自动运行的 SQL Tuning Advisor 配置为在夜间运行，并且仅生成建议而不自动实施这些建议。

您可以查看指定时间段（例如近 7 天）内 SQL 自动调整的结果汇总，还可以查看对所有处理的 SQL 语句生成的详细建议。然后就可以手动有选择地实施建议。您还可以查看自动实施的建议。可以将自动运行的 SQL Tuning Advisor 配置为在所有维护窗口运行或根据需要完全禁用。

SQL 计划管理

SQL 计划管理通过提供捕获、选择和发展 SQL 执行计划的组件，可以防止由于对 SQL 语句的执行计划进行突然的更改而引起的性能下降。SQL 性能会受各种更改（如新的优化器版本、对优化器统计信息和/或参数的更改或者 SQL 概要文件的创建）影响。SQL 计划管理是一个预防性的机制，可以不断记录和评估 SQL 语句的执行计划，构建由一组公认有效的现有计划组成的 SQL 计划基准。然后，可以使用 SQL 计划基准来保护相应的 SQL 语句的性能，而不管系统中发生何种更改。

通常，在以下情况下使用 SQL 计划管理会提高或维持 SQL 性能：

安装新的优化器版本通常导致少量 SQL 语句的计划更改，而大多数计划更改导致性能提高或没有变化时进行的数据库升级。但是，某些计划更改可能导致性能下降。使用 SQL 计划基准可以显著降低由于数据库升级而导致的可能的性能下降。

持续的系统和数据更改会影响 SQL 语句的计划，从而可能导致性能

下降。使用 SQL 计划基准还可以帮助尽量防止性能降低和维持

SQL 性能。

部署新的应用程序模块意味着在系统中引入新的 SQL 语句。应用程序软件可能使用在新的 SQL 语句标准测试配置下开发的相应 SQL 执行计划。

SQL 计划基准随时间不断发展，可以提供更好的性能。在 SQL 计划发展阶段，Oracle 数据库 11g 会例行评估新计划的性能，并将性能更好的计划集成到 SQL 计划基准中。要成功地验证一个新计划，需要将新计划的性能与从 SQL 计划基准中选择的一个计划的性能进行比较，从而确保新计划提供更好的性能。

11g

发展 SQL 计划基准有三种方法：

1. 手动方式，将用户验证的新计划载入现有的 SQL 计划基准中。

2. 手动方式，使用 DBMS_SPM PL/SQL 程序包的

EVOLVE_SQL_PLAN_BASELINE 函数验证新计划。

3. 自动方式，使用 Oracle 数据库 11g 的 SQL 自动调整功能。

SQL ACCESS ADVISOR 增强：PARTITION ADVISOR

Oracle 数据库 11g 增强了 SQL Access Advisor，可提供分区建议，作为 SQL 访问结构建议的一部分。新的、改进的 SQL Access Advisor 现在可

以给出全面的建议，说明如何根据系统负载优化模式设计以获得佳性能。

SQL Access Advisor 接受实际的或合成的 SQL 负载作为输入，并为提高

性能提供访问结构建议。建议的访问结构包括表和索引以及物化视图的分区建议，还有创建新的、放弃现有的索引（b 树、位图和功能索引）、物化

视图和物化视图日志的建议。SQL Access Advisor 在提供建议时将查询和 DML 都考虑在内。

分区建议仅为某些负载提供，这些负载在一些类型为 NUMBER 或 DATE

的列上具有一些谓词和连接。分区建议仅在上述列类型上生成，并局限于为单个列的 INTERVAL、HASH 或 RANGE 分区。SQL Access Advisor 十分精密，足以识别要分区的对象，并为上述种类的分区的建议分区键和范围。

与 SQL Tuning Advisor 类似，SQL Access Advisor 利用现有的基于成本

的优化器 (CBO) 规则，是一个基于易于使用的向导的解决方案。由于

SQL Access Advisor 与数据库内核的紧密集成，SQL Access Advisor 可

以根据内核附带的更新的 CBO 规则为访问结构提供佳建议。

SQL Access Advisor 还可以为索引、物化视图和分区解决方案的组合提供建议。给出 SQL Access Advisor 建议要考虑的因素包括存储器的创建和

维护成本，负载为全部负载还是部分负载，以及对负载中查询的整体好处。

处理大型负载时可能会中断 SQL Access Advisor，并为当时已处理的一组 SQL 提供调整建议。用户可以指定 SQL Access Advisor 处理 SQL 的顺序。

Oracle 企业管理器通过按成本降低由高到低的顺序列出 SQL 语句显示 SQL Access Advisor 任务的结果。DBA 可以选择按下一个按钮立即执行建议。或者，在更严格的环境中，DBA 可以创建一个包含一组可执行

SQL 语句的脚本来实施建议。

自动内存管理

Oracle 数据库内存结构基本上由共享内存或系统全局区 (SGA) 和专用内存或程序全局区 (PGA) 组成。在 Oracle 数据库 9i 中，引入了自动执行

的 SQL 内存管理功能来自动化 PGA 的管理。在 Oracle 数据库 10g 中，引入了自动共享内存管理来自动化 SGA 的管理。这意味着 PGA 中的所有不同 SQL 区域都针对系统负载自动进行调整以提供佳性能，共享内存中的所有内存池在大小上也进行类似的调整以获得佳性能。用户只需

指定 PGA 和 SGA 的目标大小，Oracle 会相应地在这些目标内分配内存以提供可能的佳性能。用户还可以借助 PGA Advisor 和 SGA Advisor

来对 Oracle 数据库 10g 中 SGA 和 PGA 的目标进行适当地设置。

图 3：自动内存管理

在 Oracle 数据库 11g 中，内存管理的自动化程度进一步提高。所有内存 PGA 和 SGA 现在都可以借助自动内存管理功能集中进行管理。DBA 只需指定一个参数 MEMORY_TARGET，Oracle 将自动根据负载调整程序全局区 (PGA) 和系统全局区 (SGA) 的大小。使用间接的内存传输，数据库可以将 SGA 中的内存传输到 PGA（反之亦然），从而对负载做出响应。间接的传输使用操作系统机制来释放共享内存和分配的内存并将它们传输到需要内存的其他组件，例如从 PGA 传输到 SGA。动态的内存分配会经常调整，以根据负载要求优化内存的使用，从而大化内存使用率并避免内存不足错误。使用自动内存管理功能时，用户可以选择设置 SGA 和 PGA 目标。这可以确保 SGA 和 PGA 的大小不会低于相应的参数目标在自动调整模式下指定的值。现在，该功能可以在 Linux、Solaris、HPUX、AIX 和 Windows 平台上使用。

11g

Oracle 数据库 10g 率先引入了 Memory Advisor，Memory Advisor 提供了所有内存目标设置、SGA 和 PGA 目标设置或 SGA 组件大小设置的图形分析。DBA 可以使用这些分析来调整数据库性能并执行假设的计划方

案。根据数据库使用的内存管理模式的不同，可以使用不同的 Memory

Advisor。

例如，如果启用了自动内存管理，您可以获得设置分配给整个数据库的目标

内存数量的建议。该 Memory Advisor 为该实例提供总的内存目标的建议。

如果启用了自动共享内存管理，您可以获得配置 SGA 和实例 PGA 的目标大小的建议。如果启用了手动共享内存管理，您可以获得配置共享池、缓冲区缓存和实例 PGA 的大小的建议。

AWR 基准和适应式阈值

自动负载信息库 (AWR) 是 Oracle 数据库 10g 重要的自我管理功能之一。Oracle 数据库分别捕获内存和数据库中的实时和历史性能统计信息，以便为 DBA 提供正确的工具和信息来解决性能问题。

利用 AWR 基准，DBA 可以捕获一段时间内感兴趣的或有代表性的负载的系统性能。例如，如果公司当前的月工资单处理缓慢，那么 DBA 可以将

系统性能与上个月的工资单处理相比较，以确定问题的原因。

利用“AWR 比较期间”报告可以轻松将有问题的时间段对照保存的基准，以确定性能偏差的可能原因。除了性能量度外，该报告还捕获配置信息，例如总内存以及 CPU 的数量，该数量可以确定可能导致性能降低的外部原因。如果对 COMPATIBLE 等重要参数进行带外更改可能会影响 SQL 性

能，在这种情况下，该报告还会捕获数据库系统信息，例如初始化参数。

此外，基准还可以用来设置系统性能量度的警报阈值。在 Oracle 企业管理器中可以查看大多数量度，以及在基准时间段内观察的同一量度的统计总数。这可以帮助用户设置基准形成的阈值，而不是选择没有实际数据的上下文的阈值。此外，适应式阈值适用于特定的关键性能量度。适应式阈值是性能警报阈值，由系统自动设置并定期进行调整，使用系统移动窗口基准数据作为阈值设定的基准。对于希望立即使用适应式阈值的客户，只需点几下鼠标即可利用新的“快速配置”选项根据常用的负载概要文件设置一个启动工

具包。

Oracle 数据库中有三种类型的基准：

1. 固定的基准

固定的基准与用户在过去指定的一个固定的、连续的时间段相对应。通常，选作基准的时间段应该代表以佳水平运行的系统，以便在性能低劣的时间段，可以针对基准进行比较以分析性能低下的原因。

2. 系统移动窗口

系统移动窗口是一个现成的功能，它是在从现在起到指定的到以前的某个时间的窗口（以天数为单位）内可用的所有 AWR 数据。默认情况下，该窗口的大小为当前的 AWR 保留期，即 8 天。如果您计划使用适应式阈值，请考虑一个更大的移动窗口（如 35 天），以计算更大的数据示例的更好阈值。如果客户将 AWR 保留期设置为一个较大的值，可以将系统移动窗口配置为小于 AWR 保留期的值。作为一般规则，系统移动窗口好在 3 到 13 周之间。

3. 基准模板

您还可以使用基准模板为以后的一个连续的时间段创建基准。基准模板有两种类型，即单个的和重复的。单个的基准模板可用于为以后的一个连续的时间段创建基准。如果您预先知道要在以后捕获的时间段，该模板是很有用的。例如，您可能希望捕获计划在下周进行的系统测试期间的 AWR 数据。在这种情况下，您可以创建一个单个的基准模板，以自动在测试进行时捕获该时间段的数据。

重复的基准模板可用于根据重复的时间安排创建和放弃基准。如果您希望 Oracle 数据库不断地自动捕获一个连续时间段的数据，这是很有用的。例如，您可能希望在某个月的每个星期一捕获 AWR 数据。在这种情况下，您可以创建一个重复的基准模板，以自动根据每个星期一的重复安排创建基准，并在指定的到期间隔（例如一个月）后自动删除旧的基准。

AWR 基准为定义动态的和以后的基准提供了强大的功能，并极大地简化了创建和管理性能数据以进行比较的过程。

故障诊断基础架构

从版本 11g 开始，Oracle 数据库包括一个高级的故障诊断基础架构，用于防止、检测、诊断和解决问题。针对特殊目标的问题是影响数据库运行状况的严重错误。出现严重错误时，会为该错误分配一个事故编号，立即捕获该错误的诊断数据（跟踪、转储以及其他），并用该事故编号进行标记。然后将数据存储再自动诊断信息库 (ADR) 中，该信息库是一个基于文件的信

息库，位于数据库外，稍后可以在该信息库中使用事故编号检索该数据并进

行分析。

Oracle 数据库 11g 中的大量故障诊断基础架构的改进是为了提供以下优点：

通过使用运行状况检查警告 DBA 主动响应小问题并防止灾难性系统故障。

使用数据恢复和 SQL Repair Advisor 检测问题出现后的有限损害、修复和中断。

通过 ADR 和 Test Case Builder 缩短问题诊断时间。

使用 IPS 和 Oracle 配置支持管理器简化客户与 Oracle 支持的互动。

以下是故障诊断基础架构的主要组件：

运行状况检查

Oracle 数据库 11g 中引入了运行状况检查器框架，用于对系统运行状况执行主动的检查。检查到严重错误时，故障诊断基础架构可以运行一个或多个运行状况检查，以对严重错误执行更深入的分析。运行状况检查的结果存储在一个报告中，可在浏览器中以文本文件或经过格式设置的 HTML 的形式进行查看。可以向该报告中添加为该错误收集到的其他诊断数据。单独的运行状况检查查找数据损坏、撤消和重做损坏、数据词典损坏等。作为 DBA，您还可以选择定期或根据需要手动调用这些运行状况检查。

Data Recovery Advisor

您可以使用 Data Recovery Advisor 修复数据块损坏、撤消损坏、数据词

典损坏等。Data Recovery Advisor 与 Oracle 企业管理器中的支持工作台工具和 RMAN 实用程序相集成，以显示数据损坏问题、评估它们的程度和影响，并提出修复建议。

SQL Repair Advisor

SQL Repair Advisor 是一个可以帮助 DBA 诊断 SQL 问题的新功能。如果 SQL 语句因严重错误（例如 ORA-600 错误）而失败，您可以使用

SQL Repair Advisor 分析问题，在大多数情况下，SQL Repair Advisor 可以推荐一个修复该语句的 SQL 补丁。通过应用 SQL 补丁，让查询优化器选择一个备用的执行计划供以后执行使用，可以防止 SQL 故障。

SQL Test Case Builder

对于许多应用程序问题，获得一个可再现的测试案例是加快问题解决的一个重要因素。SQL Test Case Builder 允许用户自动收集再现问题所需的所有

必需信息，例如 SQL 文本、PL/SQL、DDL、执行环境信息等。

然后，可以将收集到的信息传送到 Oracle 支持，以帮助再现问题。

自动诊断信息库 (ADR)

ADR 是一个基于文件的信息库，用于存放数据库诊断数据，例如跟踪、转储、警报日志、运行状况监视器报告等。该信息库有一个跨 Oracle 数据库

的多个实例和组件的统一目录结构，它替换了以前版本的

USER_DUMP_DEST、BACKGROUND_DUMP_DEST 和

CORE_DUMP_DEST。ADR 中的诊断数据是自我管理的，并根据预先定义的数据保留设置自动清除。ADR 还维护数据库上所有严重错误的元数据，以便用户可以对照 ADR 运行查询，来确定近几天、几个月甚至几年以来发生了什么严重问题、数量是多少。使用 Oracle 企业管理器或通过一个名为 ADR 命令解释器或 ADRCI 的命令行工具可以查看 ADR 中的数据。

事故打包服务(IPS)

事故打包服务自动运行收集与一个或多个问题有关的所有必需的诊断数据的过程。用户无需在不同的目录位置中搜索来收集 Oracle 支持诊断问题所需的所有相关的跟踪文件和转储文件。通过调用 IPS，所有与严重错误相关的诊断数据

（跟踪、转储、运行状况检查报告、SQL 测试案例）将自动打包为一个压缩文件，然后可以将该压缩文件传送给 Oracle 支持。

图 4：事故打包详情

支持工作台

支持工作台是 Oracle 企业管理器中的一个工具，利用它您可以与 Oracle 数据库 11g 的新的故障诊断基础架构进行交互。利用该工具，您可以调查、报告和修复（如果需要）问题，所有这些操作都可以在一个易于使用的界面中进行。支持工作台提供一种自助服务手段，供您使用 IPS 打包诊断数据、获得一个支持请求号，并将 IPS 程序包上载到 Oracle 支持，这些操作只需极少的工作量和时间，从而缩短了解决问题的时间。注意，所有与 Oracle 支持的自动交互（例如支持号创建或 IPS 程序包上载）都需要 Oracle 配置管理器在数据库位置运行。

Oracle 配置支持管理器是 Oracle Premier Support 中的一个自动运行的主动支持功能，它为客户提供了一种更简单的方法来跟踪、管理和支持您的 Oracle 配置，同时减少计划外系统停机风险。

11g

图 5：支持工作台流程

支持工作台流程包括以下步骤：

1. 根据首次出现的故障自动在数据库中创建一个事故。

2. 向 DBA 警告该故障，并在报告出现故障的区域运行运行状况检查。

3. 如果是一个已知问题，则建议并应用补丁来解决该问题。

4. 否则，对事故和相关的配置信息进行打包并上载到 Oracle Support，然后运行 Repair Advisor 从故障恢复。

Oracle 数据库中可能出现很多种不同的问题，针对每个问题的正确补救也可能

不同。支持工作台拥有大量工作流，可以指导用户针对遇到的问题采取相应的措施。

总结

当今快速发展的 IT 环境不断变化。但是，数据中心管理员并不难做。感谢

Oracle 数据库 11g 中新的真正应用测试功能，数据库管理员可以轻松适应变化，将他们不希望出现的结果控制到少。真正应用测试为 DBA 和系统管理员提供一个易于部署的解决方案，测试和展开数据中心更改，并减少硬件和软件投资，从而可以帮助企业降低测试成本。同时，利用 Oracle 数据库 11g 中的可管理性增强，数据库管理员可以保持系统的高性能和高可用性，同时为用户提供更高质量的服务。

声明: 除非转自他站（如有侵权，请联系处理）外，本文采用 BY-NC-SA 协议进行授权 | 嗅谱网
转载请注明：转自《Oracle 数据库 11g：真正应用测试与可管理性概述》
本文地址：http://www.xiupu.net/archives-2893.html
关注公众号：

赞赏

微信赞赏支付宝赞赏