ITPUB??ì3
2010数据库技术大会
ITPUB论坛 » Oracle数据库管理 » 烦人的"Recost for ORDER BY"

您有 2 条公共消息
  • 来自: 公共消息 标题: 新开"PLM/PDM产品 ... 内容: 讨论范围包括:产品研发管理(PDM),产品生命周期管理(PLM),工艺/ ...
  • 来自: 公共消息 标题: 2010数据库技术大 ... 内容: “2010数据库技术大会”将于2010年4月2日~4月3日,在北京歌华开元大酒 ...

    标题: 烦人的"Recost for ORDER BY"
    离线 mihawk
    卡卡西


    来自 杭州
    精华贴数 1
    个人空间 72
    技术积分 1645 (1256)
    社区积分 64 (5303)
    注册日期 2004-12-27
    论坛徽章:4
    2008北京奥运纪念徽章:皮划艇激流回旋2008北京奥运纪念徽章:柔道2008北京奥运纪念徽章:羽毛球生肖徽章2007版:鸡  
          

    发表于 2008-3-20 11:42 
    烦人的"Recost for ORDER BY"

    起因是一个SQL走错了索引
    SELECT ROWID AS rid
    FROM tab_1 s
    WHERE s.c_id = :1
    ORDER BY s.gmt_r DESC

    执行计划如下
    ------------------------------------------------------------------------------------------
    | Id  | Operation                   |  Name                      | Rows  | Bytes | Cost  |
    ------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT            |                            |   858 | 25740 |   138K|
    |*  1 |  TABLE ACCESS BY INDEX ROWID| tab_1               |   858 | 25740 |   138K|
    |*  2 |   INDEX FULL SCAN DESCENDING| tab_1_RPST_ST_IND  |   605K|       |  3408 |
    ------------------------------------------------------------------------------------------

    Predicate Information (identified by operation id):
    ---------------------------------------------------

       1 - filter("S"."c_id"=TO_NUMBER(:Z))
    CBO走了排序字段的索引, 而不是过滤度很高的c_id字段上的索引.

    10053 Trace发现的东西
    ***************************************
    SINGLE TABLE ACCESS PATH
    Column: C_ID  Col#: 4      Table: tab_1   Alias:  S
        NDV: 1854      NULLS: 0         DENS: 1.4164e-03
        HEIGHT BALANCED HISTOGRAM: #BKT: 72 #VAL: 73
    Column:     STATUS  Col#: 33     Table: tab_1   Alias:  S
        NDV: 4         NULLS: 0         DENS: 5.0201e-04
        FREQUENCY HISTOGRAM: #BKT: 996 #VAL: 4
      TABLE: tab_1     ORIG CDN: 657584  ROUNDED CDN: 858  CMPTD CDN: 858
      Access path: tsc  Resc:  1868  Resp:  1868
      Access path: index (scan)
          Index: tab_1_CID_ST_GE_IND
      TABLE: tab_1
          RSC_CPU: 0   RSC_IO: 122
      IX_SEL:  1.3048e-03  TB_SEL:  1.3048e-03
      Access path: index (no sta/stp keys)
          Index: tab_1_GID_CID_ST_IND
      TABLE: tab_1
          RSC_CPU: 0   RSC_IO: 3785
      IX_SEL:  1.0000e+00  TB_SEL:  1.3048e-03
      Access path: index (no sta/stp keys)
          Index: tab_1_RPST_ST_IND
      TABLE: tab_1
          RSC_CPU: 0   RSC_IO: 138323
      IX_SEL:  1.0000e+00  TB_SEL:  9.2118e-01
      BEST_CST: 122.00  PATH: 4  Degree:  1-------------------------CBO在计算了全表扫描和各个索引的扫描成本以后找到到了正确的索引, cost是122.
    ***************************************
    OPTIMIZER STATISTICS AND COMPUTATIONS
    ***************************************
    GENERAL PLANS
    ***********************
    Join order[1]: tab_1 [ S]
    ORDER BY sort
        SORT resource      Sort statistics
          Sort width:          119 Area size:      838656 Max Area size:    41943040   Degree: 1
          Blocks to Sort:        5 Row size:           43 Rows:        858
          Initial runs:          1 Merge passes:        1 IO Cost / pass:         17
          Total IO sort cost: 11------------------------------------------------------排序, cost为11
          Total CPU sort cost: 0
          Total Temp space used: 0
    Best so far: TABLE#: 0  CST:        133  CDN:        858  BYTES:      25740
                                                           ↑---------------------------------------------------总cost为122+11=133
    ****** Recost for ORDER BY (using index) ************ --------------------成本重算, 噩梦的开始.
    ***************************************
    SINGLE TABLE ACCESS PATH
      TABLE: tab_1     ORIG CDN: 657584  ROUNDED CDN: 858  CMPTD CDN: 858
      Access path: tsc  Resc:  1868  Resp:  1868
      Skip scan: ss-sel 1  andv 176430  
        ss cost 176430
        index io scan cost 3406
      Access path: index (no sta/stp keys)
          Index: tab_1_RPST_ST_IND
      TABLE: tab_1
          RSC_CPU: 0   RSC_IO: 138323
      IX_SEL:  1.0000e+00  TB_SEL:  9.2118e-01
      BEST_CST: 138323.00  PATH: 4  Degree:  1-----------------------CBO重新选择了排序字段所在的index, 尽管它的cost是13万.
    ***********************
    Join order[1]: tab_1 [ S]
    Best so far: TABLE#: 0  CST:     138323  CDN:        858  BYTES:      25740-------------best so far, 看到这几个字, 表示CBO停止了更多执行计划的尝试.
        SORT resource      Sort statistics
          Sort width:          119 Area size:      838656 Max Area size:    41943040   Degree: 1
          Blocks to Sort:        5 Row size:           43 Rows:        858
          Initial runs:          1 Merge passes:        1 IO Cost / pass:         17
          Total IO sort cost: 11
          Total CPU sort cost: 0
          Total Temp space used: 0
    Final:-------------------------------------------------------------------------final, 最终选择了cost为13万的执行计划.  
    CST: 138323  CDN: 858  RSC: 138323  RSP: 138323  BYTES: 25740
      IO-RSC: 138323  IO-RSP: 138323  CPU-RSC: 0  CPU-RSP: 0
      First Rows Plan
    PLAN
    Cost of plan:  138323
    Operation...........Object name.....Options.........Id...Pid..
    SELECT STATEMENT                                        0
    TABLE ACCESS        tab_1    BY INDEX ROWID      1
    INDEX               tab_1_RPFULL SCAN DESCEN    2    1

    数据库版本是9.2.0.4, 我的问题是CBO为什么会在13万的cost和133的cost之间选择了前者.


    [ 本帖最后由 mihawk 于 2008-10-20 14:52 编辑 ]


    __________________
    ◆◆决定一个SQL执行效率的是执行计划, 而不是SQL的写法.◆◆
    1. 数据真实的"统计"的分布情况
    2. 系统视图中记录的统计信息
    3. 实际每个SQL执行时对应的数据情况

    欢迎访问Alibaba DBA 团队Blog: www.alidba.net
    只看该作者    顶部
    离线 vogts
    财神


    精华贴数 0
    个人空间 0
    技术积分 2258 (857)
    社区积分 46 (6225)
    注册日期 2004-12-20
    论坛徽章:7
    会员2007贡献徽章CTO参与奖2008北京奥运纪念徽章:羽毛球2008北京奥运纪念徽章:射箭2008北京奥运纪念徽章:皮划艇激流回旋生肖徽章2007版:鼠
    ITPUB新首页上线纪念徽章     

    发表于 2008-3-20 11:55 
    是不是直方图的统计信息不对啊???


    __________________
    wt66550601@hotmail.com
    只看该作者    顶部
    离线 mihawk
    卡卡西


    来自 杭州
    精华贴数 1
    个人空间 72
    技术积分 1645 (1256)
    社区积分 64 (5303)
    注册日期 2004-12-27
    论坛徽章:4
    2008北京奥运纪念徽章:皮划艇激流回旋2008北京奥运纪念徽章:柔道2008北京奥运纪念徽章:羽毛球生肖徽章2007版:鸡  
          

    发表于 2008-3-20 11:58 


    QUOTE:
    原帖由 vogts 于 2008-3-20 11:55 发表
    是不是直方图的统计信息不对啊???

    直方图的统计信息是最新的, 而且基于直方图计算出来的cost是正确的, 符合实际情况的.


    __________________
    ◆◆决定一个SQL执行效率的是执行计划, 而不是SQL的写法.◆◆
    1. 数据真实的"统计"的分布情况
    2. 系统视图中记录的统计信息
    3. 实际每个SQL执行时对应的数据情况

    欢迎访问Alibaba DBA 团队Blog: www.alidba.net
    只看该作者    顶部
    离线 justin033
    Popgo@XM


    精华贴数 0
    个人空间 0
    技术积分 644 (3542)
    社区积分 4 (21702)
    注册日期 2005-7-17
    论坛徽章:1
    ITPUB新首页上线纪念徽章     
          

    发表于 2008-3-20 12:33 
    attention!


    __________________
    Make Others Great!

    Unix-DBA google group

    To be a dba Unix DBA QQ group: 10098435
    只看该作者    顶部
    离线 mihawk
    卡卡西


    来自 杭州
    精华贴数 1
    个人空间 72
    技术积分 1645 (1256)
    社区积分 64 (5303)
    注册日期 2004-12-27
    论坛徽章:4
    2008北京奥运纪念徽章:皮划艇激流回旋2008北京奥运纪念徽章:柔道2008北京奥运纪念徽章:羽毛球生肖徽章2007版:鸡  
          

    发表于 2008-3-20 14:14 
    metalink查了, 是oracle的bug, id是1306032.


    __________________
    ◆◆决定一个SQL执行效率的是执行计划, 而不是SQL的写法.◆◆
    1. 数据真实的"统计"的分布情况
    2. 系统视图中记录的统计信息
    3. 实际每个SQL执行时对应的数据情况

    欢迎访问Alibaba DBA 团队Blog: www.alidba.net
    只看该作者    顶部
    离线 justin033
    Popgo@XM


    精华贴数 0
    个人空间 0
    技术积分 644 (3542)
    社区积分 4 (21702)
    注册日期 2005-7-17
    论坛徽章:1
    ITPUB新首页上线纪念徽章     
          

    发表于 2008-3-20 14:44 
    have fixed this bug? which the patch?


    __________________
    Make Others Great!

    Unix-DBA google group

    To be a dba Unix DBA QQ group: 10098435
    只看该作者    顶部
    离线 mihawk
    卡卡西


    来自 杭州
    精华贴数 1
    个人空间 72
    技术积分 1645 (1256)
    社区积分 64 (5303)
    注册日期 2004-12-27
    论坛徽章:4
    2008北京奥运纪念徽章:皮划艇激流回旋2008北京奥运纪念徽章:柔道2008北京奥运纪念徽章:羽毛球生肖徽章2007版:鸡  
          

    发表于 2008-3-20 15:10 
    刚刚在高人的指点下, 把_SORT_ELIMINATION_COST_RATIO 设为 1 就可以解决问题了.


    __________________
    ◆◆决定一个SQL执行效率的是执行计划, 而不是SQL的写法.◆◆
    1. 数据真实的"统计"的分布情况
    2. 系统视图中记录的统计信息
    3. 实际每个SQL执行时对应的数据情况

    欢迎访问Alibaba DBA 团队Blog: www.alidba.net
    只看该作者    顶部
    离线 paulyibinyi
    态度决定一切


    精华贴数 1
    个人空间 5299
    技术积分 5631 (287)
    社区积分 1791 (819)
    注册日期 2006-4-17
    论坛徽章:45
    ITPUB元老祖母绿CTO参与奖八级虎吧徽章2010新春纪念徽章祖国60周年纪念徽章
    ITPUB8周年纪念徽章生肖徽章2007版:马2009日食纪念生肖徽章2007版:虎生肖徽章2007版:虎生肖徽章2007版:龙

    发表于 2008-3-26 11:52 
    学习了


    __________________
    目前关注oracle 11gR2新技术
    坚持走好oracle dba的路
    my blog
    http://space.itpub.net/7199859/
    oracle各种不完全恢复测试用例欢迎下载
    http://www.itpub.net/viewthread.php?tid=974423
    oracle 10g install asm database pdf
    http://www.itpub.net/thread-1010536-1-1.html
    step by step install oracle10g rac+asm for linux
    http://www.itpub.net/thread-1014003-1-1.html
    step by step install oracle10g rac+asm for windows
    http://www.itpub.net/thread-1084821-1-1.html
    11g RMAN active database duplicate
    http://www.itpub.net/thread-1030938-1-1.html
    只看该作者    顶部
    离线 battleman
    一朵梨花压海棠


    来自 北京
    精华贴数 0
    个人空间 0
    技术积分 5006 (331)
    社区积分 93 (4391)
    注册日期 2004-4-13
    论坛徽章:25
    ITPUB元老会员2007贡献徽章授权会员生肖徽章2007版:兔生肖徽章2007版:马生肖徽章2007版:龙
    2009新春纪念徽章生肖徽章2007版:鸡生肖徽章2007版:猪2008北京奥运纪念徽章:皮划艇静水生肖徽章2007版:鸡生肖徽章2007版:龙

    发表于 2008-3-28 15:21 
    学习


    __________________
    北京晶锐恒通科技有限公司
                     ---专业的Oracle第三方服务公司
    MSN:         sleepingbag1124@hotmail.com
    TEL:          010-81966285
    MOBILE:    13811778831
    只看该作者    顶部
    离线 foxmile
    蚊子
    难得糊涂


    精华贴数 0
    个人空间 64
    技术积分 12854 (109)
    社区积分 3635 (488)
    注册日期 2004-5-8
    论坛徽章:21
    生肖徽章2007版:龙生肖徽章2007版:龙    
          

    发表于 2008-3-28 15:28 


    QUOTE:
    原帖由 mihawk 于 2008-3-20 14:14 发表
    metalink查了, 是oracle的bug, id是1306032.

    怎么触发这个bug的。


    __________________
    年年岁岁花相似 岁岁年年人不同
    我的blog   http://space.itpub.net/?79499
    只看该作者    顶部
    相关内容


    CopyRight 1999-2006 itpub.net All Right Reserved.
    北京皓辰网域网络信息技术有限公司. 版权所有
    E-mail:Webmaster@itpub.net
    网站律师 隐私政策 知识产权声明
    京ICP证:060528号 联系我们