CBO对于Oracle SQL执行计划的影响(之二)
初试化参数对于执行计划的影响
有几个初试化参数对于多表链接的执行计划有重要的关系。数据库
在Oracle 8 release 8.0.5中引入了两个参数OPTIMIZER_MAX_PERMUTATIONS 和 OPTIMIZER_SEARCH_LIMITsession
optimizer_search_limit参数指定了在决定链接多个数据表的最好方式时，CBO须要衡量的数据表链接组合的最大数目。
该参数的缺省值是5。
若是链接表的数目小于optimizer_search_limit参数，那么Oracle会执行全部可能的链接。可能链接的组合数目是数据表数目的阶乘。oracle
咱们刚才有7张表，那么有7!（5040）种组合。优化
optimizer_max_permutations参数定义了CBO所考虑的表链接的最大数目的上限。
当咱们给这个参数设置很小的一个值的时候，Oracle的计算比较很快就能够被遏制。而后执行计划，给出结果。code
optimizer_search_limit参数和optimizer_max_permutations参数和Ordered参数不相容，若是定义了ordered提示，那么
optimizer_max_permutations参数将会失效。
实际上，当你定义了ordered提示时，oracle已经无需计算了。ip
optimizer_search_limit参数和optimizer_max_permutations参数要结合使用，优化器将在optimizer_search_limit参数或
optimizer_max_permutations参数值超出以前，生成可能的表链接转换。当优化器中止对表链接的评估时，它将选择成本最低的组合。get
例如，须要链接9个表的查询已经超出了optimizer_search_limit参数的限制，可是仍然可能要花费大量的时间去试图评估全部362880个
可能的链接顺序(9!),直到超过了optimizer_max_permutations参数的默认值(80000个表链接顺序)。it
optimizer_max_permutations参数为CBO须要评估的排列数量的最大值。
optimizer_max_permutations的默认值是80000。
在肯定查询排列评估数量的上限时，CBO采用的原则是：
若是查询中存在的非单一记录表的数目小于optimizer_search_limit+1,那么排列的最大值等于下面两个表达式中较大的数值：
optimizer_max_permutations
______________________________
(可能启动表的数目+1)io
和cli
optimizer_search_limit!
___________________________
(可能启动表的数目+1)
例如5个表链接
排列的最大值= 80000/6=13333
____________________________
搜索限制=5!/6=120/6=20
较大值是13333，这就是优化器要考虑的排列的最大数值(固然实际的数值要比这个小的多,Oracle会排除掉大部分不可能组合)。
SQL> alter session set optimizer_search_limit = 3;
会话已更改。
已用时间: 00: 00: 00.60
SQL> alter session set optimizer_max_permutations = 100;
会话已更改。
已用时间: 00: 00: 00.90
SQL> set autotrace traceonly
SQL> SELECT "SP_TRANS"."TRANS_NO",
2 "SP_TRANS"."TRANS_TYPE",
3 "SP_TRANS"."STORE_NO",
4 "SP_TRANS"."BILL_NO",
5 "SP_TRANS"."TRANSDATE",
6 "SP_TRANS"."MANAGER_ID",
7 "SP_TRANS"."REMARK",
8 "SP_TRANS"."STATE",
9 "SP_TRANS_SUB"."TRANS_NO",
10 "SP_TRANS_SUB"."ITEM_CODE",
11 "SP_TRANS_SUB"."COUNTRY",
12 "SP_TRANS_SUB"."QTY",
13 "SP_TRANS_SUB"."PRICE",
14 "SP_TRANS_SUB"."TOTAL",
15 "SP_CHK"."CHK_NO",
16 "SP_CHK"."RECEIVE_NO",
17 "SP_CHK"."CHECKER",
18 "SP_CHK_SUB"."CHK_NO",
19 "SP_CHK_SUB"."ITEM_CODE",
20 "SP_CHK_SUB"."COUNTRY",
21 "SP_CHK_SUB"."PLAN_NO",
22 "SP_CHK_SUB"."PLAN_LINE",
23 "SP_CHK_SUB"."QTY_CHECKOUT",
24 "SP_CHK_SUB"."NOW_QTY",
25 "SP_RECEIVE"."RECEIVE_NO",
26 "SP_RECEIVE"."VENDOR_NAME",
27 "SP_RECEIVE"."BUYER",
28 "SP_RECEIVE_SUB"."RECEIVE_NO",
29 "SP_RECEIVE_SUB"."PLAN_NO",
30 "SP_RECEIVE_SUB"."PLAN_LINE",
31 "SP_RECEIVE_SUB"."ITEM_NAME",
32 "SP_RECEIVE_SUB"."COUNTRY",
33 "SP_ITEM"."ITEM_CODE",
34 "SP_ITEM"."CHART_ID",
35 "SP_ITEM"."SPECIFICATION"
36 FROM "SP_TRANS" ,
37 "SP_CHK" ,
38 "SP_RECEIVE" ,
39 "SP_TRANS_SUB" ,
40 "SP_CHK_SUB" ,
41 "SP_RECEIVE_SUB" ,
42 "SP_ITEM"
43 WHERE
44 ( "SP_TRANS_SUB"."TRANS_NO" = "SP_TRANS"."TRANS_NO" ) and
45 ("SP_TRANS"."BILL_NO" = "SP_CHK"."CHK_NO") and
46 ( "SP_CHK_SUB"."CHK_NO" = "SP_CHK"."CHK_NO" ) and
47 ( "SP_CHK"."RECEIVE_NO" = "SP_RECEIVE"."RECEIVE_NO" ) and
48 ( "SP_CHK"."STATE" = 15 ) and
49 ( "SP_RECEIVE_SUB"."RECEIVE_NO" = "SP_RECEIVE"."RECEIVE_NO" ) and
50 ( "SP_TRANS_SUB"."ITEM_CODE" = "SP_ITEM"."ITEM_CODE" ) and
51 ( "SP_TRANS_SUB"."ITEM_CODE" = "SP_CHK_SUB"."ITEM_CODE" ) and
52 ( "SP_CHK_SUB"."ITEM_CODE" = "SP_RECEIVE_SUB"."ITEM_CODE" ) and
53 ( "SP_CHK_SUB"."COUNTRY" = "SP_TRANS_SUB"."COUNTRY" ) and
54 ( "SP_CHK_SUB"."COUNTRY" = "SP_RECEIVE_SUB"."COUNTRY" ) and
55 ( "SP_CHK_SUB"."PLAN_NO" = "SP_RECEIVE_SUB"."PLAN_NO" ) and
56 ( "SP_CHK_SUB"."PLAN_LINE" = "SP_RECEIVE_SUB"."PLAN_LINE" ) and
57 (to_char("SP_TRANS"."TRANSDATE" ,'YYYY-MM-DD') >='2003-01-01')
58 /
已选择130行。
已用时间: 00: 00: 05.78
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2177 Card=1 Bytes=288)
1 0 NESTED LOOPS (Cost=2177 Card=1 Bytes=288)
2 1 NESTED LOOPS (Cost=2176 Card=1 Bytes=256)
3 2 NESTED LOOPS (Cost=2174 Card=1 Bytes=219)
4 3 MERGE JOIN (Cost=2173 Card=1 Bytes=178)
5 4 SORT (JOIN) (Cost=1115 Card=8081 Bytes=1018206)
6 5 HASH JOIN (Cost=645 Card=8081 Bytes=1018206)
7 6 HASH JOIN (Cost=96 Card=1717 Bytes=133926)
8 7 TABLE ACCESS (FULL) OF 'SP_TRANS' (Cost=44 Card=1717 Bytes=80699)
9 7 TABLE ACCESS (FULL) OF 'SP_CHK' (Cost=13 Card=3870 Bytes=119970)
10 6 TABLE ACCESS (FULL) OF 'SP_CHK_SUB' (Cost=59 Card=36412 Bytes=1747776)
11 4 SORT (JOIN) (Cost=1058 Card=36730 Bytes=1909960)
12 11 TABLE ACCESS (FULL) OF 'SP_RECEIVE_SUB' (Cost=89 Card=36730 Bytes=1909960)
13 3 TABLE ACCESS (BY INDEX ROWID) OF 'SP_RECEIVE' (Cost=1 Card=7816 Bytes=320456)
14 13 INDEX (UNIQUE SCAN) OF 'PK_SP_RECEIVE' (UNIQUE)
15 2 TABLE ACCESS (BY INDEX ROWID) OF 'SP_TRANS_SUB' (Cost=2 Card=136371 Bytes=5045727)
16 15 INDEX (UNIQUE SCAN) OF 'PK_SP_TRANS_SUB' (UNIQUE) (Cost=1 Card=136371)
17 1 TABLE ACCESS (BY INDEX ROWID) OF 'SP_ITEM' (Cost=1 Card=29763 Bytes=952416)
18 17 INDEX (UNIQUE SCAN) OF 'SYS_C0012193' (UNIQUE)
Statistics
----------------------------------------------------------
8 recursive calls
131 db block gets
3436 consistent gets
1397 physical reads
0 redo size
38555 bytes sent via SQL*Net to client
1085 bytes received via SQL*Net from client
10 SQL*Net roundtrips to/from client
8 sorts (memory)
1 sorts (disk)
130 rows processed
SQL>
3. 其余
在有的系统视图查询中，不少时候会出现问题，好比如下的SQL：
select a.username, a.sid, a.serial#, b.id1 from v$session a, v$lock b where a.lockwait = b.kaddr /
这个语句用来查找锁，在Oracle7的年代，这样的SQL语句执行的很快，可是在Oracle8之后的数据库，若是碰巧你用的是CBO，那么
这样的语句执行结果多是Hang了（其实不是死了，只是不少人没有耐心等而已），在Oracle7里，这样的语句毫无疑问使用RBO，
很快你就能够获得执行结果。能够对于CBO，你所看到的两个视图，对于数据库来讲，其实是6个表，单只6个表的可能顺序组合就有
6!（720）种，数据库时间都消耗在计算这些执行路径上了，因此你获得的就是hang的结果。
最简单的解决办法就是使用rule提示，或者使用ordered提示
咱们能够看一下这两种方式的执行计划，若是你有兴趣的话，还能够研究一下X$视图：
SQL> select /*+ rule */ a.username, a.sid, a.serial#, b.id1
2 from v$session a, v$lock b
3 where a.lockwait = b.kaddr
4 /
未选定行
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=HINT: RULE
1 0 MERGE JOIN
2 1 SORT (JOIN)
3 2 MERGE JOIN
4 3 SORT (JOIN)
5 4 MERGE JOIN
6 5 FIXED TABLE (FULL) OF 'X$KSQRS'
7 5 SORT (JOIN)
8 7 VIEW OF 'GV$_LOCK'
9 8 UNION-ALL
10 9 VIEW OF 'GV$_LOCK1'
11 10 UNION-ALL
12 11 FIXED TABLE (FULL) OF 'X$KDNSSF'
13 11 FIXED TABLE (FULL) OF 'X$KSQEQ'
14 9 FIXED TABLE (FULL) OF 'X$KTADM'
15 9 FIXED TABLE (FULL) OF 'X$KTCXB'
16 3 SORT (JOIN)
17 16 FIXED TABLE (FULL) OF 'X$KSUSE'
18 1 SORT (JOIN)
19 18 FIXED TABLE (FULL) OF 'X$KSUSE'
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
196 bytes sent via SQL*Net to client
246 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
0 rows processed
对于Ordered提示：
SQL> select /*+ ordered */ a.username, a.sid, a.serial#, b.id1
2 from v$session a, v$lock b
3 where a.lockwait = b.kaddr
4 /
未选定行
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=112 Card=1 Bytes=145 )
1 0 NESTED LOOPS (Cost=112 Card=1 Bytes=145)
2 1 NESTED LOOPS (Cost=96 Card=1 Bytes=128)
3 2 NESTED LOOPS (Cost=80 Card=1 Bytes=111)
4 3 FIXED TABLE (FULL) OF 'X$KSUSE' (Cost=16 Card=1 Bytes=86)
5 3 VIEW OF 'GV$_LOCK'
6 5 UNION-ALL
7 6 VIEW OF 'GV$_LOCK1' (Cost=32 Card=2 Bytes=162)
8 7 UNION-ALL
9 8 FIXED TABLE (FULL) OF 'X$KDNSSF' (Cost=16 Card=1 Bytes=94)
10 8 FIXED TABLE (FULL) OF 'X$KSQEQ' (Cost=16 Card=1 Bytes=94)
11 6 FIXED TABLE (FULL) OF 'X$KTADM' (Cost=16 Card=1 Bytes=94)
12 6 FIXED TABLE (FULL) OF 'X$KTCXB' (Cost=16 Card=1 Bytes=94)
13 2 FIXED TABLE (FULL) OF 'X$KSUSE' (Cost=16 Card=1 Bytes=17)
14 1 FIXED TABLE (FIXED INDEX #1) OF 'X$KSQRS' (Cost=16 Card=100 Bytes=1700)
Statistics
----------------------------------------------------------
0 recursive calls
67 db block gets
0 consistent gets
0 physical reads
0 redo size
202 bytes sent via SQL*Net to client
244 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
17 sorts (memory)
0 sorts (disk)
0 rows processed
SQL>
相似的
SELECT /*+ RULE */
s.SID, s.serial#, l.TYPE, l.id1, l.id2, l.lmode, l.request, l.addr,
l.kaddr, l.ctime, l.BLOCK, s.username, s.osuser, s.machine,
DECODE (l.id2,
0, TO_CHAR (o.owner#) || '-' || o.NAME,
'Trans-' || TO_CHAR (l.id1) || '-' || l.id2
) object_name,
DECODE (l.lmode,
0, '--Waiting--',
1, 'Null',
2, 'Row Share',
3, 'Row Excl',
4, 'Share',
5, 'Sha Row Exc',
6, 'Exclusive',
'Other'
) lock_mode,
DECODE (l.request,
0, ' ',
1, 'Null',
2, 'Row Share',
3, 'Row Excl',
4, 'Share',
5, 'Sha Row Exc',
6, 'Exclusive',
'Other'
) req_mode
FROM v$lock l, v$session s, SYS.obj$ o
WHERE l.request = 0
AND l.SID = s.SID
AND l.id1 = o.obj#(+)
AND s.username IS NOT NULL
ORDER BY s.username, l.SID, l.BLOCK;
以上问题对于CBO优化器广泛存在，对于Oracle9i2一样如此。
幸运的是在Oracle9i中，optimizer_max_permutations初始值下降到2000，从80000到2000，这是一个重大的进步
其实或者这不能算是问题，对于Oracle这只是一种知识，一种方法而已。
相关文章
- 1. CBO对于Oracle SQL执行计划的影响(之一)
- 2. SQL执行计划之sql_trace
- 3. 执行计划--WHERE条件的先后顺序对执行计划的影响
- 4. Hive——SQL的执行计划（8）
- 5. Oracle sql优化（三）SQL执行计划
- 6. 执行计划
- 7. SQL之执行计划
- 8. Oracle之一条SQL对应多个执行计划
- 9. SQL执行计划
- 10. 执行计划sql
- 更多相关文章...
- • MyBatis SqlSession和Mapper接口执行Sql - MyBatis教程
- • Hibernate的二级缓存 - Hibernate教程
- • ☆基于Java Instrument的Agent实现
- • 互联网组织的未来：剖析GitHub员工的任性之源
相关标签/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
- 1. 安装cuda+cuDNN
- 2. GitHub的使用说明
- 3. phpDocumentor使用教程【安装PHPDocumentor】
- 4. yarn run build报错Component is not found in path “npm/taro-ui/dist/weapp/components/rate/index“
- 5. 精讲Haproxy搭建Web集群
- 6. 安全测试基础之MySQL
- 7. C/C++编程笔记：C语言中的复杂声明分析，用实例带你完全读懂
- 8. Python3教程(1)----搭建Python环境
- 9. 李宏毅机器学习课程笔记2：Classification、Logistic Regression、Brief Introduction of Deep Learning
- 10. 阿里云ECS配置速记
欢迎关注本站公众号,获取更多信息
相关文章
- 1. CBO对于Oracle SQL执行计划的影响(之一)
- 2. SQL执行计划之sql_trace
- 3. 执行计划--WHERE条件的先后顺序对执行计划的影响
- 4. Hive——SQL的执行计划（8）
- 5. Oracle sql优化（三）SQL执行计划
- 6. 执行计划
- 7. SQL之执行计划
- 8. Oracle之一条SQL对应多个执行计划
- 9. SQL执行计划
- 10. 执行计划sql