测试库两张表,数据一致,(表有复合主键A+B),但同样执行DELETE TABLE FROM T1/T2 WHERE A='1' AND ROWNUM<100;时,T1表删除时间非常长,T2表删除时间很快。在PLSQL中或sqlplus中查看执行计划都是一样的,表示都用到了索引范围扫描。
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
-----------------------------------------------------------------------
| 0 | DELETE STATEMENT | | 1000 | 12000 | 3217 |
| 1 | DELETE | T1 | | | |
|* 2 | COUNT STOPKEY | | | | |
|* 3 | INDEX RANGE SCAN | IDX_T1 | 420K| 4931K| 3217 |
-----------------------------------------------------------------------
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
2 - filter(ROWNUM<=1000)
3 - access("T1"."A"='1')
Note: cpu costing is off
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
--------------------------------------------------------------------
| 0 | DELETE STATEMENT | | 1000 | 12000 | 2965 |
| 1 | DELETE | T2 | | | |
|* 2 | COUNT STOPKEY | | | | |
|* 3 | INDEX RANGE SCAN | IDX_T2 | 393K| 4607K| 2965 |
--------------------------------------------------------------------
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
2 - filter(ROWNUM<=1000)
3 - access("T2"."A"='1')
Note: cpu costing is off
显然感觉这两个表的实际操作和执行计划不太相符,这时10053事件就起到了作用。
10053介绍:
10053 事件是oracle 提供的用于跟踪sql 语句成本计算的内部事件,它能记载CBO 模式下oracle 优化器如何计算sql 成本,生成相应的执行计划。 用来描述oracle如何选择执行计划的过程,然后输出到trace文件里,因为我们经常看执行计划怎么执行的消耗了哪些资源,而不是常看执行计划怎么选择出来了的。
10053特点:
(1) 只可以了解oracle执行计划的选择过程
(2) 无法获知代价的计算公式,因为这是oracle内部的商业机密,而且每个oracle版本的优化器计算公式都不相同差距还是蛮大的,不同版本的同一个语句的代价也不一样,优化器现在还不是很成熟,还有待完善。
(3) 在这个里面我们重点要了解的是“代价”是如何计算出来的,然后我们才能了解执行计划是如何选择的。
(4) 在10053中可以了解哪些因素影响sql的执行代价
(5) oracle 8i cost等价IO资源消耗 9i以后cost等价IO+CPU+网络+等待事件+其他代价
T1表的10053事件信息:
***************************************
BASE STATISTICAL INFORMATIONBEST_CST: 1340.00 PATH: 2 Degree: 1 最佳代价是1340,即全表扫描
对应的执行计划:
***************************************
GENERAL PLANS
***********************
Join order[1]: STAROTHERPRF[STAROTHERPRF]#0
Best so far: TABLE#: 0 CST: 1340 CDN: 334480 BYTES: 4348240
Final - All Rows Plan:
JOIN ORDER: 1
CST: 1340 CDN: 334480 RSC: 1340 RSP: 1340 BYTES: 4348240
IO-RSC: 1340 IO-RSP: 1340 CPU-RSC: 0 CPU-RSP: 0
QUERY
explain plan for delete from starotherprf WHERE AIRLINE_CODE = 'US' AND ROWNUM <= 1000
PLAN
Cost of plan: 1340
Operation...........Object name.....Options.........Id...Pid..
DELETE STATEMENT 0
DELETE STAROTHERPRF 1
COUNT STOPKEY 2 1
TABLE ACCESS T1 FULL 3 2
QUERY
显示用的就是全表扫描
T2表的10053事件信息:
***************************************
SINGLE TABLE ACCESS PATH
Column: AIRLINE_CO Col#: 1 Table: T2 Alias: T2
NDV: 19 NULLS: 0 DENS: 5.2632e-02
NO HISTOGRAM: #BKT: 1 #VAL: 2
TABLE: CASTARPRF ORIG CDN: 6665065 ROUNDED CDN: 350793 CMPTD CDN: 350793
Access path: tsc Resc: 4275 Resp: 4275 全表扫描代价(4275)
Skip scan: ss-sel 0 andv 413617 索引跳跃扫描代价(413617)
ss cost 413617
index io scan cost 1973
Access path: index (index-only) 索引(范围)扫描代价(1975)
Index: IDX_T2
TABLE: T2
RSC_CPU: 0 RSC_IO: 1975
IX_SEL: 5.2632e-02 TB_SEL: 5.2632e-02
BEST_CST: 1975.00 PATH: 4 Degree: 1 最佳代价是1975,即索引扫描
对应的执行计划:
***************************************
GENERAL PLANS
***********************
Join order[1]: CASTARPRF[CASTARPRF]#0
Best so far: TABLE#: 0 CST: 1975 CDN: 350793 BYTES: 4911102
prefetching is on for IDX_CASTAR
Final - All Rows Plan:
JOIN ORDER: 1
CST: 1975 CDN: 350793 RSC: 1975 RSP: 1975 BYTES: 4911102
IO-RSC: 1975 IO-RSP: 1975 CPU-RSC: 0 CPU-RSP: 0
QUERY
explain plan for delete from castarprf WHERE AIRLINE_CODE = 'US' AND ROWNUM <= 1000
PLAN
Cost of plan: 1975
Operation...........Object name.....Options.........Id...Pid..
DELETE STATEMENT 0
DELETE CASTARPRF 1
COUNT STOPKEY 2 1
INDEX IDX_T2 RANGE SCAN 3 2
QUERY
显示用的就是索引扫描
现在就可以知道为什么这两张表删除时间不同了,原因就是T1表CBO选择了错误的执行计划,导致全表扫描,因此百万级的数据就会耗费更长的时间。
总结:当感觉SQL语句执行时走的是错误的执行计划,而又找不到原因时,这时请用10053来分析一下原因。这就是10053的适用场景。