关于Oracle 调整存在着许多神秘和规则
我是否应该分割这个表?
我应该使用什么分区scheme?
我应该将OPTIMIZER_INDEX_COST_ADJ和OPTIMIZER_INDEX_CACHING的值设为什么?
我是否应该定期重建我的索引?
还有许多问题在这个领域的一些德高望重的专家包括Tom Kyte和Jonathan Lewis提出了证明它的方法论问题是构建测试用例和试验的时间可能稍稍受限
进入SQL Performance Analyzer(SQL性能分析器SPA)这是我最喜欢的g新特性之一SQL Performance Analyzer允许你捕捉一个sql调整工具集可以很多次地回去使用不同选择来重新执行然后获得改变后的结果
让我们快速浏览一下这个过程
捕捉一个SQL调整工具集这是一个从数据库控制台进行的一个步骤在我后面的例子里我告诉它去捕捉用户FLOWS_在之后的两分钟执行的所有SQL然后我运行Application Express builder来生成SQL
运行SQL Performance Analyzer Guided Workflow向导
第一次替换SQL调整工具集
改变一些参数或数据结构
第二次替换SQL调整工具集
比较这两个调整工具集并存储结果
查看这个结果包括改进或退后的SQL以及改变了的所有SQL计划
示例
这是一个例子我们来看看改变OPTIMIZER_INDEX_COST_ADJ和OPTIMIZER_INDEX_CACHING 的影响正如我先前所提到的我们要使用的调整工具集是用户FLOWS_执行的SQL所以这不是测试这个改变对整个数据库的影响但是你可以捕捉整个数据库的调整工具集来测试这个影响这里不会进行向导的所有个步骤因为没有那么多要看的我会解释整个过程包括捕捉SQL调整工具集这只需要分钟
要从g数据库控制台里到SQL Performance Analyzer点击Performance标签然后点击右下角的SQL Performance Analyzer之后再点击Guided Workflow下面是Guided Workflow 向导的一个截屏
在开始第二步之前运行下面的代码
图
在开始第三步之前运行下面的代码
图
下面是结果的截屏注意这条SQL语句中条有错误这是由于在APEX 中的DML操作所以在这不是问题但是这是一个要注意的地方还要注意有%的改进作用和%的衰退影响
让我们看一个SQL语句的细节以便我们可以看到在这个语句上的改变详情
图
最后下面两个截屏是从一个改变了的SQL计划的细节得来的显示了旧计划和新计划
旧的计划
图
新的计划
图
正如你所看到的新计划使用了一个索引而旧计划没有
过去测试针对一条SQL语句的变更相对简单但是测试条以上的语句或者是整个数据库中的每条语句这几乎是不可能的所以这是数据库管理员和开发人员之类的人非常欢迎的一个特性作为一个开发人员你可以在你提出请求之前测试任何你希望你的数据库管理员要做的性能变更作为一个数据库管理员你可以在对产品做更改之前查看所有潜在的变更所带来的影响这可以显着地降低风险
