一次分析的全过程,和大家交流!

phchristmas

不好意思, 我想问一下是在哪里做的分析呀?

Ian

最初由 忍者神龟 发布
[B]这个china oracle user group在哪里？
cp师兄
[/B]

http://www.*****.org/bin/ut/forum_show.cgi

halbert

但是oracle 公司的专家建议不要用analyze 分析表。

badboys

分析的思路比较好有借鉴之处

litsnake

好，这里高手真多

guhf2001

这个例子好像并不能说明什么问题。
从第一个分析结果来判断，就应该在sp_trans表的vendor_id上创建索引。而真正起作用的也正是这个索引。而不在于是RBO还是CBO。

htp

哎，看不懂，还需要学习呀！

eygle

最初由 halbert 发布
[B]但是oracle 公司的专家建议不要用analyze 分析表。 [/B]

几年前的建议 或是 早期版本的建议了吧

从Oracle9i开始，Oracle的CBO已经值得应用

从Oracle10g开始，Oracle缺省的优化器应经变成了ALL_ROWS
而且Oracle不再对RBO提供升级及修正

CBO是必经之路了。


参考:

http://www.itpub.net/showthread.php?s=&threadid=200312

-Eygle

zf_wu

最初由 eygle 发布
[B]然而这不是最快的，这是RBO

我们修改optimizer_index_cost_adj参数，然后奇迹出现了

optimizer_index_cost_adj告诉CBO倾向于使用索引扫描而不是全表扫描的程度，该参数缺省值是１００，就是不左右CBO的判断


SQL> alter session set optimizer_index_cost_adj=30
  2 /

会话已更改。

已用时间: 00: 00: 00.20

SQL> SELECT "SP_TRANS"."TRANS_NO",
  2 "SP_TRANS_SUB"."ITEM_CODE",
  3 "SP_ITEM"."ITEM_NAME",
  4 "SP_ITEM"."CHART_ID",
  5 "SP_ITEM"."SPECIFICATION",
  6 "SP_TRANS_SUB"."COUNTRY",
  7 "SP_TRANS_SUB"."QTY",
  8 "SP_TRANS_SUB"."PRICE",
  9 "SP_TRANS"."VENDOR_CODE",
10 "SP_TRANS"."PAY_MODE",
11 NVL("SP_TRANS_SUB"."PAY_QTY",0),
12 0 as PAY_THIS
13 FROM "SP_TRANS",
14 "SP_ITEM",
15 "SP_TRANS_SUB"
16 WHERE ( "SP_TRANS_SUB"."TRANS_NO" = "SP_TRANS"."TRANS_NO" ) and
17 ( "SP_ITEM"."ITEM_CODE" = "SP_TRANS_SUB"."ITEM_CODE" ) and
18 ( ( "SP_TRANS"."VENDOR_CODE" = '20011021023') )
19 /

已选择8行。

已用时间: 00: 00: 00.11

Execution Plan
----------------------------------------------------------
   0 SELECT STATEMENT Optimizer=CHOOSE (Cost=658 Card=1095 Bytes= 102930)

   1 0 NESTED LOOPS (Cost=658 Card=1095 Bytes=102930)
   2 1 NESTED LOOPS (Cost=329 Card=1095 Bytes=61320)
   3 2 TABLE ACCESS (BY INDEX ROWID) OF 'SP_TRANS' (Cost=1 Card=273 Bytes=7098)
   4 3 INDEX (RANGE SCAN) OF 'IDX_VENDOR' (NON-UNIQUE) (Cost=1 Card=273)
   5 2 TABLE ACCESS (BY INDEX ROWID) OF 'SP_TRANS_SUB' (Cost= 2 Card=135502 Bytes=4065060)
   6 5 INDEX (RANGE SCAN) OF 'PK_SP_TRANS_SUB' (UNIQUE) (Cost=3 Card=135502)
   7 1 TABLE ACCESS (BY INDEX ROWID) OF 'SP_ITEM' (Cost=1 Card=29547 Bytes=1122786)
   8 7 INDEX (UNIQUE SCAN) OF 'PK_SP_ITEM' (UNIQUE)

Statistics
----------------------------------------------------------
          0 recursive calls
          0 db block gets
         49 consistent gets
          0 physical reads
          0 redo size
       1809 bytes sent via SQL*Net to client
        426 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          8 rows processed

SQL> [/B]

eygle:
      从上面可以看出修改optimizer_index_cost_adj参数得到的执行计划与/*+rule*/是一样的.那么就奇怪了?难道一样的执行计划,执行的代价和速度还不一样吗? 我觉得应该一样.这里的不一样只是偶然的.

eygle

最初由 zf_wu 发布
[B]
eygle:
      从上面可以看出修改optimizer_index_cost_adj参数得到的执行计划与/*+rule*/是一样的.那么就奇怪了?难道一样的执行计划,执行的代价和速度还不一样吗? 我觉得应该一样.这里的不一样只是偶然的. [/B]

不一样的，你仔细看看