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;