ITPub博客

首页 > Linux操作系统 > Linux操作系统 > CBO与RBO的基本概念

CBO与RBO的基本概念

原创 Linux操作系统 作者:tyoodz 时间:2011-12-06 15:32:14 0 删除 编辑

RBO的执行机制非常简单,就是在优化器内置制订了一些规则,执行SQL时按照这些规则执行就可以了。比如,如果谓词上有索引就会选择走索引。

ty@BBK10G> drop table t;

Table dropped.

ty@BBK10G> create table t as select 100 id, object_name from dba_objects;

Table created.

ty@BBK10G> update t set id = 99 where rownum < 2;

1 row updated.

ty@BBK10G> select id, count(*) from t group by id;

        ID   COUNT(*)
---------- ----------
       100      51135  --数据分布非常不均匀
        99          1

ty@BBK10G> set autot trace exp stat
ty@BBK10G> create index t_idx on t (id);

Index created.

ty@BBK10G> BEGIN
    dbms_stats.gather_table_stats(
    ownname          => user,
    tabname          => 'T',
    estimate_percent => 100,
    method_opt       => 'for all columns size skewonly',  --收集直方图信息
    cascade          => TRUE
  );
END;
 10  /

PL/SQL procedure successfully completed.

ty@BBK10G> select * from t where id = 100;

51135 rows selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      | 51135 |  1348K|    55   (2)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    | 51135 |  1348K|    55   (2)| 00:00:01 |   --CBO走的是全表扫描
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("ID"=100)

Statistics
----------------------------------------------------------
         54  recursive calls
         23  db block gets
       3629  consistent gets
          0  physical reads
       5224  redo size
    1527163  bytes sent via SQL*Net to client
      37873  bytes received via SQL*Net from client
       3410  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      51135  rows processed
 
 
ty@BBK10G> select /*+ rule*/ * from t where id = 100; --强制优化器选择RBO

51135 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 470836197

---------------------------------------------
| Id  | Operation                   | Name  |
---------------------------------------------
|   0 | SELECT STATEMENT            |       |
|   1 |  TABLE ACCESS BY INDEX ROWID| T     |
|*  2 |   INDEX RANGE SCAN          | T_IDX |  --RBO走的是索引
---------------------------------------------

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

   2 - access("ID"=100)

Note
-----
   - rule based optimizer used (consider using cbo) --提示最要用CBO

Statistics
----------------------------------------------------------
         54  recursive calls
         24  db block gets
       7127  consistent gets  --逻辑读非常大
          0  physical reads
       5192  redo size
    1527233  bytes sent via SQL*Net to client
      37873  bytes received via SQL*Net from client
       3410  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      51135  rows processed
 
可以看出RBO按照了它内置的规则选择了索引。即使表、索引没有被分析也oracle也会选择CBO,因为可以通过动态采样收集一些信息,
上面因为手动收集了信息所以没有出现动态采样。


Oracle的优化器的RBO和CBO方式 
 
 
1、基于规则的优化方式(Rule-Based Optimization,简称为RBO) 
 
    优化器在分析SQL语句时,所遵循的是Oracle内部预定的一些规则,对数据是不敏感的。它只借助少量的信息来决定一个sql语句的执行计划,包括:
    1)sql语句本身
    2)sql中涉及到的table、view、index等的基本信息
    3)本地数据库中数据字典中的信息(远程数据库数据字典信息对RBO是无效的) 
    例如:我们常见的,当一个where子句中的一列有索引时去走索引。但是需要注意,走索引不一定就是优的,比如一个表只有两行数据
,一次IO就可以完成全表的检索,而此时走索引时则需要两次IO,这时全表扫描(full table scan)的效率更优。 
 
 
2、基于代价的优化方式(Cost-Based Optimization,简称为CBO) 
 
    它是看语句的代价(Cost),通过代价引擎来估计每个执行计划所需的代价,该代价将每个执行计划所耗费的资源进行量化,CBO根据这个代价选择出最优的执行计划。
一个查询所耗费的资源可分为三部分:I/O代价、CPU代价、NETWORK代价。I/O是指把数据从磁盘读入内存时所需代价(该代价是查询所需最主要的,所以在优化时一个基本原则就是降低I/O总次数);
CPU代价是指处理内存中数据所需的代价,数据一旦读入内存,当我们识别出我们所要的数据后,会在这些数据上执行排序(sort)或连接(join)操作,这需要消耗CPU资源;对于访问远程节点来说,
network代价的花费也是很大的。 优化器在判断是否用这种方式时,主要参照的是表及索引的统计信息。统计信息给出表的大小、有多少行、每行的长度等信息。这些统计信息起初在库内是没有的,
是做analyze后才出现的,很多的时侯过期统计信息会令优化器做出一个错误的执行计划,因些应及时更新这些信息(dbms_stat.analyze)。 
    如星型连接排列查询,哈希连接查询,函数索引,和并行查询等一些技术都是基于CBD的。 
 
 
3、优化模式包括Rule、Choose、First rows、All rows四种方式: 
 
    Rule:基于规则的方式。 
    Choolse:默认的情况下Oracle用的便是这种方式。指的是当一个表或或索引有统计信息,则走CBO的方式,如果表或索引没统计信息,表又不是特别的小,而且相应的列有索引时,那么就走索引,走RBO的方式。 
    First Rows:它与Choose方式是类似的,所不同的是当一个表有统计信息时,它将是以最快的方式返回查询的最先的几行,从总体上减少了响应时间。 
    All Rows:也就是我们所说的Cost的方式,当一个表有统计信息时,它将以最快的方式返回表的所有的行,从总体上提高查询的吞吐量。没有统计信息则走RBO的方式。 
 
 
4、设定选用哪种优化模式: 
    A、在initSID.ora中设定OPTIMIZER_MODE=RULE/CHOOSE/FIRST_ROWS/ALL_ROWS(默认是Choose)
    B、Sessions级别通过:ALTER SESSION SET OPTIMIZER_MODE=RULE/CHOOSE/FIRST_ROWS/ALL_ROWS
    C、语句级别用Hint(/*+ ... */)来设定 
 
 
5、一些常见的问题: 
 
  A、为什么表的某个字段明明有索引,但执行计划却不走索引? 
    1、优化模式是all_rows的方式 
    2、表作过analyze,有统计信息
    3、表很小,上文提到过的,Oracle的优化器认为不值得走索引。 
 
  B、使用CBO时,SQL语句中为什么不能引用系统数据字典表或视图? 
    1、因为系统数据字典表都未被分析过,可能导致极差的“执行计划”。 
    2、擅自对数据字典表做分析,可能导致死锁,或系统性能严重下降。 
 
  C、使用CBO时如何选择表连接方式? 
    1、CBO有时会偏重于SMJ和HJ,但在OLTP系统中,NL一般会更好,因为它高效的使用了索引。 
    2、SMJ即使相关列上建有索引,最多只能因索引的存在,避免数据排序过程。 
    3、HJ由于须做HASH运算,索引的存在对数据查询速度几乎没有影响。 
 
  D、使用CBO时,需要注意什么吗? 
    1、必须保证为表和相关的索引搜集足够的统计数据, 对数据经常有增、删、改的表最好定期对表和索引进行分析 
    2、可用SQL语句:analyze table xxx compute statistics for all indexes 
 
  E、为什么有时使用CBO会比较慢? 
    1、没有对表或视图进行Analyze 
    2、SQL进行CBO时对于没有Analyze的对象会自动进行Analyze,因此造成运行缓慢 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25361369/viewspace-712806/,如需转载,请注明出处,否则将追究法律责任。

下一篇: Hint Cardinality
请登录后发表评论 登录
全部评论

注册时间:2011-05-16

  • 博文量
    55
  • 访问量
    72509