Oracle 11g：SQL性能分析器（三）(4)

作者: Jim Czuprynski/黄永兵 译 出处:51CTO.com　

 

 

评估参数改变：情景#3

有不用企业管理器仅执行一系列SQL*plus和PL/SQL命令就能完成相同分析任务的方法吗？值得欣慰的是的确存在这样的方法，结果一些判断正确的和广泛的SQL语句跟踪后，我准确地找到了SPA向导是如何提交这些任务的。

我使用这些语句生成了我最终的初始化参数改变情景：将初始化参数OPTIMIZER_INDEX_COST_ADJ的非默认值25改变为默认值100对性能的影响。正如前面提到的，我希望看到语句LDGN5.1和LDGN5.4在优化器成本上的影响，因为这个参数影响CBO决定使用一个有效的索引而不是一个全表扫描。

我在列表3.2中列出了我执行分析用到的代码，这些语句：
◆创建一个名叫SPA_IPC_300的SQL性能分析任务
◆执行一个“之前”的性能影响分析
◆执行一个“之后”的性能影响分析
◆在“之前”和“之后”性能影响分析之间创建一个对比报告

Oracle 11g使用一个简单的方法执行“之前”和“之后”性能影响分析：在性能分析前使用ALTER_SESSION命令修改初始化参数设置，然后执行SPA分析任务捕获结果，图3.9显示了这个SQL性能分析任务成功执行后的摘要信息页面，图3.9.1和3.9.2显示了SQL语句LDGN5.1分析的详细结果：

图3.9 SQL性能分析任务SPA_IPC_300执行摘要

 

自定义SQL性能分析器报告结果

如果我对SQL性能顾问对比报告机制产生的对比报告外观不满意怎么办？例如，如果我想让指定用于分析的SQL语句按不同的顺序进行存储 -- 假设用优化器成本替代消耗时间（默认）时怎么办？好消息是我可以为摘要报告指定一个不同的报告维度，通过修改存储过程DBMS_SQLPA.EXECUTE_ANALYSIS_TASK的execution_params参数的值来实现。我在前面紧接的例子已经通过选择OPTIMIZER_COST作为对比量度来说明过。
这里是我为这个参数测试过的值，在本文发布时，这些内容在Oracle 11g在线手册中都还没有文档记录。

表3.1 SQL性能分析器分析维度
维度	描述
OPTIMIZER_COST	评估执行语句的总体成本，通过基于成本的优化器进行计算
EXECUTIONS	语句执行消耗的时间
ELAPSED_TIME	执行语句消耗的总体时间（如等待时间wall time），这是默认设置
CPU_TIME	执行语句消耗的总的CPU时间（CPU time）
PARSE_TIME	解析语句消耗的总体时间
BUFFER_GETS	语句需要的完整的总的缓存获取数量（buffer gets）（如缓存读取buffer read + 一致性读取consistent  reads）
DISK_READS	语句执行磁盘读取数量（disk reads）
DIRECT_WRITES	语句执行磁盘写入数量（disk writes）
ROWS_PROCESSED	语句处理的行数（rows）
FETCHES	语句执行提取到数量（fetches）

在地平线上：SQL计划管理器

SQL性能分析器的特性让人不得不佩服，当打算修改系统、数据库升级和应用程序修改时，DBA还存在一个问题：如何有效地使用这些分析来限制性能低劣的SQL语句？它许诺让所有DBA面对那些不确定的事情时能迅速解决。

有两个方面是需要实现的：
◆一旦所有改变完成，确保所有在提交改变的生产环境中毫无疑问最佳执行的SQL语句立即开始使用更好的执行计划，以及
◆确保所有在当前生产环境中执行得很好的SQL语句继续使用它们当前的在提交改变的生产环境中的执行计划

达到这些目的是我下一系列文章将要讲述的：Oracle 11g新的SQL计划管理（SPM）特性

结论

如这一系列文章所展示的，Oracle数据库11g的新SQL性能分析器提供了一个令人佩服的用于在没有为每个测试情景建立测试环境的情况下分析SQL语句性能影响的工具集，因此SQL性能分析器非常明显地减少了Oracle DBA、QA分析员和应用程序开发人员过去花在识别、校验和定位性能低下的SQL语句的时间（在主数据库版本生效后、现有应用程序新版本发布后，或甚至表面上看上去无害的一个初始化参数的修改生效后）。