Oracle执行计划变更

SQL执行计划变更导致数据库负载突升。Oracle的CBO模式会根据字段的取值比重调整对应的执行计划，无论如何，都会选择成本值最低的一个执行计划，这也是CBO优于以前RBO的地方，这里仅用于实验，因为一般OLTP的应用会使用绑定变量的写法，不会像上面这种使用常量值的写法，11g之前，可能带来的一些负面影响就是绑定变量窥探的作用，即对于使用绑定变量窥探的SQL语句，Oracle会根据第一次执行使用的绑定变量值来用于以后的执行，即第一次做硬解析的时候，窥探了变量值，之后的软解析，不再窥视，换句话说，如果上面实验的SQL语句使用了绑定变量，第一次执行时name=’A’(99.9%)，则接下来即使使用name=’B’(0.1%)的SQL语句仍会使用全表扫描，不会选择索引扫描，vice versa。相关的实验dbsnake的书中会有很详细的说明，可以参考。11g之后，有了ACS自适应游标的新特性，会根据绑定变量值的情况可以重新生成执行计划，因此这种问题得到了缓解，当然这些都是有代价的，缓解了绑定变量窥探的副作用，相应地可能会导致有很多子游标，具体的算法可以参考dbsanke的书。11g默认绑定变量窥探是开启的，由optim peek user binds隐藏参数控制

--     1.查询当前在活动的会话获得SQL_ID值
select a.USERNAME,
       a.SQL_ID,
       a.SID,
       a.MACHINE,
       a.PROGRAM,
       a.sql_hash_value,
       a.blocking_session_status
  from v$session a
 where a.status = 'ACTIVE'
   AND a.SCHEMA# > 0;


--     2.获得此sql_id对应的sql语句 
select sql_id, sql_fulltext from v$sql where sql_id = '9j2c5zhzvsfd7';


--     3.查询此sql_id历史执行信息
select a.INSTANCE_NUMBER,
       a.snap_id,
       a.sql_id,
       a.plan_hash_value,
       b.begin_interval_time
  from dba_hist_sqlstat a, dba_hist_snapshot b
 where sql_id = '9j2c5zhzvsfd7'
   and a.snap_id = b.snap_id
 order by instance_number, snap_id;


--     4.查询变更前后的执行计划
select sql_id,
       plan_hash_value,
       id,
       operation,
       options,
       object_owner,
       object_name,
       depth,
       cost,
       timestamp
  from DBA_HIST_SQL_PLAN
 where sql_id = 'dxx8pvcttf5qv'
   and plan_hash_value in (1904478120, 2125777269);


--     5.根据执行计划的不同点查找原因-使用coe_xfr_sql_profile.sql可以发现两种执行计划的效率(AVG_ET_SECS)
select *
  from dba_objects
 where object_name = 'MOD_LOTHISTORY_IDX01'
   and owner = 'MDWMGR'
 order by last_ddl_time desc;