标签:
1.1控制执行计划的稳定性
1.2 11g执行计划管理
凭什么来判断是否可以使用一个新产生的执行计划呢?就是把该新的执行计划与plan baseline里的计划进行比较来判断。 某个SQL语句的执行计划可以属于plan history,但是不一定属于plan baseline。
2.1 OPTIMIZER_CAPTURE_PLAN_BASELINES
OPTIMIZER_CAPTURE_PLAN_BASELINES=true,则会自动的捕获SQL的执行计划,但该参数缺省为false。
当某条SQL语句第一次执行时,该SQL语句的plan history是空的,显然该SQL语句的plan baseline也是空的。 那么当该SQL第二次再次执行时,优化器会自动将该SQL语句以及相关的执行计划放入plan history,同时也会放入到plan baseline里。
当你做了某些修改(比如添加了一个索引等),然后第三次执行该同样的SQL语句,则会产生另外一个不同的执行计划。这时新的执行计划会自动进入plan history,但是不会自动进入plan baseline。 是否使用该新的执行计划,则要把该新的执行计划与plan baseline里现存的第二次执行SQL时的执行计划进行比较, 如果新的执行计划成本更低,则会使用新的执行计划,否则使用plan baseline里的执行计划。
2.2 DBMS_SPM
使用该包,可以直接将SQL的执行计划从shared pool里加载到plan baseline里,也可以使用dbms_spm包将已经存在的SQL Tuning Set加载到plan baseline里。
同时,dbms_spm可以让你把plan history里的执行计划加入到plan baseline里。反之,也可以使用该包将plan baseline里的执行计划移出去。
注意,某条SQL语句的plan baseline里的第一个执行计划可以像上面说的通过设置初始化参数来自动加入,但是如果你希望在plan baseline里添加该SQL语句的其他新的执行计划时,则必须使用dbms_spm包手动完成。
OPTIMIZER_USE_PLAN_BASELINES参数缺省为true,表示要求优化器考虑使用plan baseline里的执行计划,如果设置为false,则不使用执行计划管理的特性,而又回到了11g之前的状况。
场景:以下描述基于的前提是plan baseline里已经存在了一个SQL的执行计划.
每次优化器解析SQL语句的时候,首先仍然使用11g之前的传统方式产生一个成本最低的执行计划,然后看初始化参数:OPTIMIZER_USE_PLAN_BASELINES.
整理自网络:http://tech.it168.com/db/2007-07-23/200707231104640.shtml
标签:
原文地址:http://www.cnblogs.com/polestar/p/4457368.html