10053事件分析案例一则

测试库两张表,数据一致,(表有复合主键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 INFORMATION
***********************
Table stats    Table: T1   Alias: T1 来自user_tables视图
  TOTAL ::  CDN: 2341358  NBLKS:  13921  AVG_ROW_LEN:  40
-- Index stats 来自user_indexes视图
  INDEX NAME: IDX_STAROTHER  COL#: 2 3 
    TOTAL ::  LVLS: 2   #LB: 13609  #DK: 2156054  LB/K: 1  DB/K: 1  CLUF: 165252
_OPTIMIZER_PERCENT_PARALLEL = 0
***************************************
SINGLE TABLE ACCESS PATH
Column: AIRLINE_CO  Col#: 2      Table: T1 Alias: T1
    NDV: 7         NULLS: 0         DENS: 1.4286e-01
    NO HISTOGRAM: #BKT: 1 #VAL: 2
  TABLE: STAROTHERPRF     ORIG CDN: 2341358  ROUNDED CDN: 334480  CMPTD CDN: 334480
  Access path: tsc  Resc:  1340  Resp:  1340   全表扫描代价(1340),这里tsc我想应该是TableScan的缩写
  Skip scan: ss-sel 0  andv 308008  
    ss cost 308008  索引跳跃扫描的代价(1945)
    index io scan cost 1945 
  Access path: index (index-only) 索引(范围)扫描代价(1947)
      Index: IDX_T1
  TABLE: T1
      RSC_CPU: 0   RSC_IO: 1947
  IX_SEL:  1.4286e-01  TB_SEL:  1.4286e-01

  BEST_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的适用场景。

你可能感兴趣的:(oracle,10053)