Oracle SQL执行计划基线总结（SQL Plan Baseline）

1、基础概念

Oracle 11g开始，提供了一种新的固定执行计划的方法，即SQL plan baseline，中文名SQL执行计划基线（简称基线），能够认为是OUTLINE（大纲）或者SQL PROFILE的改进版本，基本上它的主要做用能够概括为以下两个：

一、稳定给定SQL语句的执行计划，防止执行环境或对象统计信息等等因子的改变对SQL语句的执行计划产生影响！

二、减小数据库中出现SQL语句性能退化的几率，理论上不容许一条语句切换到一个比已经执行过的执行计划慢不少的新的执行计划上！

注意：

一、从Oracle的发展角度来看，估计这种方法是Oracle发展和改进的方向，现在outline已经被废弃，sql profile估计在后续的发行版本中也难有改进，所以，对于从11g开始接触Oracle的朋友来讲，必定要对sql计划基线有所了解，由于这是之后的主流！

二、SQL执行计划基线保存在数据字典中，查询优化器会自动判断使用他们。

2、工做机制

从Oracle 11g开始，因为基线的存在，一条语句的解析过程大概以下：

1.SQL语句被硬解析后，CBO（优化器）会产生不少个的执行计划，CBO从中选择一个成本最低执行计划。
2.基于SQL语句的文本造成一个哈希值（signature)，经过这个哈希值来检查数据字典中是否存在一样的基线。
3.若是基线存在，优化器会对刚刚产生的执行计划和保存在SQL plan baseline中的执行计划进行比较。
4.若是基线中有与CBO刚产生的执行计划的匹配的SQL执行计划存在，而且被标记为可接受（‘accepted’），则这个CBO生成的执行计划被启用。
5.若是基线中没有匹配的SQ执行计划存在，CBO评估基线中被标记为‘accepted’的的多个执行计划，并选择其中cost最低的执行计划。（注意，一个语句的基线能够有多个执行计划被保存，这是与其余Outline和SQL profiel都不一样的地方）
6.若是刚刚硬解析过程当中CBO选择的执行计划比保存在基线中的执行计划COST都低，这个新生成的执行计划被标记为‘not-accepted’并保存在基线中。直到这个执行计划被演化且验证后才会被考虑使用，即标记为accepted(演化和验证，能够简单理解为Oracle确认这个执行计划能够带来更好的性能)。

Oracle 就是经过上面这种方式来确保SQL语句的性能不会退化（即第一部分中我概括的第二个主要做用），称为“执行计划保守选择策略”

3、基线的一些特色

简单概括以下几个

1.经过OPTIMIZER_USE_SQL_PLAN_BASELINE来控制Oracle是否使用基线，默认值为TRUE，即会自动使用基线。
2.11g中默认是不会自动建立基线
3.与OUTLINE和SQL Profile不一样，基线中不存在分类的概念
4.与OUTLINE和SQL Profile不一样，每一个SQL语句能够有多个基线。Oracle根据制定的规则来判断具体是否哪一个基线
5.基线针对RAC中全部的实例都生效
6.基线有两个表示，一个为sql_handle，能够理解为表示语句文本的惟一标识，一个为sql_plan_name能够理解为执行计划的惟一标识
7.不能像sql profile同样经过force_matching属性将字面值不同的SQL语句使用一个基线应用多个语句。

3、建立基线的几种方式

一、自动捕获基线，经过将optimizer_cature_sql_plan_baselines设置为true，优化器为重复执行两次以上的SQL语句生成并保存基线（能够系统级或会话级修改）

二、从SQL调优集合中加载，经过使用包dbms_spm.load_plans_from_sqlset来从SQL调优集合中加载基线

DECLARE

l_plans_loaded PLS_INTEGER;

BEGIN

l_plans_loaded := DBMS_SPM.load_plans_from_sqlset(

sqlset_name => 'my_sqlset');

END;

/

三、从库缓存中加载，经过包dbms_spm.load_plans_from_cursor_cache函数为一条已经在游标缓存中的语句建立基线

DECLARE

l_plans_loaded PLS_INTEGER;

BEGIN

l_plans_loaded := DBMS_SPM.load_plans_from_cursor_cache(sql_id => '1fkh93md0802n',plan_hash_value=>null);

END;

/

备注：能够有多种方式加载，例如能够根据sql文本进行模糊匹配、SQL语句解析的用户名等等方式，具体见文档

4、基线的几种状态

一个SQL语句对应的基线，我将它们概括为三种状态

1.accepted（可接受），只有这种状态的基线，优化器才会考虑此基线中的执行计划
2.no-accepted（不可接受），这种状态的基线，优化器在SQL语句解析期间不会考虑。这种状态的基线必须经过演化和验证经过后，转变为accepted状态后，才会被优化器考虑使用
3.fixed为yes（固定），这种状态的基线固有最高优先级！比其余两类基线都要优先考虑

5、查看基线

一、基本视图：dba_sql_plan_baselines、dba_sql_management_config

二、底层视图：sqlobj$data 、 sqlobj$ （保存具体的hint），以下查看基线中保存的执行计划语句：

select

extractvalue(value(d), '/hint') as outline_hints

from

xmltable('/outline_data/hint'

passing (

select

xmltype(comp_data) as xmlval

from

sqlobj$data sod, sqlobj$ so

where so.signature = sod.signature

and so.plan_id = sod.plan_id

and comp_data is not null

and name like '&baseline_plan_name'

)

) d;

三、经过函数来查看基线的详细信息：

select * from table(dbms_xplan.display_sql_plan_baseline(sql_handle=>'SYS_SQL_11bcd50cd51504e9',plan_name=>'SQL_PLAN_13g6p1maja1790cce5f0e'));

6、演化基线

为了验证基线中一个处于不可接受状态的执行计划是否比一个处于可接受状态的执行计划具备更高的效率，必须经过演化来验证，须要让优化器以不一样的执行计划来执行这条SQL语句，观察不可接受状态的执行计划基线是否会带来更好的性能，若是性能确实更高，这个不可接受状态的基线将会转换为可接受状态。演化的方式有两种：

一、手工执行运行

SELECT DBMS_SPM.evolve_sql_plan_baseline(sql_handle => 'SYS_SQL_xxxxxxxxxxxxx') From dual;

还有time_limit/verify/commit几个参数，能够参考文档

二、调优包实现基线的自动演化，能够理解为，启动一个调度任务，周期性的检查是否有不可接受状态的基线能够被演化

7、修改基线

能够经过dbms_spm.alter_sql_plan_baseline包来修改基线的一些属性，主要有以下几个属性

1.ENABLED ：设置该属性的值为NO告诉Oracle 11g临时禁用某个计划，一个SQL计划必须同时标记为ENABLED和ACCEPTED，不然CBO将忽略它
2.FIXED：设置为YES，那个计划将是优化器惟一的选择[最高优先级]，即便若是某个计划可能拥有更低的成本。这让DBA能够撤销SMB的默认行为，对于转换一个存储概要进入一稳定的SQL计划基线特别有用，注意当一个新计划被添加到被标记为FIXED的SQL计划基线，该新计划不能被利用除非它申明为FIXED状态
3.AUTOPURG：设置这个属性的值为NO告诉Oracle 11g无限期保留它，从而不用担忧SMB的自动清除机制
4.plan_name : 改变SQL plan 名字
5.description : 改变SQL plan描述

语法：

SET SERVEROUTPUT ON

DECLARE

v_text PLS_INTEGER;

BEGIN

v_text := DBMS_SPM.alter_sql_plan_baseline(sql_handle => 'SYS_SQL_xxxxxx',plan_name => 'SYS_SQL_PLAN_xxxxxxxxx',

attribute_name => 'fixed',attribute_value => 'YES');

DBMS_OUTPUT.put_line('Plans Altered: ' || v_text );

END;