Oracle优化器之基数反馈（CardinalityFeedback）功能
概述
在Oracle 11gR2的版本上推出了基数反馈（Cardinality Feedback 之后简称CFB）功能，经过这个特性，对于某些查询在第一次执行时，若是CBO发现根据统计信息估算出的基数(Computed cardinality)和SQL执行时的实际值差距很大的状况发生时，在SQL下次执行时，会根据实际值调整基数，从新生成执行计划。ios
另外，基数反馈 （CFB）在12c版本上获得更进一步的扩展改称为统计反馈（Statistics Feedback），成为12c自动从新优化（Automatic Reoptimization）的一部分。
关于这统计反馈（Statistics Feedback）中扩展的内容和12c自动从新优化（Automatic Reoptimization）的内容，将在之后的章节中进行介绍。sql
下面咱们将经过几个例子来了解一下CFB功能。数据库
例子1（CFB无效）
首先咱们在10.2.0.5的环境中也就是CFB无效的状况下，看看执行的状况：
（咱们使用了Oracle数据库提供的样例Schema OE 及其表PRODUCT_INFORMATION和ORDER_ITEMS进行测试。）session
1.首先确认相关表的统计信息和表的数据量。（基于10.2.0.5版本测试）ide
--统计信息可以反映出表中的数据量。
SQL> select TABLE_NAME,NUM_ROWS,BLOCKS from user_tables where TABLE_NAME in ('PRODUCT_INFORMATION','ORDER_ITEMS');
TABLE_NAME NUM_ROWS BLOCKS
-------------------- ---------- ----------
ORDER_ITEMS 665 5
PRODUCT_INFORMATION 288 13
SQL> select count(*) from ORDER_ITEMS;
COUNT(*)
----------
665
SQL> select count(*) from PRODUCT_INFORMATION;
COUNT(*)
----------
288
2.设定环境参数statistics_level为ALL，以便可以经过dbms_xplan.display_cursor函数查看SQL文根据统计信息估算出的访问数据行数和SQL执行时的实际值。函数
SQL> alter session set statistics_level=all; Session altered.
3.第一次执行SQL测试
SQL> SELECT o.order_id, v.product_name
2 FROM orders o,
3 ( SELECT order_id, product_name
4 FROM order_items o, product_information p
5 WHERE p.product_id = o.product_id
6 AND list_price < 50
7 AND min_price < 40 ) v
8 WHERE o.order_id = v.order_id
9 ;
ORDER_ID PRODUCT_NAME
---------- --------------------
2354 Sound Card STD
...
2457 Graphics - DIK+
269 rows selected.
4.查看第一次执行后的执行计划优化
SQL> select * from table(dbms_xplan.display_cursor(NULL, NULL,'typical iostats last -cost -bytes'));
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------
SQL_ID bmh5hb8331u33, child number 0
-------------------------------------
SELECT o.order_id, v.product_name FROM orders o, ( SELECT order_id, product_name FROM
order_items o, product_information p WHERE p.product_id = o.product_id AND list_price < 50
AND min_price < 40 ) v WHERE o.order_id = v.order_id
Plan hash value: 1906736282
---------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | E-Time | A-Rows | A-Time | Buffers | Reads |
---------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | | 269 |00:00:00.44 | 9189 | 20 |
| 1 | NESTED LOOPS | | 1 | 1 | 00:00:01 | 269 |00:00:00.44 | 9189 | 20 |
| 2 | MERGE JOIN CARTESIAN| | 1 | 4 | 00:00:01 | 9135 |00:00:00.17 | 35 | 15 |
|* 3 | TABLE ACCESS FULL | PRODUCT_INFORMATION | 1 | 1 ★| 00:00:01 | 87 ★|00:00:00.01 | 34 | 14 |
| 4 | BUFFER SORT | | 87 | 105 | 00:00:01 | 9135 |00:00:00.07 | 1 | 1 |
| 5 | INDEX FULL SCAN | ORDER_PK | 1 | 105 | 00:00:01 | 105 |00:00:00.01 | 1 | 1 |
|* 6 | INDEX UNIQUE SCAN | ORDER_ITEMS_UK | 9135 | 1 | | 269 |00:00:00.18 | 9154 | 5 |
---------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter(("MIN_PRICE"<40 AND "LIST_PRICE"<50))
6 - access("O"."ORDER_ID"="ORDER_ID" AND "P"."PRODUCT_ID"="O"."PRODUCT_ID")
26 rows selected.
SQL> ---查看V$SQL的统计信息。
SQL> select sql_id,child_number, executions, buffer_gets,plan_hash_value
2 from v$sql
3 where sql_id = 'bmh5hb8331u33';
SQL_ID CHILD_NUMBER EXECUTIONS BUFFER_GETS PLAN_HASH_VALUE
------------- ------------ ---------- ----------- ---------------
bmh5hb8331u33 0 1 9701 1906736282
咱们发现因为访问条件(“MIN_PRICE”<40 AND “LIST_PRICE”<50)的影响，优化器认为PRODUCT_INFORMATION表的预估行数（E-Rows）为1，优化器基于预估基数在选择表PRODUCT_INFORMATION和ORDER_ITEMS结合的最优执行计划时，选择了MERGE JOIN CARTESIAN的结合方式。
但实际实际访问行数（A-Time：87），所以因为预估基数不许，颇有可能致使选择的执行计划不是最优的。this
5.咱们再屡次执行相同的SQL文spa
---第二次执行
SQL> SELECT o.order_id, v.product_name
2 FROM orders o,
3 ( SELECT order_id, product_name
4 FROM order_items o, product_information p
5 WHERE p.product_id = o.product_id
6 AND list_price < 50
7 AND min_price < 40 ) v
8 WHERE o.order_id = v.order_id
9 ;
ORDER_ID PRODUCT_NAME
---------- --------------------
2354 Sound Card STD
...
2457 Graphics - DIK+
269 rows selected.
SQL>
---第二次执行的执行计划
SQL> select * from table(dbms_xplan.display_cursor(NULL, NULL,'typical iostats last -cost -bytes'));
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------
SQL_ID bmh5hb8331u33, child number 0
-------------------------------------
SELECT o.order_id, v.product_name FROM orders o, ( SELECT order_id, product_name FROM
order_items o, product_information p WHERE p.product_id = o.product_id AND
list_price < 50 AND min_price < 40 ) v WHERE o.order_id = v.order_id
Plan hash value: 1906736282
------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | E-Time | A-Rows | A-Time | Buffers |
------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | | 269 |00:00:00.45 | 9189 |
| 1 | NESTED LOOPS | | 1 | 1 | 00:00:01 | 269 |00:00:00.45 | 9189 |
| 2 | MERGE JOIN CARTESIAN| | 1 | 4 | 00:00:01 | 9135 |00:00:00.17 | 35 |
|* 3 | TABLE ACCESS FULL | PRODUCT_INFORMATION | 1 | 1 | 00:00:01 | 87 |00:00:00.01 | 34 |
| 4 | BUFFER SORT | | 87 | 105 | 00:00:01 | 9135 |00:00:00.06 | 1 |
| 5 | INDEX FULL SCAN | ORDER_PK | 1 | 105 | 00:00:01 | 105 |00:00:00.01 | 1 |
|* 6 | INDEX UNIQUE SCAN | ORDER_ITEMS_UK | 9135 | 1 | | 269 |00:00:00.18 | 9154 |
------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter(("MIN_PRICE"<40 AND "LIST_PRICE"<50))
6 - access("O"."ORDER_ID"="ORDER_ID" AND "P"."PRODUCT_ID"="O"."PRODUCT_ID")
26 rows selected.
---第三次执行的执行计划
SQL> SELECT o.order_id, v.product_name
2 FROM orders o,
3 ( SELECT order_id, product_name
4 FROM order_items o, product_information p
5 WHERE p.product_id = o.product_id
6 AND list_price < 50
7 AND min_price < 40 ) v
8 WHERE o.order_id = v.order_id
9 ;
ORDER_ID PRODUCT_NAME
---------- --------------------
2354 Sound Card STD
...
2457 Graphics - DIK+
269 rows selected.
--第三次执行的执行计划
SQL> select * from table(dbms_xplan.display_cursor(NULL, NULL,'typical iostats last -cost -bytes'));
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------
SQL_ID bmh5hb8331u33, child number 0
-------------------------------------
SELECT o.order_id, v.product_name FROM orders o, ( SELECT order_id, product_name FROM
order_items o, product_information p WHERE p.product_id = o.product_id AND
list_price < 50 AND min_price < 40 ) v WHERE o.order_id = v.order_id
Plan hash value: 1906736282
------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | E-Time | A-Rows | A-Time | Buffers |
------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | | 269 |00:00:00.45 | 9189 |
| 1 | NESTED LOOPS | | 1 | 1 | 00:00:01 | 269 |00:00:00.45 | 9189 |
| 2 | MERGE JOIN CARTESIAN| | 1 | 4 | 00:00:01 | 9135 |00:00:00.16 | 35 |
|* 3 | TABLE ACCESS FULL | PRODUCT_INFORMATION | 1 | 1 | 00:00:01 | 87 |00:00:00.01 | 34 |
| 4 | BUFFER SORT | | 87 | 105 | 00:00:01 | 9135 |00:00:00.07 | 1 |
| 5 | INDEX FULL SCAN | ORDER_PK | 1 | 105 | 00:00:01 | 105 |00:00:00.01 | 1 |
|* 6 | INDEX UNIQUE SCAN | ORDER_ITEMS_UK | 9135 | 1 | | 269 |00:00:00.19 | 9154 |
------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter(("MIN_PRICE"<40 AND "LIST_PRICE"<50))
6 - access("O"."ORDER_ID"="ORDER_ID" AND "P"."PRODUCT_ID"="O"."PRODUCT_ID")
26 rows selected.
咱们发现，虽然根据统计信息估算出的基数(Computed cardinality)和SQL执行时的实际值不一样，可是之后的执行过程当中，SQL文依然会利用之前的执行计划（软解析）。
在这个状况下，颇有可能因为最初优化器没有选择最优的执行计划，在之后的重复执行中也得不到改进而致使效率问题。
例子2（CFB有效）
下面咱们在11.2.0.4的环境中也就是CFB有效的状况下，看看执行的状况：
（咱们依然使用Oracle数据库提供的样例Schema OE 及其表PRODUCT_INFORMATION和ORDER_ITEMS进行测试。）
1.首先确认相关表的统计信息和表的数据量。（基于11.2.0.4版本测试）
--统计信息可以反映出表中的数据量。
SQL> select TABLE_NAME,NUM_ROWS,BLOCKS from user_tables where TABLE_NAME in ('PRODUCT_INFORMATION','ORDER_ITEMS');
TABLE_NAME NUM_ROWS BLOCKS
-------------------- ---------- ----------
ORDER_ITEMS 665 5
PRODUCT_INFORMATION 288 13
Elapsed: 00:00:00.04
SQL> select count(*) from ORDER_ITEMS;
COUNT(*)
----------
665
Elapsed: 00:00:00.02
SQL> select count(*) from PRODUCT_INFORMATION;
COUNT(*)
----------
288
Elapsed: 00:00:00.01
SQL>
2.设定环境参数statistics_level为ALL，以便可以经过dbms_xplan.display_cursor函数查看SQL文根据统计信息估算出的访问数据行数和SQL执行时的实际值。
SQL> alter session set statistics_level=all; Session altered. Elapsed: 00:00:00.01
3.第一次执行SQL
SQL>
SQL> SELECT o.order_id, v.product_name
2 FROM orders o,
3 ( SELECT order_id, product_name
4 FROM order_items o, product_information p
5 WHERE p.product_id = o.product_id
6 AND list_price < 50
7 AND min_price < 40 ) v
8 WHERE o.order_id = v.order_id
9 ;
ORDER_ID PRODUCT_NAME
---------- --------------------
2403 Battery - EL
...
2450 Plastic Stock - W/HD
269 rows selected.
Elapsed: 00:00:00.22
SQL>
4.查看第一次执行后的执行计划
SQL> select * from table(dbms_xplan.display_cursor(format=>'typical iostats last -cost -bytes'));
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------
SQL_ID bmh5hb8331u33, child number 0
-------------------------------------
SELECT o.order_id, v.product_name FROM orders o, ( SELECT
order_id, product_name FROM order_items o,
product_information p WHERE p.product_id = o.product_id
AND list_price < 50 AND min_price < 40 ) v WHERE
o.order_id = v.order_id
Plan hash value: 1906736282
---------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | E-Time | A-Rows | A-Time | Buffers | Reads |
---------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | | 269 |00:00:00.17 | 1337 | 20 |
| 1 | NESTED LOOPS | | 1 | 1 | 00:00:01 | 269 |00:00:00.17 | 1337 | 20 |
| 2 | MERGE JOIN CARTESIAN| | 1 | 4 | 00:00:01 | 9135 |00:00:00.06 | 33 | 15 |
|* 3 | TABLE ACCESS FULL | PRODUCT_INFORMATION | 1 | ★ 1 | 00:00:01 | ★ 87 |00:00:00.01 | 32 | 14 |
| 4 | BUFFER SORT | | 87 | 105 | 00:00:01 | 9135 |00:00:00.02 | 1 | 1 |
| 5 | INDEX FULL SCAN | ORDER_PK | 1 | 105 | 00:00:01 | 105 |00:00:00.01 | 1 | 1 |
|* 6 | INDEX UNIQUE SCAN | ORDER_ITEMS_UK | 9135 | 1 | | 269 |00:00:00.05 | 1304 | 5 |
---------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter(("MIN_PRICE"<40 AND "LIST_PRICE"<50))
6 - access("O"."ORDER_ID"="ORDER_ID" AND "P"."PRODUCT_ID"="O"."PRODUCT_ID")
28 rows selected.
Elapsed: 00:00:00.19
咱们发现和10.2.0.5环境同样，因为访问条件(“MIN_PRICE”<40 AND “LIST_PRICE”<50)的影响，优化器认为PRODUCT_INFORMATION表的预估行数（E-Rows）为1，优化器基于预估基数在选择表PRODUCT_INFORMATION和ORDER_ITEMS结合的最优执行计划时，选择了MERGE JOIN CARTESIAN的结合方式。
5.查看动态视图VSQL和VSQL_SHARED_CURSOR
SQL> ---sql_id:bmh5hb8331u33 SQL> select sql_id,child_number, executions, buffer_gets,plan_hash_value 2 from v$sql 3 where sql_id = 'bmh5hb8331u33'; SQL_ID CHILD_NUMBER EXECUTIONS BUFFER_GETS PLAN_HASH_VALUE ------------- ------------ ---------- ----------- --------------- bmh5hb8331u33 0 1 1604 1906736282 Elapsed: 00:00:00.01 SQL> SQL> select sql_id, child_number, USE_FEEDBACK_STATS 2 from V$SQL_SHARED_CURSOR 3 where sql_id = 'bmh5hb8331u33'; SQL_ID CHILD_NUMBER U ------------- ------------ - bmh5hb8331u33 0 Y Elapsed: 00:00:00.04 SQL>
咱们发现V$SQL_SHARED_CURSOR的USE_FEEDBACK_STATS列标记为Y。
（USE_FEEDBACK_STATS列是在11.2.0.4 的版本上新追加的列，用于标示当根据统计信息估算出的基数(Computed cardinality)和SQL执行时的实际值差距很大时，下次执行时从新生成执行计划）
6.咱们再次次执行相同的SQL文
---第二次执行
SQL> SELECT o.order_id, v.product_name
2 FROM orders o,
3 ( SELECT order_id, product_name
4 FROM order_items o, product_information p
5 WHERE p.product_id = o.product_id
6 AND list_price < 50
7 AND min_price < 40 ) v
8 WHERE o.order_id = v.order_id
9 ;
ORDER_ID PRODUCT_NAME
---------- --------------------
2403 Battery - EL
...
2401 SPNIX3.3 AU
269 rows selected.
Elapsed: 00:00:00.03★
SQL>
咱们发现执行时间变短了。
7.再次查看执行计划
SQL> select * from table(dbms_xplan.display_cursor(format=>'typical iostats last -cost -bytes'));
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------
SQL_ID bmh5hb8331u33, child number 1
-------------------------------------
SELECT o.order_id, v.product_name FROM orders o, ( SELECT
order_id, product_name FROM order_items o,
product_information p WHERE p.product_id = o.product_id
AND list_price < 50 AND min_price < 40 ) v WHERE
o.order_id = v.order_id
Plan hash value: 35479787
----------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | E-Time | A-Rows | A-Time | Buffers | Reads |
----------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | | 269 |00:00:00.01 | 61 | 1 |
| 1 | NESTED LOOPS | | 1 | 313 | 00:00:01 | 269 |00:00:00.01 | 61 | 1 |
|* 2 | HASH JOIN | | 1 | 313 | 00:00:01 | 269 |00:00:00.01 | 40 | 1 |
|* 3 | TABLE ACCESS FULL | PRODUCT_INFORMATION | 1 | ★87 | 00:00:01 | ★87 |00:00:00.01 | 15 | 0 |
| 4 | INDEX FAST FULL SCAN| ORDER_ITEMS_UK | 1 | 665 | 00:00:01 | 665 |00:00:00.01 | 25 | 1 |
|* 5 | INDEX UNIQUE SCAN | ORDER_PK | 269 | 1 | | 269 |00:00:00.01 | 21 | 0 |
----------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("P"."PRODUCT_ID"="O"."PRODUCT_ID")
3 - filter(("MIN_PRICE"<40 AND "LIST_PRICE"<50))
5 - access("O"."ORDER_ID"="ORDER_ID")
Note
-----
- cardinality feedback used for this statement ★
32 rows selected.
Elapsed: 00:00:00.03
咱们发现SQL文进行了硬解析，而且表PRODUCT_INFORMATION的预估信息（E-Rows）调整为第一次执行时收集的实际值（87），用于优化器选择执行计划。所以，优化器基于调整后预估基数在选择表PRODUCT_INFORMATION和ORDER_ITEMS结合的最优执行计划时，选择了HASH JOIN的结合方式，从而更有效的执行了SQL文。
8.再次查看动态视图VSQL和VSQL_SHARED_CURSOR
SQL> ---sql_id:bmh5hb8331u33 SQL> select sql_id,child_number, executions, buffer_gets,plan_hash_value,is_shareable 2 from v$sql 3 where sql_id = 'bmh5hb8331u33'; SQL_ID CHILD_NUMBER EXECUTIONS BUFFER_GETS PLAN_HASH_VALUE I ------------- ------------ ---------- ----------- --------------- - bmh5hb8331u33 0 1 1604 1906736282 N★ bmh5hb8331u33 1 1 61 35479787 Y★ Elapsed: 00:00:00.02 SQL> SQL> select sql_id, child_number, USE_FEEDBACK_STATS 2 from V$SQL_SHARED_CURSOR 3 where sql_id = 'bmh5hb8331u33'; SQL_ID CHILD_NUMBER U ------------- ------------ - bmh5hb8331u33 0 Y bmh5hb8331u33 1 N Elapsed: 00:00:00.00
经过视图V$SQL咱们发现，新生成的游标CHILD#1比之前的游标CHILD#1会使用更少的BUFFER_GETS，效率更高。而且之前游标CHILD#0的is_shareable列标记为N，不在被共享。
新生成的游标CHILD#1的is_shareable列标记为Y，供之后的执行重用。
9.再屡次执行SQL文
--第三次执行
SQL> SELECT o.order_id, v.product_name
2 FROM orders o,
3 ( SELECT order_id, product_name
4 FROM order_items o, product_information p
5 WHERE p.product_id = o.product_id
6 AND list_price < 50
7 AND min_price < 40 ) v
8 WHERE o.order_id = v.order_id
9 ;
ORDER_ID PRODUCT_NAME
---------- --------------------
2403 Battery - EL
...
2401 SPNIX3.3 AU
269 rows selected.
Elapsed: 00:00:00.06
SQL>
--查看执行计划
SQL> set line 200
SQL> set pagesize 9999
SQL>
SQL> select * from table(dbms_xplan.display_cursor(format=>'typical iostats last -cost -bytes'));
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------
SQL_ID bmh5hb8331u33, child number 1
-------------------------------------
SELECT o.order_id, v.product_name FROM orders o, ( SELECT
order_id, product_name FROM order_items o,
product_information p WHERE p.product_id = o.product_id
AND list_price < 50 AND min_price < 40 ) v WHERE
o.order_id = v.order_id
Plan hash value: 35479787
-------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | E-Time | A-Rows | A-Time | Buffers |
-------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | | 269 |00:00:00.03 | 61 |
| 1 | NESTED LOOPS | | 1 | 313 | 00:00:01 | 269 |00:00:00.03 | 61 |
|* 2 | HASH JOIN | | 1 | 313 | 00:00:01 | 269 |00:00:00.02 | 40 |
|* 3 | TABLE ACCESS FULL | PRODUCT_INFORMATION | 1 | 87 | 00:00:01 | 87 |00:00:00.01 | 15 |
| 4 | INDEX FAST FULL SCAN| ORDER_ITEMS_UK | 1 | 665 | 00:00:01 | 665 |00:00:00.01 | 25 |
|* 5 | INDEX UNIQUE SCAN | ORDER_PK | 269 | 1 | | 269 |00:00:00.01 | 21 |
-------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("P"."PRODUCT_ID"="O"."PRODUCT_ID")
3 - filter(("MIN_PRICE"<40 AND "LIST_PRICE"<50))
5 - access("O"."ORDER_ID"="ORDER_ID")
Note
-----
- cardinality feedback used for this statement
32 rows selected.
Elapsed: 00:00:00.07
--查看动态视图
SQL> ---sql_id:bmh5hb8331u33
SQL> select sql_id,child_number, executions, buffer_gets,plan_hash_value,is_shareable
2 from v$sql
3 where sql_id = 'bmh5hb8331u33';
SQL_ID CHILD_NUMBER EXECUTIONS BUFFER_GETS PLAN_HASH_VALUE I
------------- ------------ ---------- ----------- --------------- -
bmh5hb8331u33 0 1 1604 1906736282 N
bmh5hb8331u33 1 2 122 35479787 Y
Elapsed: 00:00:00.00
SQL>
SQL> select sql_id, child_number, USE_FEEDBACK_STATS
2 from V$SQL_SHARED_CURSOR
3 where sql_id = 'bmh5hb8331u33';
SQL_ID CHILD_NUMBER U
------------- ------------ -
bmh5hb8331u33 0 Y
bmh5hb8331u33 1 N
Elapsed: 00:00:00.00
--第四次执行
SQL> SELECT o.order_id, v.product_name
2 FROM orders o,
3 ( SELECT order_id, product_name
4 FROM order_items o, product_information p
5 WHERE p.product_id = o.product_id
6 AND list_price < 50
7 AND min_price < 40 ) v
8 WHERE o.order_id = v.order_id
9 ;
ORDER_ID PRODUCT_NAME
---------- --------------------
2403 Battery - EL
...
2401 SPNIX3.3 AU
269 rows selected.
Elapsed: 00:00:00.05
SQL>
--查看执行计划
SQL> set line 200
SQL> set pagesize 9999
SQL>
SQL> select * from table(dbms_xplan.display_cursor(format=>'typical iostats last -cost -bytes'));
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------
SQL_ID bmh5hb8331u33, child number 1
-------------------------------------
SELECT o.order_id, v.product_name FROM orders o, ( SELECT
order_id, product_name FROM order_items o,
product_information p WHERE p.product_id = o.product_id
AND list_price < 50 AND min_price < 40 ) v WHERE
o.order_id = v.order_id
Plan hash value: 35479787
-------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | E-Time | A-Rows | A-Time | Buffers |
-------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | | 269 |00:00:00.02 | 61 |
| 1 | NESTED LOOPS | | 1 | 313 | 00:00:01 | 269 |00:00:00.02 | 61 |
|* 2 | HASH JOIN | | 1 | 313 | 00:00:01 | 269 |00:00:00.01 | 40 |
|* 3 | TABLE ACCESS FULL | PRODUCT_INFORMATION | 1 | 87 | 00:00:01 | 87 |00:00:00.01 | 15 |
| 4 | INDEX FAST FULL SCAN| ORDER_ITEMS_UK | 1 | 665 | 00:00:01 | 665 |00:00:00.01 | 25 |
|* 5 | INDEX UNIQUE SCAN | ORDER_PK | 269 | 1 | | 269 |00:00:00.01 | 21 |
-------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("P"."PRODUCT_ID"="O"."PRODUCT_ID")
3 - filter(("MIN_PRICE"<40 AND "LIST_PRICE"<50))
5 - access("O"."ORDER_ID"="ORDER_ID")
Note
-----
- cardinality feedback used for this statement
32 rows selected.
Elapsed: 00:00:00.02
SQL>
--查看动态视图
SQL>
SQL> ---sql_id:bmh5hb8331u33
SQL> select sql_id,child_number, executions, buffer_gets,plan_hash_value,is_shareable
2 from v$sql
3 where sql_id = 'bmh5hb8331u33';
SQL_ID CHILD_NUMBER EXECUTIONS BUFFER_GETS PLAN_HASH_VALUE I
------------- ------------ ---------- ----------- --------------- -
bmh5hb8331u33 0 1 1604 1906736282 N
bmh5hb8331u33 1 3 183 35479787 Y
Elapsed: 00:00:00.00
SQL>
SQL> select sql_id, child_number, USE_FEEDBACK_STATS
2 from V$SQL_SHARED_CURSOR
3 where sql_id = 'bmh5hb8331u33';
SQL_ID CHILD_NUMBER U
------------- ------------ -
bmh5hb8331u33 0 Y
bmh5hb8331u33 1 N
Elapsed: 00:00:00.00
咱们发现之后的执行都会变成软解析，使用第二次产生的执行计划。
经过CFB功能使优化器可以在之后的执行中选择更优的执行计划，从获得更好的执行效率。
CFB的处理流程
下面经过如下流程图来整体的回顾一下CFB的处理过程。
在下列状况CBO可能没法估算出准确的Cardinality，Oracle会启用CFB功能：
| 1 2 3 |
|
针对上述状况，Oracle会采起以下的CFB流程处理：
| 1 2 3 4 |
|
相关文章
- 1. 【Oracle 优化器】基数反馈 （Cardinality Feedback）功能
- 2. SQL优化之关闭反馈信息
- 3. Oracle优化及常用函数功能
- 4. 基数反馈（Cardinality Feedback）
- 5. 测试答题及时反馈功能
- 6. 编程感悟之反馈，反馈，反馈
- 7. MySQL优化器功能开关optimizer_switch之功能概览
- 8. oracle优化器
- 9. oracle 性能优化
- 10. oracle性能优化
- 更多相关文章...
- • SEO - 搜索引擎优化 - 网站建设指南
- • MySQL 5.7的新特性（新功能） - MySQL教程
- • Flink 数据传输及反压详解
- • 算法总结-广度优先算法
相关标签/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
欢迎关注本站公众号,获取更多信息
