查看: 5496|回复: 28

920的CBO还是不够'聪明'

[复制链接]
认证徽章
论坛徽章:
168
马上加薪
日期:2014-02-19 11:55:142012新春纪念徽章
日期:2012-02-13 15:10:582012新春纪念徽章
日期:2012-01-04 11:49:54蜘蛛蛋
日期:2011-12-05 16:08:56ITPUB十周年纪念徽章
日期:2011-11-01 16:19:41设计板块每日发贴之星
日期:2011-07-22 01:01:02ITPUB官方微博粉丝徽章
日期:2011-06-30 12:30:16管理团队成员
日期:2011-05-07 01:45:082011新春纪念徽章
日期:2011-01-25 15:42:562011新春纪念徽章
日期:2011-01-25 15:42:33
发表于 2005-2-26 14:50 | 显示全部楼层 |阅读模式
今天客户报告说月结操作很慢,跟踪session发现很多表连接均为Hash join,FTS访问一张大表.
一个单位的月结平均需要12秒,把优化器模式变为rule后,优化器选择了正确的执行计划,一个单位的月结平均只需要2秒.对于上万个单位的月结,10秒的提高获取的收益是非常大的.


hp-ux 11.11
1g memory cpu x 2
oracle 9.2.0.6
论坛徽章:
226
BLOG每日发帖之星
日期:2010-02-11 01:01:06紫蛋头
日期:2013-01-12 23:45:222013年新春福章
日期:2013-02-25 14:51:24问答徽章
日期:2013-10-17 18:06:40优秀写手
日期:2013-12-18 09:29:10马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上加薪
日期:2014-02-19 11:55:14
发表于 2005-2-26 16:14 | 显示全部楼层
你如何收集的统计信息?

呵呵,我觉得还是不要对CBO期望的太高。

使用道具 举报

回复
认证徽章
论坛徽章:
168
马上加薪
日期:2014-02-19 11:55:142012新春纪念徽章
日期:2012-02-13 15:10:582012新春纪念徽章
日期:2012-01-04 11:49:54蜘蛛蛋
日期:2011-12-05 16:08:56ITPUB十周年纪念徽章
日期:2011-11-01 16:19:41设计板块每日发贴之星
日期:2011-07-22 01:01:02ITPUB官方微博粉丝徽章
日期:2011-06-30 12:30:16管理团队成员
日期:2011-05-07 01:45:082011新春纪念徽章
日期:2011-01-25 15:42:562011新春纪念徽章
日期:2011-01-25 15:42:33
发表于 2005-2-26 18:08 | 显示全部楼层
对大表10%采样收集,对小表1均全表收集.
10g的cbo相对于9i有很大的进步.

使用道具 举报

回复
论坛徽章:
31
管理团队2006纪念徽章
日期:2006-04-16 22:44:452012新春纪念徽章
日期:2012-02-13 15:11:522012新春纪念徽章
日期:2012-02-13 15:11:522012新春纪念徽章
日期:2012-02-13 15:11:522012新春纪念徽章
日期:2012-02-13 15:11:52铁扇公主
日期:2012-02-21 15:02:402013年新春福章
日期:2013-02-25 14:51:242014年新春福章
日期:2014-02-18 16:41:11马上有车
日期:2014-02-18 16:41:11马上有车
日期:2014-02-19 11:55:14
发表于 2005-2-26 18:13 | 显示全部楼层

Re: 920的CBO还是不够'聪明'

最初由 husthxd 发布
[B]
一个单位的月结平均需要12秒,把优化器模式变为rule后,优化器选择了正确的执行计划,一 [/B]


what is the "正确的执行计划"  ?   NL  ?

使用道具 举报

回复
认证徽章
论坛徽章:
168
马上加薪
日期:2014-02-19 11:55:142012新春纪念徽章
日期:2012-02-13 15:10:582012新春纪念徽章
日期:2012-01-04 11:49:54蜘蛛蛋
日期:2011-12-05 16:08:56ITPUB十周年纪念徽章
日期:2011-11-01 16:19:41设计板块每日发贴之星
日期:2011-07-22 01:01:02ITPUB官方微博粉丝徽章
日期:2011-06-30 12:30:16管理团队成员
日期:2011-05-07 01:45:082011新春纪念徽章
日期:2011-01-25 15:42:562011新春纪念徽章
日期:2011-01-25 15:42:33
发表于 2005-2-26 18:32 | 显示全部楼层
我意思的'正确'执行计划是指远远优于cbo的执行计划.
1.选择了正确的驱动表
2.选择了nl join

使用道具 举报

回复
论坛徽章:
86
ITPUB元老
日期:2005-02-28 12:57:002012新春纪念徽章
日期:2012-01-04 11:49:542012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:20咸鸭蛋
日期:2012-05-08 10:27:19版主8段
日期:2012-05-15 15:24:112013年新春福章
日期:2013-02-25 14:51:24
发表于 2005-2-26 19:33 | 显示全部楼层
不管cbo是不是聪明,在陈述这个问题的时候,我觉得应该交代几个问题:

1:sql
2:相关数据分布/数据量/满足条件数据量 和返回数据量
3:分析方式(是否分析索引和其column  histograms)
4:好执行计划是什么,不好执行计划是什么

在这些基础上,可以尝试一下 CBO 下的 10053 trace 看看成本分别如何计算的



如果你只是告诉大家一个 cbo 不够聪明,对大家没多大的价值,因为可能有更多的人发现他们的cbo还是蛮聪明的。而这种问题只能 case  by  case ,不能一概而论。

使用道具 举报

回复
认证徽章
论坛徽章:
168
马上加薪
日期:2014-02-19 11:55:142012新春纪念徽章
日期:2012-02-13 15:10:582012新春纪念徽章
日期:2012-01-04 11:49:54蜘蛛蛋
日期:2011-12-05 16:08:56ITPUB十周年纪念徽章
日期:2011-11-01 16:19:41设计板块每日发贴之星
日期:2011-07-22 01:01:02ITPUB官方微博粉丝徽章
日期:2011-06-30 12:30:16管理团队成员
日期:2011-05-07 01:45:082011新春纪念徽章
日期:2011-01-25 15:42:562011新春纪念徽章
日期:2011-01-25 15:42:33
发表于 2005-2-26 20:21 | 显示全部楼层
今天星期六,本想明天整理的
sql语句如下:
SELECT SUM(NVL(A.JCYLJ,0)), SUM(NVL(A.GDXYLJ,0)), SUM(NVL(A.GRZHYLJ,0)),
             SUM(NVL(A.HLF,0)), SUM(NVL(A.DFBCLXDY,0)), SUM(NVL(A.HYGDXBT,0)),
             SUM(NVL(A.DYZE,0))
        INTO v_JCYLJ_ZJ, v_GDXYLJ_ZJ, v_GRZHYLJ_ZJ,
             v_HLF_ZJ, v_DFBCLXDY_ZJ, v_HYGDXBT_ZJ, v_HJ_ZJ
        FROM <TABLE_A> A, <TABLE_B> B, <VIEW_C> C
       WHERE A.GRBH = B.GRBH AND
             A.GRBH = C.GRBH AND
             C.DWBH = :b1 AND
             B.JZSJ = :b2 AND
             B.YWZJBZ = '2';

表/索引均有统计数据,但没有column histograms.
TABLE_A大概有80万条记录
TABLE_B大概有40万条记录
VIEW_C大概有70万条记录
1.B.JZSJ和B.YWZJBZ的选择性不高,在B.JZSJ和B.YWZJBZ上建立索引并不合适.
2.C上的C.DWBH有很高的选择性,在C.DWBH 上有索引.
期望的访问方式为以VIEW_C为驱动表与A连接,然后在与B连接.
当时没有把执行计划copy下来,大体如下:

cost优化器模式:
执行计划为
首先TABLE_B与TABLE_A采用NL join连接,驱动表为TABLE_B,TABLE_B的访问方式为全表扫描.然后与VIEW_C连接,方式为hash join.

rule优化模式:
执行计划为
VIEW_C与TABLE_A采用NL join连接,驱动表为"VIEW_C",使用了C.DWBH上的索引.然后与TABLE_B连接,连接方式为nl join.
真是期望的访问方式.

由于存储过程是其他开发商开发的,由于存在很多复杂的因素,sql的修改基本上是不可能的.

使用道具 举报

回复
论坛徽章:
0
发表于 2005-2-26 23:15 | 显示全部楼层
最初由 husthxd 发布
[B]对大表10%采样收集, [/B]

10%少点了,试一下30%-50%,毕竟才几十万的记录。

使用道具 举报

回复
论坛徽章:
226
BLOG每日发帖之星
日期:2010-02-11 01:01:06紫蛋头
日期:2013-01-12 23:45:222013年新春福章
日期:2013-02-25 14:51:24问答徽章
日期:2013-10-17 18:06:40优秀写手
日期:2013-12-18 09:29:10马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上加薪
日期:2014-02-19 11:55:14
发表于 2005-2-26 23:20 | 显示全部楼层
如果可能试试收集一下被索引列的信息。

使用道具 举报

回复
论坛徽章:
86
ITPUB元老
日期:2005-02-28 12:57:002012新春纪念徽章
日期:2012-01-04 11:49:542012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:20咸鸭蛋
日期:2012-05-08 10:27:19版主8段
日期:2012-05-15 15:24:112013年新春福章
日期:2013-02-25 14:51:24
发表于 2005-2-26 23:34 | 显示全部楼层
rule base 下如果走nl 则 from 后面最末尾的表作为驱动表,所以,不能说rule聪明,是碰巧还是故意放后面的?

由于正好版本是920,又还使用了绑定变量,所以问题倒还复杂了起来,执行计划控制反而困难了,确信c表满足条件记录少则使用hints为好,但既然已经不可能修改,则也许分析 hisgrams 可以带来好处,利用  *窥视*  功能。

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备09055130号-4  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表