Oracle 10053详解(原创)

10053事件概述
查询优化器Query Optimizer是Oracle数据库的一个核心技术，作用是将输入SQL转化为最优的执行计划。由于SQL语句本身是一种描述特性的语言，Query Optimizer生成最优的执行计划，就是各品种、各版本DBMS的追求目标。
10g以后Oracle就完全废除了RB0，使用CBO（Cost-Based Optimizer）称为基于成本的优化器作为默认优化器。CBO的工作完全依赖于对数据库对象的统计量，如数据表、索引等对象的统计信息。此外，还有一些内部的系统参数和内部计算公式。CBO将系统I/O和CPU转化为统一的成本度量，比较多条可能的执行路径成本差额，最后将成本cost最少的一个作为实际生成的执行计划。
借助Oracle的10053事件event，我们可以监控到CBO对SQL进行成本计算和路径选择的过程和方法。
10053事件有两个级别：
Level 2：2级是1级的一个子集，它包含以下内容：
Column statistics
Single Access Paths
Join Costs
Table Joins Considered
Join Methods Considered (NL/MS/HA)
Level 1： 1级比2级更详细，它包含2级的所有内容，在加如下内容：
Parameters used by the optimizer
Index statistics
启用10053事件
ALTER SESSION SET EVENTS='10053 trace name context forever, level 1';
ALTER SESSION SET EVENTS='10053 trace name context forever, level 2';
关闭10053事件：
ALTER SESSION SET EVENTS '10053 trace name context off';
说明：
1、sqlplus中打开autotrace看到的执行计划实际上是用explain plan 命令得到的，explain plan 命令不会进行bind peeking。应该通过v$sql_plan查看SQL的真实的执行计划。
2、10053只对CBO有效，而且如果一个sql语句已经解析过，就不会产生新的trace信息。
3、10053事件产生的trace文件不能用tkprof格式化。
查看10053事件的trace文件

实验步骤：
SQL> create table t as select rownum x from dba_objects;
Table created.
SQL> create index t_idx on t(x);
Index created.
SQL> exec dbms_stats.gather_table_stats('HR','T',cascade=>true);
PL/SQL procedure successfully completed.
SQL> create table t1 as select object_id id ,object_Name from dba_objects;
Table created.
SQL> create index t1_idx on t1(id);
Index created.
SQL> exec dbms_stats.gather_table_stats('HR','T1',cascade=>true);
PL/SQL procedure successfully completed.
SQL> alter session set events '10053 trace name context forever,level 1';
Session altered.
SQL> explain plan for select t1.* from t1,t where t.x<:c and t.x=t1.id;
Explained.
SQL> alter session set events '10053 trace name context off';
Session altered.

trace文件如下,篇幅原因有省略
/u01/app/admin/orcl/udump/orcl_ora_2590.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /u01/app/oracle
System name: Linux
Node name: rac1
Release: 2.6.18-164.el5
Version: #1 SMP Tue Aug 18 15:51:54 EDT 2009
Machine: i686
Instance name: orcl
Redo thread mounted by this instance: 1
Oracle process number: 33
Unix process pid: 2590, image: oracle@rac1 (TNS V1-V3)
trace文件通用，包含了操作系统、数据库和会话的信息，这里不再累述。
*** 2012-04-25 10:53:00.982
*** ACTION NAME:() 2012-04-25 10:53:00.981
*** MODULE NAME:(SQL*Plus) 2012-04-25 10:53:00.981
*** SERVICE NAME:(SYS$USERS) 2012-04-25 10:53:00.981
*** SESSION ID:(159.5) 2012-04-25 10:53:00.981
Registered qb: SEL$1 0x2db12034 (PARSER)
signature (): qb_name=SEL$1 nbfros=2 flg=0
fro(0): flg=4 objn=53393 hint_alias="T"@"SEL$1"
fro(1): flg=4 objn=53395 hint_alias="T1"@"SEL$1"
下面是10053 trace信息

 ***************************************
  PARAMETERS IN OPT_PARAM HINT
 ****************************
 ***************************************
 Column Usage Monitoring is ON: tracking level = 1   标识10053事件用的时level1级别
 ***************************************

 

**************************
Predicate Move-Around (PM)
**************************
PM: Considering predicate move-around in SEL$1 (#0).
PM: Checking validity of predicate move-around in SEL$1 (#0).
PM: PM bypassed: Outer query contains no views.
FPD: Considering simple filter push in SEL$1 (#0)
FPD: Current where clause predicates in SEL$1 (#0) :
"T"."X"<:B1 AND "T"."X"="T1"."ID"            #最初的谓词条件
kkogcp: try to generate transitive predicate from check constraints for SEL$1 (#0)
predicates with check contraints: "T"."X"<:B1 AND "T"."X"="T1"."ID" AND "T1"."ID"<:B2
after transitive predicate generation: "T"."X"<:B1 AND "T"."X"="T1"."ID" AND "T1"."ID"<:B2
finally: "T"."X"<:B1 AND "T"."X"="T1"."ID" AND "T1"."ID"<:B2            #最终的谓词条件 
可以看出，从逻辑上这两个谓词条件是等价的，CBO只所以进行改写，是为了方便计算每一步的成本和估算Cardinality
FPD: Following transitive predicates are generated in SEL$1 (#0) :
"T1"."ID"<:B1
apadrv-start: call(in-use=340, alloc=16360), compile(in-use=34068, alloc=37692)
kkoqbc-start
: call(in-use=344, alloc=16360), compile(in-use=34824, alloc=37692)
******************************************
Current SQL statement for this session:
select t1.* from t1,t where t.x<:c and t.x=t1.id
*******************************************
Legend
The following abbreviations are used by optimizer trace.
CBQT - cost-based query transformation
JPPD - join predicate push-down
FPD - filter push-down
PM - predicate move-around
CVM - complex view merging
。。。。。省略若干行。。。。。。
 128: use hash partitioning dimension
256: use range partitioning dimension
2048: use list partitioning dimension
1024: run the join in serial
0: invalid distribution method
sel - selectivity
ptn - partition

****************
 QUERY BLOCK TEXT
 ****************
 select t1.* from t1,t where t.x<:c and t.x=t1.id
 ---------------------
 QUERY BLOCK SIGNATURE
 ---------------------
 signature (optimizer): qb_name=SEL$1 nbfros=2 flg=0
 fro(0): flg=0 objn=74723 hint_alias="T"@"SEL$1"
 fro(1): flg=0 objn=74725 hint_alias="T1"@"SEL$1"
 
 -----------------------------
 SYSTEM STATISTICS INFORMATION
 -----------------------------

 ***************************************
Peeked values of the binds in SQL statement
kkscoacd
Bind#0
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000000 frm=00 csi=00 siz=24 off=0
kxsbbbfp=b7b1efb8 bln=22 avl=00 flg=05
BIND ：Variables bound to a cursor，游标号
bind N ：The bind position being bound，绑定游标的位置，从0开始，0是第一个游标
dty ：Data type，数据类型
mxl ：Maximum length of the bind variable (private max len in paren)，绑定变量的最大长度
mal ：Array length，最大数组长度(当用到绑定变量数组或批量操作时)
scl ：Scale，比例
pre ：Precision，精度
oacflg ：Special flag indicating bind options，内部标记，若是奇数，则绑定变量为空值，允许有空值。
oacflg2 ：Continuation of oacflg，内部标记的扩展
size ：Amount of memory to be allocated for this chunk，缓冲区的大小
offset ：Offset into this chunk for this bind buffer，缓冲区的chunk大小
bfp ：Bind address，绑定变量地址
bln ：Bind buffer length，绑定变量缓冲区长度
avl ：Actual value length (array length too)，实际值的长度
flg ：Special flag indicating bind status，内部标记
value ：The actual value of the bind variable，绑定变量的实际值，有可能是16进制转储

***************************************
PARAMETERS USED BY THE OPTIMIZER
********************************
*************************************
PARAMETERS WITH ALTERED VALUES
******************************
_b_tree_bitmap_plans = false
optimizer_dynamic_sampling = 3
*************************************
PARAMETERS WITH DEFAULT VALUES
******************************
optimizer_mode_hinted = false
optimizer_features_hinted = 0.0.0
parallel_execution_enabled = true
性能相关的初始化参数值
。。。。。省略若干行。。。。。。
_optimizer_star_tran_in_with_clause = true
_optimizer_complex_pred_selectivity = true
_gby_hash_aggregation_enabled = true
***************************************
PARAMETERS IN OPT_PARAM HINT
****************************
***************************************
Column Usage Monitoring is ON: tracking level = 1
***************************************
****************
QUERY BLOCK TEXT
****************
select t1.* from t1,t where t.x<100 and t.x=t1.id
*********************
QUERY BLOCK SIGNATURE
*********************
qb name was generated
signature (optimizer): qb_name=SEL$1 nbfros=2 flg=0
fro(0): flg=0 objn=53393 hint_alias="T"@"SEL$1"
fro(1): flg=0 objn=53395 hint_alias="T1"@"SEL$1"
*****************************
SYSTEM STATISTICS INFORMATION
*****************************
 Using NOWORKLOAD Stats                       基于非工作量统计模式

CPUSPEEDNW: 2696 millions instructions/sec (default is 100)         非工作量统计模式下CPU主频

IOTFRSPEED: 4096 bytes per millisecond (default is 4096)    IO传输速率（字节/毫秒）

IOSEEKTIM: 10 milliseconds (default is 10)                IO寻址时间（毫秒）

MBRC: -1 blocks (default is 8)            一次多块读可以读几个数据块
***************************************
BASE STATISTICAL INFORMATION
这一部分是sql中应用到的对象基本信息，包括表关联和各自索引的信息，这些信息都可以在相关视图中找到，如user_indexes,user_tables等
***********************
Table Stats::
Table: T Alias: T
#Rows: 50701 #Blks: 86 AvgRowLen: 4.00
Column (#1): X(NUMBER)
AvgLen: 5.00 NDV: 50701 Nulls: 0 Density: 1.9723e-05 Min: 6 Max: 50700
Index Stats::
Index: T_IDX Col#: 1
LVLS: 1 #LB: 112 #DK: 50701 LB/K: 1.00 DB/K: 1.00 CLUF: 78.00
***********************
Table Stats::
Table: T1 Alias: T1
#Rows: 50701 #Blks: 251 AvgRowLen: 29.00
Column (#1): ID(NUMBER)
AvgLen: 5.00 NDV: 50701 Nulls: 0 Density: 1.9723e-05 Min: 8 Max: 53394
Index Stats::
Index: T1_IDX Col#: 1
LVLS: 1 #LB: 112 #DK: 50701 LB/K: 1.00 DB/K: 1.00 CLUF: 393.00
表信息的部分中包括了表的行数、数据块数、平均行数。对于字段，只列出了谓词条件中包含的字段。对于在谓词中没有出现的字段，因为它不影响执行计划的选择，所以以CBO不需要将他考虑到代价中，我们看到，这里列出的是X字段，因为它既是两表关联的字段，同时自身也是一个谓词条件，X列的信息包括了它的类型、平均长度、非重复的值、空值、密度以及列的最大最小值，这些信息在CBO做执行计划代价的计算上都要作为输入的值。
  索引项部分中列出了所以的高度，索引页块数（LB，Leaf Blocks），每个索引占据的数据块数（LB/K Leaf Blocks/Key），每个索引键值对应的表中数据块（DB/K，Data Blocks/Key），索引的聚合因子（CLUF，Clustering Factor）。集合因子CLUF（索引聚合因子），它表示索引中的键值和元表中的数据分布的一种关系，当索引键值和表中数据的排列顺序大致相同时，它意味着键值指向的数据块越多时（数据排序和索引相差越大）时，这个因子就越大，越不利于索引的使用。了解这个指标对于我们分析sql的执行计划很有用处，比如我们发现SQL执行计划异常，可是从cardinality上无法解释，也许应该考虑一下是否是CLUF的影响导致的。关于CLUF可以参加如下文章：
http://czmmiao.iteye.com/blog/1481957
***************************************
SINGLE TABLE ACCESS PATH
*** 2012-04-25 10:53:00.998
** Performing dynamic sampling initial checks. **
** Dynamic sampling initial checks returning FALSE.
Table: T1 Alias: T1
Card: Original: 50701 Rounded: 87 Computed: 87.37 Non Adjusted: 87.37

原始行数             近似值         精确值             非修正值
Access Path: TableScan
Cost: 58.69 Resp: 58.69 Degree: 0               --Cost:总代价
Cost_io: 57.00 Cost_cpu: 11929421            --Cost:总代价=IO代价 + CPU代价
Resp_io: 57.00 Resp_cpu: 11929421          --并行访问代价
Access Path: index (RangeScan)
Index: T1_IDX
resc_io: 3.00 resc_cpu: 53924                       --串行访问代价
ix_sel: 0.0017233 ix_sel_with_filters: 0.0017233

索引选择率     带过滤条件索引选择率
Cost: 3.01 Resp: 3.01 Degree: 1
Best:: AccessPath: IndexRange Index: T1_IDX
Cost: 3.01 Degree: 1 Resp: 3.01 Card: 87.37 Bytes: 0
***************************************
SINGLE TABLE ACCESS PATH
*** 2012-04-25 10:53:00.998
** Performing dynamic sampling initial checks. **
** Dynamic sampling initial checks returning FALSE.
Table: T Alias: T
Card: Original: 50701 Rounded: 94 Computed: 94.01 Non Adjusted: 94.01
Access Path: TableScan
Cost: 22.53 Resp: 22.53 Degree: 0
Cost_io: 21.00 Cost_cpu: 10752644
Resp_io: 21.00 Resp_cpu: 10752644
Access Path: index (index (FFS))
Index: T_IDX
resc_io: 26.00 resc_cpu: 9416771
ix_sel: 0.0000e+00 ix_sel_with_filters: 1
Access Path: index (FFS)
Cost: 27.34 Resp: 27.34 Degree: 1
Cost_io: 26.00 Cost_cpu: 9416771
Resp_io: 26.00 Resp_cpu: 9416771
Access Path: index (IndexOnly)
Index: T_IDX
resc_io: 2.00 resc_cpu: 33243
ix_sel: 0.0018543 ix_sel_with_filters: 0.0018543
Cost: 2.00 Resp: 2.00 Degree: 1
Best:: AccessPath: IndexRange Index: T_IDX
Cost: 2.00 Degree: 1 Resp: 2.00 Card: 94.01 Bytes: 0
这部分展示了CBO计算的每个对象单独访问的代价。CBO要计算出每个对象单独访问时的代价，通过比较所有的数据访问的代价，选择出代价最小的一种访问方式。以T表为例我们比较关心如下两个指标
Card:Original:50741
原纪录数，也就是操作数据源的数据纪录数，在这里就是表的实际纪录50741
Card：Rounded：94
输出的纪录数，CBO计算出通过条件过滤，预计得到的纪录数。我们知道T安装条件小于100的纪录数是94条，这里估算出是96条，比较接近实际值。
通过这一部分的信息我们看到，对于T表，CBO人为可能使用下面几种方式来访问数据。
全表扫描
Access Path: TableScan
索引快速扫描
Access Path: index (index (FFS))
单独访问索引
Access Path: index (IndexOnly)
因为在结果集里面是T1表的信息，所以对于T表，只需要访问索引做关联条件查询，不需要访问表，所以单独访问索引也是可行的。
CBO计算出三种方式产生的代价分别是：
TableScan: 22.53
index (FFS) 26
index (IndexOnly) 2.00
很显然，单独访问索引的方式是代价最低的，所以CBO得出的结论，对于T表上的查询，选择使用单独访问索引的方式。
Best:: AccessPath: IndexRange Index: T_IDX
Cost: 2.00 Degree: 1 Resp: 2.00 Card: 94.01 Bytes: 0
T1表的分析方法雷同，这里不再赘述。 这一部分，CBO计算了每个表单独进行数据访问代价最小的方式，为下一步表关联查询提供了代价计算的数据依据
***************************************
OPTIMIZER STATISTICS AND COMPUTATIONS
***************************************
GENERAL PLANS
***************************************
Considering cardinality-based initial join order.
***********************
Join order[1]: T1[T1]#0 T[T]#1             #T1关联T
***************
Now joining: T[T]#1
***************
NL Join                  #NESTED LOOPS JOIN
Outer table: Card: 87.37 Cost: 3.01 Resp: 3.01 Degree: 1 Bytes: 29
Inner table: T Alias: T
Access Path: TableScan
NL Join: Cost: 1773.79 Resp: 1773.79 Degree: 0
Cost_io: 1641.00 Cost_cpu: 935533938
Resp_io: 1641.00 Resp_cpu: 935533938
Access Path: index (index (FFS))
Index: T_IDX
resc_io: 24.52 resc_cpu: 9416771
ix_sel: 0.0000e+00 ix_sel_with_filters: 1
Inner table: T Alias: T
Access Path: index (FFS)
NL Join: Cost: 2252.29 Resp: 2252.29 Degree: 0
Cost_io: 2136.00 Cost_cpu: 819313026
Resp_io: 2136.00 Resp_cpu: 819313026
kkofmx: index filter:"T"."X"<100 AND "T"."X"="T1"."ID" AND "T1"."ID"<100
Access Path: index (AllEqJoinGuess)
Index: T_IDX
resc_io: 1.00 resc_cpu: 8171
ix_sel: 1.9723e-05 ix_sel_with_filters: 3.6573e-08
NL Join (ordered): Cost: 90.11 Resp: 90.11 Degree: 1
Cost_io: 90.00 Cost_cpu: 769190
Resp_io: 90.00 Resp_cpu: 769190
Best NL cost: 90.11        #最好的nested loops join方式，代价为90.11
resc: 90.11 resc_io: 90.00 resc_cpu: 769190
resp: 90.11 resp_io: 90.00 resp_cpu: 769190
Join Card: 86.47 = outer (87.37) * inner (94.01) * sel (0.010526)
Join Card - Rounded: 86 Computed: 86.47
SM Join               #SORT MERGE JOIN
Outer table:
resc: 3.01 card 87.37 bytes: 29 deg: 1 resp: 3.01
Inner table: T Alias: T
resc: 2.00 card: 94.01 bytes: 4 deg: 1 resp: 2.00
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 106 Area size: 131072 Max Area size: 18874368
Degree: 1
Blocks to Sort: 1 Row size: 15 Total Rows: 94
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 7073149
Total Temp space used: 0
SM join: Resc: 6.02 Resp: 6.02 [multiMatchCost=0.00]
SM cost: 6.02             #Sort merge join的代价为6.02
resc: 6.02 resc_io: 5.00 resc_cpu: 7160316
resp: 6.02 resp_io: 5.00 resp_cpu: 7160316
HA Join
Outer table:
resc: 3.01 card 87.37 bytes: 29 deg: 1 resp: 3.01
Inner table: T Alias: T
resc: 2.00 card: 94.01 bytes: 4 deg: 1 resp: 2.00
using dmeth: 2 #groups: 1
Cost per ptn: 0.50 #ptns: 1
hash_area: 0 (max=0) Hash join: Resc: 5.52 Resp: 5.52 [multiMatchCost=0.00]
HA cost: 5.52             #hash join的代价为5.52 
resc: 5.52 resc_io: 5.00 resc_cpu: 3632312
resp: 5.52 resp_io: 5.00 resp_cpu: 3632312
Best:: JoinMethod: Hash
  Cost: 5.52 Degree: 1 Resp: 5.52 Card: 86.47 Bytes: 33           
***********************
Best so far: Table#: 0 cost: 3.0077 card: 87.3729 bytes: 2523
Table#: 1 cost: 5.5156 card: 86.4652 bytes: 2838
#CBO得出结论，T1表关联T表代价最下的join方式为hash join的代价为5.52
***********************
Join order[2]: T[T]#1 T1[T1]#0             #T表关联T1表 
***************
Now joining: T1[T1]#0
***************
NL Join             #NESTED LOOPS JOIN
Outer table: Card: 94.01 Cost: 2.00 Resp: 2.00 Degree: 1 Bytes: 4
Inner table: T1 Alias: T1
Access Path: TableScan
NL Join: Cost: 5324.17 Resp: 5324.17 Degree: 0
Cost_io: 5165.00 Cost_cpu: 1121398858
Resp_io: 5165.00 Resp_cpu: 1121398858
kkofmx: index filter:"T1"."ID"<100
Access Path: index (AllEqJoinGuess)
Index: T1_IDX
resc_io: 2.00 resc_cpu: 15463
ix_sel: 1.9723e-05 ix_sel_with_filters: 3.3989e-08
NL Join (ordered): Cost: 190.21 Resp: 190.21 Degree: 1
Cost_io: 190.00 Cost_cpu: 1491454
Resp_io: 190.00 Resp_cpu: 1491454
Best NL cost: 190.21             #最好的nested loops join的代价为190.21 
resc: 190.21 resc_io: 190.00 resc_cpu: 1491454
resp: 190.21 resp_io: 190.00 resp_cpu: 1491454
Join Card: 86.47 = outer (94.01) * inner (87.37) * sel (0.010526)
Join Card - Rounded: 86 Computed: 86.47
SM Join             #Sort merge join
Outer table:
resc: 2.00 card 94.01 bytes: 4 deg: 1 resp: 2.00
Inner table: T1 Alias: T1
resc: 3.01 card: 87.37 bytes: 29 deg: 1 resp: 3.01
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 106 Area size: 131072 Max Area size: 18874368
Degree: 1
Blocks to Sort: 1 Row size: 42 Total Rows: 87
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 7070644
Total Temp space used: 0
SM join: Resc: 6.02 Resp: 6.02 [multiMatchCost=0.00]
SM cost: 6.02             #Sort merge join的代价为6.02
resc: 6.02 resc_io: 5.00 resc_cpu: 7157811
resp: 6.02 resp_io: 5.00 resp_cpu: 7157811
HA Join             #hash join
Outer table:
resc: 2.00 card 94.01 bytes: 4 deg: 1 resp: 2.00
Inner table: T1 Alias: T1
resc: 3.01 card: 87.37 bytes: 29 deg: 1 resp: 3.01
using dmeth: 2 #groups: 1
Cost per ptn: 0.50 #ptns: 1
hash_area: 0 (max=0) Hash join: Resc: 5.52 Resp: 5.52 [multiMatchCost=0.00]
HA cost: 5.52             #hash join的代价为5.52，这里计算出来的代价值和上面T1关联T表的代价值相等，那么CBO会继续比较串行执行和并行执行的IO和CPU代价
resc: 5.52 resc_io: 5.00 resc_cpu: 3632662         #串行执行的CPU代价为3632662大于上面计算出来的3632312 
resp: 5.52 resp_io: 5.00 resp_cpu: 3632662         #并行执行的CPU代价为3632662大于上面计算出来的3632312 
Join order aborted: cost > best plan cost         # 废弃该join方式
***********************
(newjo-stop-1) k:0, spcnt:0, perm:2, maxperm:2000
*********************************
Number of join permutations tried: 2
*********************************
(newjo-save) [1 0 ]
Final - All Rows Plan: Best join order: 1         # 得出结论，采用T1表hash joinT表的方式
Cost: 5.5156 Degree: 1 Card: 86.0000 Bytes: 2838         # 具体代价
Resc: 5.5156 Resc_io: 5.0000 Resc_cpu: 3632312
Resp: 5.5156 Resp_io: 5.0000 Resc_cpu: 3632312
kkoipt: Query block SEL$1 (#0)
******* UNPARSED QUERY IS *******
SELECT "T1"."ID" "ID","T1"."OBJECT_NAME" "OBJECT_NAME" FROM "HR"."T1" "T1","HR"."T" "T" WHERE "T1"."ID"<:B1 AND "T"."X"="T1"."ID" AND "T"."X"<:B2
kkoqbc-end
: call(in-use=43384, alloc=49112), compile(in-use=37140, alloc=37692)
apadrv-end: call(in-use=43384, alloc=49112), compile(in-use=37760, alloc=41816)
sql_id=azdnm8t9dwdb3.
Current SQL statement for this session:
select t1.* from t1,t where t.x<:c and t.x=t1.id
============
Plan Table
============
------------------------------------------------+-----------------------------------+
| Id | Operation | Name | Rows | Bytes | Cost | Time |
------------------------------------------------+-----------------------------------+
| 0 | SELECT STATEMENT | | | | 6 | |
| 1 | HASH JOIN | | 3 | 99 | 6 | 00:00:01 |
| 2 | INDEX RANGE SCAN | T_IDX | 3 | 12 | 2 | 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID | T1 | 5 | 145 | 3 | 00:00:01 |
| 4 | INDEX RANGE SCAN | T1_IDX | 5 | | 2 | 00:00:01 |
------------------------------------------------+-----------------------------------+
Predicate Information:
----------------------
1 - access("T"."X"="T1"."ID")
2 - access("T"."X"<:C)
4 - access("T1"."ID"<:C)
Content of other_xml column
执行计划
===========================
db_version : 10.2.0.1
parse_schema : HR
plan_hash : 1611193875
Outline Data:
/*+
BEGIN_OUTLINE_DATA
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE('10.2.0.1')
OPT_PARAM('_b_tree_bitmap_plans' 'false')
OPT_PARAM('optimizer_dynamic_sampling' 3)
ALL_ROWS
OUTLINE_LEAF(@"SEL$1")
INDEX(@"SEL$1" "T1"@"SEL$1" ("T1"."ID"))
INDEX(@"SEL$1" "T"@"SEL$1" ("T"."X"))
LEADING(@"SEL$1" "T1"@"SEL$1" "T"@"SEL$1")
USE_HASH(@"SEL$1" "T"@"SEL$1")
END_OUTLINE_DATA
*/

Optimizer environment:
optimizer_mode_hinted = false
optimizer_features_hinted = 0.0.0
参数和bug信息
。。。。。省略若干行。。。。。。
Query Block Registry:
*********************
MISC$1 0xb7f4ac90 (PARSER) [FINAL]
Optimizer State Dump: call(in-use=84156, alloc=84156), compile(in-use=38936, alloc=82100)

参考至:《让Oracle跑得更快》谭怀远著
             http://www.2cto.com/database/201202/118282.html
             http://f.dataguru.cn/thread-183790-1-1.html
             http://blog.itpub.net/26686207/viewspace-754644/
本文原创，转载请注明出处，作者
如有错误，欢迎指正
邮箱:[email protected]