12cR1出现的 Adaptive Plans新特性的个人理解

12cR1出现的 Adaptive Plans新特性的个人理解
参考文章1:
adaptive plan的官方文档:
http://docs.oracle.com/database/121/TGSQL/tgsql_optcncpt.htm#TGSQL94982
参考文章2:
MOS的文章:Adaptive Execution Plans (文档 ID 1409636.1)
大家知道,
--------------------------------------------------------------------------------
| Id| Operation                    |Name             |Rows|Bytes|Cost %CPU|Time|
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT             |                 | 10| 250| 3 (0)| 00:00:01|
| 1 |  NESTED LOOPS                |                 |   |    |      |         |
| 2 |   NESTED LOOPS               |                 | 10| 250| 3 (0)| 00:00:01|
|*3 |    TABLE ACCESS FULL         |DEPARTMENTS      |  1|   7| 2 (0)| 00:00:01|
|*4 |    INDEX RANGE SCAN          |EMP_DEPARTMENT_IX| 10|    | 0 (0)| 00:00:01|
| 5 |   TABLE ACCESS BY INDEX ROWID|EMPLOYEES        | 10| 180| 1 (0)| 00:00:01|
上面的执行计划中的Rows列,Bytes列,Cost %CPU列,Time列都是CBO根据统计信息计算出来的(详情请见http://docs.oracle.com/database/121/TGSQL/tgsql_optcncpt.htm#TGSQL213),
上面的执行计划中的Rows列,Bytes列,Cost %CPU列,Time列不是SQL语句实际执行时的真实返回值.

那么为了高效的执行SQL,尽量减小CBO生成的执行计划在实际执行时偏差(该偏差是指某一行的执行计划的实际返回行数A-Rows 跟 该行执行计划的估计返回行数E-Rows 之间存在巨大差异),那么,Adaptive Execution Plans 就有了用武之地.

我理解的Adaptive Execution Plans 的工作原理是:
在SQL语句实际执行时,在optimizer statistics collector的作用(收集SQL执行时的信息,缓存subplan的返回行数)之下,优化器确定一个更加优化的执行计划.

如下摘自参考文章1:
Purpose of Adaptive Plans
The ability of the optimizer to adapt a plan, based on information learned during execution, can greatly improve query performance. 
Adaptive plans are useful because the optimizer occasionally picks a suboptimal default plan because of a cardinality misestimate. 
The ability to adapt the plan at run time based on actual execution statistics results in a more optimal final plan. 
After choosing the final plan, the optimizer uses it for subsequent executions, thus ensuring that the suboptimal plan is not reused.
How Adaptive Plans Work
An adaptive plan contains multiple predetermined subplans, and an optimizer statistics collector. 
A subplan is a portion of a plan that the optimizer can switch to as an alternative at run time. 
For example, a nested loops join could be switched to a hash join during execution.
 An optimizer statistics collector is a row source inserted into a plan at key points to collect run-time statistics.
 These statistics help the optimizer make a final decision between multiple subplans.

During statement execution, the statistics collector gathers information about the execution, and buffers some rows received by the subplan. 
Based on the information observed by the collector, the optimizer chooses a subplan. 
At this point, the collector stops collecting statistics and buffering rows, and permits rows to pass through instead. 
On subsequent executions of the child cursor, the optimizer continues to use the same plan unless the plan ages out of the cache,
 or a different optimizer feature (for example, adaptive cursor sharing or statistics feedback) invalidates the plan.

与本特性有关的数据库初始化参数:

OPTIMIZER_FEATURES_ENABLE is 12.1.0.1 or later
OPTIMIZER_ADAPTIVE_REPORTING_ONLY initialization parameter is set to the default of false
OPTIMIZER_ADAPTIVE_FEATURES  enables 

另外注1
查看执行计划是不是adaptive plan的方法(之一),

------------------------------------------------------------------------------------------------
|Id | Operation          | Name         |Starts|E-Rows|A-Rows|A-Time|Buff|Reads|OMem|1Mem|O/1/M|
------------------------------------------------------------------------------------------------
| 0| SELECT STATEMENT   |                     |1| | 13|00:00:00.10 |21 |17 |      |      |     |
|*1|  HASH JOIN         |                     |1|4| 13|00:00:00.10 |21 |17 | 2061K| 2061K|1/0/0|
|*2|   TABLE ACCESS FULL| ORDER_ITEMS         |1|4| 13|00:00:00.07 | 5 | 4 |      |      |     |
| 3|   TABLE ACCESS FULL| PRODUCT_INFORMATION |1|1|288|00:00:00.03 |16 |13 |      |      |     |
------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   1 - access("P"."PRODUCT_ID"="O"."PRODUCT_ID")
   2 - filter(("O"."UNIT_PRICE"=15 AND "QUANTITY">1))
 
 
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------
Note
-----
   - this is an adaptive plan     -------------->>>>>>>>>>>>>>>>注意此处!!!

查看执行计划是不是adaptive plan的方法(之二):

v$SQL视图的IS_RESOLVED_ADAPTIVE_PLAN列:
If IS_RESOLVED_ADAPTIVE_PLAN is set to ‘Y’, it means that the plan was not only adaptive, but the final plan has been selected.
If IS_RESOLVED_ADAPTIVE_PLAN is set to ‘N’, it indicates the plan selected is adaptive but the final plan has not yet been decided on.  

详情请参考:How to Determine if a SQL Statement is Using an Adaptive Execution Plan with V$SQL (文档 ID 2043960.1)

另外注2:

获得 某一行的执行计划的实际返回行数A-Rows 和 该行的估计返回行数E-Rows的方法:
set lines 300
alter session set statistics_level=all;
select * from t1 where id=88 and n=88;
select * from table(dbms_xplan.display_cursor(null,null,'advanced ALLSTATS LAST'));

你可能感兴趣的:(Oracle,DB,12c,Oracle,DB,12c新特性)