本文永久链接地址：https://www.askmaclean.com/archives/oracle-11g-ocm-spa.html

5 SQL性能分析

5.1 目标

在完成这个课程后，你应该能够完成下列事情：

• 确定使用SQL 性能分析器的好处
• 描述SQL性能分析器工作流程
• 使用SQL 性能分区器在数据库变更后确定性能

5.2 性能变化时DBA面临的挑战

• 通过改变硬件或软件的配置来维护服务级别协议（SLA）
• 提供生产级别的工作负载环境来达到测试的目的
• 有效的预测和分析SQL性能的影响

大的关键业务应用是复杂的，并且具有高度变化的负载和使用模式。在同一时刻，这些业务系统被希望提供确定的服务，保障响应时间，吞吐量，正常运行时间和可用性。任何系统的改变（例如数据库升级或者修改了配置），在这些更改之前，经常需要进行广泛的测试和验证，以使其成为生产系统。为了有信心移动到生产，数据库管理员（DBA）必须以生产环境中的经验，公开测试系统工作负荷的工作量。它也拥有利于DBA以一个更有效的方式来分析SQL性能对整体系统水平变化的影响，这样在生产之前可以进行任何所需的调整更改。

5.3 变化是唯一不变的

• 变化时不稳定的最常见原因

• 企业生产系统是复制的
• 实际工作负载难以模拟

• 在生产之前进行实际测试是可能的

• 不愿意做出改变
• 无法采用新的有争议的技术

在变化中保持秩序

oracle 11g是为快速发展和变更的数据中心环境设计来保证业务需求，使得DBA们能够更好的管理变更。在oracle 10g自我管理能力的基础上进行开发，oracle 11g 在自动诊断，可靠性，和变更管理领域有重大进展。

在今天，oracle DBA和信息技术管理者是数据中心关键举措的领导者。这些数据中心的方案正在迁移到低成本的计算平台（如Oracle Enterprise Linux）和使用ASM来简化存储管理。DBA需要在新操作系统或存储平台上，使用实际的工作负载进行数据库测试，来确保迁移成功。

目前的企业需要在基础结构变化时，话费重大投资到硬件和软件上。例如。如果DBA想对一个数据库测试数据文件的存储管理，从文件系统到ASM，包含一个普通的J2EE应用，企业需要为整个应用框架投资重复的硬件，包括WEB服务器，应用服务器，和数据库。该组织还需要投入昂贵的测试软件来捕捉用户的工作量。

这些需要购买的东西，使得任何组织对其数据中心，基础设施的变化评估和实施变得非常昂贵。oracle 11g，在变更管理模块下，有一系列的解决方案。

5.4 11g的变更管理

• SQL 性能分析
• SQL 执行计划管理
• 数据库重放

SQL性能分析器自动识别和评估每个SQL语句的性能差异，对全SQL工作量的变化过程的整体效果。在这一课中，还有关于SQL性能分析的额外信息。

SQL执行计划管理是oracle 11g的新特性，通过维护SQL执行计划基线，用来让系统自动的控制SQL执行计划的变化。SQL执行计划管理会在课题“SQL执行计划管理”中详细讨论。

数据库重放允许你在系统改变引起的影响，在生产系统上暴露之前，在测试系统上使用真实的工作负载进行测试。

5.5 变更管理的周期–精确测试

oracle 11g 通过使用备份数据库的快照来建立和测试物理环境，提供更真实的测试。你可以临时的打开物理备份数据库（也就是说，激活它）到读写模式，用来报告和测试。一旦参数完毕，你可以简单地恢复到物理备份模式，以便追赶上主库。这个功能保证零数据丢失并且就想物理快照一样，但是允许灾难恢复和在测试时提供一个单一的存储副本。参考11g：DG 新功能讨论，物理快照数据库的详细信息。

对于企业来说，它应该可以在数据库环境下进行精确的测试，而能够准确地再现生产场景是至关重要的。在oracle 11g 中数据库重放，进一步为精确测试提供了支持。数据库重放被设计用来在给定数据库上捕获客户端请求，然后在生产数据库的其他副本中重现。OEM提供了更简单的步骤来设置捕获一个工作负载。

这些变化是DBA涉及的数据库升级，新调优建议，方案变化，统计信息收集，和操作系统与硬件上的变化。DBA可以使用SQL性能分析来跟踪和预测，由这些变化引起的SQL性能的改变。

如果SQL性能在一些情况下回退了，DBA可以运行SQL调优顾问调整SQL语句。

5.6 变更管理周期-配置自动化

当从oracle 11g R1进行升级时，你可以使用滚动升级功能，这样就保证了各个版本间的软件仍然可以相互通信。这允许一个ASM集群自主节点在迁移或打补丁时，不影响数据库的可用性，从而在迁移到新版本时保证更高的运行时间和更少的问题。ASM提供了进一步的系统的容量规划和负载变化的改进（快速磁盘同步，优先镜像读）。众多增强在线功能（在线索引重建，在线表重定义）进一步为应用改变提供支持。

自动诊断资源库（ADR）是一个用于存储和组织跟踪文件以及其他错误诊断数据的新系统管理资源库。你得到一个广泛的视图，其中包含了所有的数据库遇到的严重错误，问题诊断相关的所有数据，和最后的决议。你也可以使用EM提供的工作台，其提供了更简单的接口去查看和诊断故障数据，打包发送给ORACLE support。数据局恢复建议工具，可以用来自动诊断数据错误，并生成适当的修复方案的报告。

oracle 11g EM 支持端对端自动地在单实例数据家目录给应用打补丁，和在集群环境进行滚动打补丁。你不再需要手动地执行步骤，关闭系统，调用OPatch，应用SQL，和一些在补丁过程中其他的最佳实践步骤。

5.7 SQL 性能分析：概述

• 针对的用户：DBA，QA，应用开发者
• 有助于在SQL负载相应时间上预测系统变化地影响
• 建立不用版本的SQL工作负载性能（也就是，SQL执行计划和执行统计数据）
• 连续地执行SQL（并不是并发）
• 分析性能差异
• 在单个SQL上提供细粒度的性能分析
• 与SQL优化指导进行优化回归分析进行了集成

oracle真正地应用程序测试选项包括了SQL性能分析，其通过生成工作负载，对SQL语句变化产生的影响给出了精确的评估。SQL性能分析帮助你预测，那些在SQL查询工作负载的性能上潜在的影响。此功能为DBA提供了对SQL语句性能的详细信息，例如之前和之后的执行统计数据，和性能提升或退化的陈述。这个可以（例如） 在测试环境中进行更改，以确定是否能通过数据库升级来提高工作负载性能。

5.8  SQL 性能分析：案例

SQL 性能分析对于下列案例是有利的：

• 数据库升级
• 实现优化建议
• 统计信息收集
• 数据库参数变化
• OS和硬件变化

SQL 性能分析可以用来预测和防止，由任何数据库环境变化而影响SQL执行计划的结构后，一些潜在的性能问题。这些变化可包括(但不局限于)以下情况：

• 数据库升级
• 实现优化建议
• 统计信息收集
• 数据库参数变化
• OS和硬件变化

你可以使用SQL性能分析预测，由于复制环境变化引起的SQL性能变化。随着应用程序的开发生命周期的发展，数据库应用程序开发人员可以对方案、数据库对象的变化进行测试，并重写应用程序，以减轻任何潜在的性能影响。

5.9 使用SQL性能分析

1.在生产上捕获工作负载

2.将SQL工作负载传输到一个测试系统

3.构建“更改前”性能数据

4.进行变更

5.优化性能回退的SQL

6.确认3-5步骤的结果

7.构建“变更”后的数据

1.收集SQL：在这个阶段，你收集的SQL语句代表你的生产系统SQL工作量。

2.传输：你必须把合成负载传输到测试系统。从生产环境导出STS,然后将STS导入到测试系统中。

3.计算之前版本的性能：在任何更改之前，你执行sql语句，收集基准信息，在工作负载上以评估未来变化对性能的影响。

4.进行变更：在你有了之前版本数据之后，你可以按计划实施变更和开始查看对性能的影响。

5.计算之后性能的变化：这一步是在数据库环境中更改后进行的。每个SQL工作负载的语句会在模拟执行下运行(只收集统计数据)，收集的信息和第3步中的一样。

6.计算和分析SQL性能：在你有了不同版本SQL工作负载下的数据后，你可以对比变更之前版本数据和之后的数据，来完成性能分析。

7.优化性能下降的SQL：在这个阶段，你已经确定了在数据库变更参数时，哪些SQL语句会引起性能问题。在此，你可以使用任何数据库工具来调整系统。实施任何调整动作后，您应该重复该过程以创建新的版本，并分析性能差异，以确保新的性能是可以接受的。

5.10 步骤1：捕获工作负载

• STS 优化集用来存储工作负载。其中包括：

-SQL 文本

-绑定变量

-执行计划

-执行统计数据

• 增量捕获用于将一段时间内的游标缓存填充到STS。
• STS的过滤和排序功能，过滤掉不良的SQL

使用SQL性能分析的第一步是捕获SQL语句来代表你的工作负载。

你可以使用优化集或者AWR来抓取传输所需的信息。因为本质上AWR会捕获高负载的SQL语句，你应该考虑修改默认捕获AWR快照的配置和捕获的TOSQL，来保证捕获SQL语句的最大值。这样可以保证更完整的SQL工作负载捕获。

5.11  传输到测试系统

• 复制优化集到临时表(“包装”)。
• 传输临时表到测试系统（数据泵，DB link等等）。
• 从临时表中复制优化集中（”打开”）。

第二步是将这些sql语句发送到一个类似的用来测试的系统中。此处，STS可以从生产上导出，然后导入到测试系统。

5.12 步骤3：构建变更之前的性能数据

11.2 以上

• 在变更之前，SQL性能版本时SQL负载的基线。
• SQL性能=执行计划+执行统计数据
• 测试/执行STS中的SQL：

-生成执行计划和统计数据

-连续地执行SQL（非并发）

-每个SQL至少执行2次

-跳过DDL/DML效果

• 解析那些在STS生成的执行计划，仅仅只是SQL执行计划。

第三步是捕获测试系统性能的基线，包括执行计划和执行统计。

在这个阶段收集的信息是系统工作负载的当前状态的一个快照。这些性能数据包括：

• 执行计划（例如。生产执行计划）
• 执行统计数据（例如，包括执行时间，磁盘度，逻辑度，和处理的行）

在数据库 11g R2，每个SQL语句执行至少两次，为尽可能多的次数直到执行超时（最多10次）。第一次执行用于缓存到缓冲区。随后的所有执行被用于计算，基于SQL语句的运行时执行数据的平均统计。

5.13 步骤4：实施计划变更和步骤5：构建变更后性能数据

• 手动实施计划变更：

-数据库升级

-调整建议的实施

-方案变更

-统计信息收集

-数据库参数变化

-OS和硬件变化

• 在变更后重新执行SQL

-测试/执行STS中的SQL来生产SQL执行计划和统计数据

-解释 STS中的SQL计划来生成SQL计划

第四步时在测试系统上进行变更。步骤5是在变更后重新运行SQL语句，进行SQL性能影响评估。

5.14 步骤：6比较和分析性能 步骤7：优化退步的SQL

• 依据用户定义的指标来对比SQL性能：

-ELAPSED_TIME,BUFFER_GETS,DISK_READS,..

• 计算变更对单独的SQL和SQL工作负载的影响。

–对整体工作负载的影响

–工作负载上 NET SQL的影响

• 用执行sql的频率在定义重要性的权重。
• 检测改进，下降，和不变的性能。
• 检查执行计划的变化。
• 建议运行SQL调优顾问来优化回退的SQLs
• 分析结果可以被种子SQL执行计划管理基线使用。

比较基于执行统计数据，例如执行时间，CPU时间，和内存读取量。

EM提供了一些完全比较性能数据的工具，包括执行统计数据，例如：

执行时间，CPU时间，和内存读取量。如果SQL性能由于一些性能导致性能回退，你需要运行SQL优化顾问来优化SQL语句–立即或者在预定时间。作为任何调优策略，建议在一个时间点只进行一次改变，然后再测试进一步的变化。

你可以根据指定的语句使用SQL优化指导或访问指导，然后实现这些建议。或者呢，你可以用在步骤3中的计划捕获来种于SQL计划管理（SPM），以保证产生的执行计划是一样的。

5.15 小测验

SQL性能分析器不执行下列哪项？

a.优化性能下降

1. 提供前后执行统计数据

c.连续执行sql

d.根据SQL负载性能构建不用版本SQL

答案：b,c,d

5.16访问SQL性能分析器

• 使用EM管理器。
• 使用DBMS_SQLPA包。

你可以通过EM或者使用 DBMS_SQLPA来访问SQL性能分析。

5.17 使用EM访问SQL性能分析

• 访问SQL性能分析器的软件，支持标签。
• 选择五种类型工作流程中的一种：

–从9i或10.1进行升级

–从10.2或11g进行升级

–参数变更

–一体机模拟

–工作流程指导

• 通过调用SQL优化指导来优化性能回退的SQL语句
• 通过SQL执行计划基线来防止性能回退。

你可以从数据库控制台中 软件和支持来访问SQL性能分析，选择数据库实例>顾问>SQL 性能分析.

SQL性能分析为不同的测试场景提供了3种工作流程：

• 从9i或10.1进行升级：测试和分析从9i或10.1进行升级在SQL优化集的性能。
• 从10.2或11g进行升级：测试和分析从10.2或11g进行升级在SQL优化集的性能。
• 参数变更：测试和比较一个初始化参数变化在SQL优化集的性能。一个SQL性能分析器创建的任务，和最初运行阶段都是以参数设置为基准。第二次试运行的参数是其改变的值。重播试验，比较报告，然后重复进行这2个运行。
• EXDATA 模拟：模拟在EXDATA 存储服务器上安装模块在SQL优化集的性能。
• 工作流程指导：创建一个SQL性能分析器的任务和通过手动创建回放实验，执行自定义实验。

你可以直接通过调用SQL优化指导来对所有性能下降的SQL进行优化。作为使用SQL优化指导进行优化的替代方案，你也可以使用SQL执行计划基线来防止性能回退。

5.18 SQL性能分析：PL/SQL 例子

• 创建调优任务：

exec :tname:= dbms_sqlpa.create_analysis_task(sqlset_name => 'MYSTS', task_name => 'MYSPA');

• 执行任务来构建变更前性能数据：

exec dbms_sqlpa.execute_analysis_task(task_name => :tname, execution_type => 'TEST EXECUTE', execution_name => 'before');

• 生产改变前的报告：

SELECT dbms_sqlpa.report_analysis_task(task_name => :tname,type=>'text', section=>'summary') FROM dual;

幻灯片中的例子显示如何使用DBMS_SQLPA包去调用SQL 性能分析来访问一些由于变更而受影响的SQL性能。你可以很轻松的改变这个例子来适应你自己的分析。

1.创建一个优化任务来运行SQL性能分析。

2.执行任务一次来构建变更前性能数据，并且生成变更前的报告（特别的报告设置：set long 10000,longchunksize 100000,和linesize 90）,在这个调用中，你可以指定各种参数，一些参数如下：

-设置 EXECUTION_TYPE 参数：EXPLAIN PLAN 为所有SQL工作负载中的SQL语句收集执行计划。TEST EXECUTE 来执行所有在SQL 负载中的语句。这个过程只执行一部分DML语句，来防止对数据库或用户数据产生负面效果。当TEXT EXECUTE被指定，该程序生成执行计划和执行统计数据。COMPARE[PERFORMANCE] 来分析和比较2个版本的SQL性能数据。CONVERT SQLTEST 作为一个任务执行来读取SQL优化集中被捕获的统计资料，然后建立模型作为执行任务。

-使用EXECUTION_PARAMS来指定执行参数，如需要dbms_advisor.arglist(name,value,…)这样来特殊指定。time_limit参数指定了一个执行SQL优化集中所有SQL, 在超时之前的一个全局时间限制。local_time_limit参数指定了一个执行SQL优化集中所有SQL, 在超时之前的一个时间限制。

在改变之后

• 创建改变后的性能数据：

EXEC dbms_sqlpa.execute_analysis_task(task_name => :tname, execution_type => 'TEST EXECUTE', execution_name => 'after');

• 收集改变后的报告

SELECT dbms_sqlpa.report_analysis_task(task_name => :tname,type=>'text', section=>'summary') FROM dual;

• 对比执行任务

EXEC dbms_sqlpa.execute_analysis_task(task_name => :tname,execution_type => 'COMPARE PERFORMANCE');

• 收集分析报告

SELECT dbms_sqlpa.report_analysis_task(task_name => :tname,type=>'text', section=>'summary') FROM dual;

3.创建变更。

4.在创建变更后再次执行任务，然后收集变更后的报告。

5.对比2次执行，然后收集和分析报告。使用不同的执行参数，你可以参考下列执行命令：

EXEC dbms_sqlpa.execute_analysis_task(task_name => :tname,execution_type => 'COMPARE PERFORMANCE');

注意：更多关于DBMS_SQLPA包的信息，可以参考Oracle Database PL/SQL Packages and Types Reference Guide。

5.19 优化性能回退的SQL语句

使用SQL 性能分析来优化性能回退的SQL语句，使用DBMS_SQLTURNE.CREATE_TUNING_TASK，为SQL性能分析执行器创建一个SQL优化任务：

BEGINDBMS_SQLTUNE.CREATE_TUNING_TASK(
spa_task_name => 'MYSPA',

spa_compare_exec => 'MYCOMPEXEC');

END;

/

如果只有很少的SQL语句出现了性能回退，考虑使用SQL 优化指导来对每个sql单独进行解决。使用DBMS_SQLTUNE.CREATE_TUNING_TASK函数，为SQL性能分析执行器创建一个SQL优化任务。这个CREATE_TUNING_TASK函数有以下参数：在查看了SQL性能分析报告之后，你可以比较SQL性能之后，对那些确实发生性能回退的SQL进行优化。如果出现了大量的SQL性能下降，尝试去找到根本愿意，然后在系统级别改变来解决这个问题。

• SPA_TASK_NAME：SQL 性能优化任务的名称。
• SPA_TASK_OWNER:指定SQL性能分析任务的拥有者。如果不指定，这个人参数默认是当前用户。
• SPA_COMPARE_EXEC：为指定的SQL性能分析任务进行比较性能试验的执行名称。如果不指定，这个参数默认是最近一次给定SQL性能分析任务的COMPARE PERFORMANCE类型。

在优化性能回退的SQL语句之后，使用SQL性能分析对发生的改变进行测试。在测试系统上执行一个新的SQL实验，其次比较（这个新的SQL和第一此SQL之间的实验）来验证你的结果。在SQL性能分析显示性能稳定之后，你可以实施那些变更。

5.20：测试数据库升级：oracle9i 和oracle 10gR1

• SQL性能分析支持对oracle 9i和oracle 10gR1升级到oracle 10gR2或者更高版本进行测试。
• 通过DB link远程连接到升级的数据库进行SQL调优设置。
• 你要升级的生产系统必须是oracle9i 或者oracle 10g R1
• 做升级测试的系统必须是oracle 10g R2(10.2.0.2)或者更高的版本。
• 建立一个独立的系统SQL性能分析：

oracle 11g (11.1.0.7) 或更高的版本

SQL性能分析器支持Oracle9i和Oracl 10g Release 1升级到 Oracle 10g Release 2和以后的版本，升级数据库测试通过执行SQL调优设置远程数据库链接升级数据库。因为SQL 性能分析只允许一组SQL语句存储在SQL优化集里面作为它的输入源，sql优化集在9i中并不支持，如果你是从9i开始升级，必须考虑到一个优化集是否能作为SQL性能分析的输入源。

升级的生产系统必须是oracle9i或者是oracle 10g R1.要升级到测试系统必须是10gR2(10.2.0.2)或者更高版本。如果你要升级到10.2.0.2 ,10.2.0.3或者10.2.0.4，在继续进行之前，还需要安装一个一次性补丁

为运行在oracle 11g R1（11.1.0.7）或者之后版本上的SQL性能分析配置一个单独的系统。使用这个系统来建立一个SQL调优设置和运行SQL性能分析。你不许需要在这个系统上的生产数据或构架，因为SQL 优化集会使用生产系统的SQL 跟踪文件中存储的统计信息创建。SQL 性能分析任务会通过你指定的DBlink远程到测试系统执行，来为SQL实验收集执行计划和统计数据。这个DBlink必须是一个公共的DBlink，而且连接的用户在测试系统中需要有执行DBMS_SQLPA 包和ADVISOR的权限。你还需要删除掉在测试系统上，用户方案下中所有存在的PLAN_TABLE。

5.21 测试数据库升级：oracle 9i 和oracle 10g R1

在oracle 9i 或者 oracle 10g R1 升级到新版本数据库中使用SQL性能分析执行以下步骤：

1.在生产系统上开启SQL跟踪。

1. 在生产系统上，创建一个映射表。

3.将SQL 跟踪文件和映射表从生产系统移动到SQL性能分析系统。

4.在sql性能分析系统，使用SQL跟踪文件构造一个SQL优化集。

5.在SQL性能分析系统：

-使用SQL性能分析来创建一个SQL性能分析任务，将在SQL优化集中的内容放置到一个预升级sql实验中，这将被作为基准。

-通过dblink远程连接到测试系统，执行测试sql来生成一个预升级sql实验

6.比较sql性能和修复性能回退的sql。

在oracle 9i 或者 oracle 10g R1 升级到新版本数据库中使用SQL性能分析执行以下步骤：

1. 在生产系统上开启SQL跟踪。考虑到只对一部分必须需要的会话开启SQL跟踪，对那些重要的SQL至少捕获一次。

2.在生产系统，创建一个映射表，将被用于在SQL跟踪文件中转换用户和对象标识符号码到对应的字符串。

1. 将SQL 跟踪文件和映射表从生产系统移动到SQL性能分析系统
2. 在sql性能分析系统，使用SQL跟踪文件构造一个SQL优化集。SQL优化集会包含SQL 跟踪文件中的SQL语句，连同其相关的执行上下文和统计数据。
3. 使用SQL性能分析来创建一个SQL性能分析任务，将在SQL优化集中的内容放置到一个预升级sql实验中，这将被作为基准. 通过dblink远程连接到测试系统，执行测试sql来生成一个预升级sql实验.你可以通过EM或者DBMS_SQLPA来访问SQL性能分析。
4. 比较sql性能和修复性能回退的sql

对任何更改进行测试，重复执行SQL优化集和比较它们在此之前的性能，直到你对结果觉得满意为止。

5.22 测试数据库升级：oracle 10g R2 和之后的版本

• SQL 性能分析支持数据升级到 10R2或之后的任何版本
• 在生产系统捕获一个SQL优化集，然后通过DB link远程到测试系统上执行2次。
• 将要升级的生产系统必须运行在oracle 10g R2或者之后更高的版本。
• 配置一个单独的系统来运行SQL性能的分析：oracle 11g R1(11.1.0.7)或者更高的版本。

你可以通过在生产系统抓取一个SQL优化集，然后通过DB link远程连接到测试系统上执行它2次–第一次创建一个变更前的SQL实验，第二次创建变更后的SQL实验，

来使用SQL 性能分析去测试 数据库从oracle 10g R2 或者之后的版本升级到任何更高的版本后，对SQL响应时间造成的影响。

将要升级的生产系统必须运行在oracle 10g R2或者之后更高的版本。首先，测试系统必须运行在相同的版本。为了保证SQL 性能分析生成的分析是准确的，测试系统应该包含生产系统的一个精确数据拷贝。在硬件上的配置，测试环境应该尽可能的于生成环境类似。

配置一个单独的系统来运行SQL性能的分析：oracle 11g R1(11.1.0.7)或者更高的版本。使用这个系统来构架一个SQL优化集和运行SQL性能分析。这个系统不需要生产数据和方案，因为SQL优化集将被存储在生产系统中，产生的SQL跟踪文件中的统计数据构建。SQL性能分析任务将通过你指定的DBlink远程到测试系统上执行，为SQL实验收集执行计划和统计数据。这个DBlink必须是一个公共的DBlink，而且连接的用户在测试系统中需要有执行DBMS_SQLPA 包和ADVISOR的权限。你还需要删除掉在测试系统上，用户方案下中所有存在的PLAN_TABLE。

执行以下步骤使用SQL性能分析从Oracle数据库10g Release 2数据库升级和以后的版本到新版本：

1.在生产系统上，抓取那些你打算分析的SQL负载，存储到SQL优化集中。

1. 建立测试系统，使其与生产环境尽可能接近。

3.传输SQL优化集到SQL 性能分析系统。

4.在SQL性能分析系统，使用SQL优化集作为输入源，创建SQL性能分析任务。通过DBlink远程到测试数据库上执行测试的SQL语句，构建变更前的SQL实验，这将被作为对比的基准。

5.升级测试系统

6.再一次通过DBlink远程到测试数据库上执行测试的SQL语句，来构建变更后的SQL实验。

1. 比较sql性能和修复性能回退的sql。

对任何更改进行测试，重复执行SQL优化集和比较它们在此之前的性能，直到你对结果觉得满意为止。

5.23 SQL性能分析：数据字典视图

• 在11g 中一些改良的视图：

-DBA{USER}_ADVISOR_TASK:显示分析任务的详细信息

– DBA{USER}_ADVISOR_FINDINGS：显示分析结果

• 11g 中的新视图：

-DBA{USER}_ADVISOR_EXECUTIONS:列出任务执行的元数据信息

– DBA{USER}_ADVISOR_SQLPLANS:显示SQL 执行计划的列表

– DBA{USER}_ADVISOR_SQLSTATS:显示SQL编译和执行统计数据的列表

在11g 中一些改良的视图：

• DBA{USER}_ADVISOR_TASK: 显示任务的详细信息，以完成系统环境变化的影响分析
• DBA{USER}_ADVISOR_FINDINGS：显示分析结果。顾问会产生四种类型的结果：性能回归，症状，错误，和提示信息

11g 中的新视图：

-DBA{USER}_ADVISOR_EXECUTIONS:列出任务执行的元数据信息。SQL性能分析创建至少三个在SQL工作量进行变更影响分析的执行：一个执行在变化之前的版本，收集性能数据的工作量，第二个执行变更后的工作量收集数据，最后执行实际的分析。

– DBA{USER}_ADVISOR_SQLPLANS:显示SQL 执行计划的列表（或者属于那些当前用户）

– DBA{USER}_ADVISOR_SQLSTATS:显示SQL编译和执行统计数据的列表（或者属于那些当前用户）

5.24 总结

在这个课程，你应该学会：

• 确定使用SQL性能分析器的好处
• 描述SQL性能分析器工作流阶段
• 使用SQL性能分析器来确定数据库的变更后性能