Oracle优化器的RBO和CBO方式

[/size]

Or[size=large][size=small]acle优化器的RBO和CBO方式[/size]

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，因此造成运行缓慢




更加详细的信息可见以下转载：
******************************************************************
http://gzzg.itpub.net/post/88/4521

CBO 和 RBO
gzzg | 10 十一月, 2004 10:16

选择获取路径（access path）
1 基于成本（Cost-Based）
优化器会根据这些因素来选择获取路径：
◎语句的可用的获取路径
◎估计每个获取路径的成本

选择获取路径（access path）
1 基于成本（Cost-Based）
优化器会根据这些因素来选择获取路径：
◎语句的可用的获取路径
◎估计每个获取路径的成本
优化器第一步会根据 where 子句的条件（和对有 sample 或者 sample block 的 from 子句）得到可利用的获取路径。然后优化器生成执行计划，并根据索引、列和表的统计信息估计每个计划的成本。最后，优化器选择一个成本最低的执行计划。
如果有提示（hints）存在的话，那么会覆盖优化器的路径选择，当语句中有 sample 或 sample block 除外。
选择可利用的获取路径，优化器考虑以下的因素：
◎选择性(Selectivity)：就是查询一个表返回的列的百分比。低百分比查询的选择性要比高百分比的好。对于返回查询结果占表的行数比例比较小的话，使用索引是有效率的，如果比例较大的话，全表扫描会更快一些。为了确定查询的选择性，优化器考虑这些信息：
※ where 子句中使用的操作符
※ where 子句中使用的唯一键和主键
※ 表的统计信息
◎DB_FILE_MULTIBLOCK_READ_COUNT 参数：全表扫描使用多块读（multiblock read），所以全表扫描的成本取决于一个多块读一次读取的块的数量。因此，当 DB_FILE_MULTIBLOCK_READ_COUNT 参数设置的比较大，那么优化器选择全表扫描的可能性也就比较大。
一个例子：
SELECT *
  FROM emp
  WHERE ename = 'JACKSON';
  如果 ename 是一个唯一性键或是主键，优化器很可能就会使用 unique scan on index 来使用索引。
  如果 ename 不是一个唯一性键或是主键，那么优化器就会使用下面的统计信息：
  USER_TAB_COLUMNS.NUM_DISTINCT  表的每一列的数值的数量
  USER_TABLES.NUM_ROWS 表的行数
 
2 基于规则（Rule-Based）
优化器会根据这些因素来选择获取路径：
◎语句的可用的获取路径
◎获取路径的级别
优化器第一步会根据 where 子句的条件得到可利用的获取路径，然后选择最高级别的获取路径。
全表扫描是最低级别的获取路径，这就意味着再基于规则的优化器如果有索引可以利用，即使全表扫描更有效率，也不会使用全表扫描。
Where 子句中的条件的顺序不影响优化器的选择。

获取路径的级别（常用）：
1     Single row by rowid  
4     Single row by unique or primary key  
8     Composite key  
9     Single-column indexes  
10   Bounded range search on indexed columns  
11   Unbounded range search on indexed columns  
12   Sort-merge join  
13   MAX or MIN of indexed column  
14   ORDER BY on indexed columns  
15   Full table scan 

Single-column indexes   ：当 Where 子句的等于条件中有一个或者多个单列索引（多个条件必须用 AND 连接）时，查询会使用 Single-column indexes 。如果 Where 子句中只用到有索引的列，Oracle 会在这个索引上执行一个 range scan 获得被选择的行的 rowids ，然后通过这些 rowids 来获得表中的行。如果 where 子句中有多个 Single-column indexes 的列，Oracle 会在每个索引上执行 range scan ，然后将这些返回的 rowids 的集合进行合并，最后再通过这些合并后的 rowids 的集合来获取表中的行。Oracle 最多可以合并 5 个索引，如果 where 子句中使用的Single-column indexes 超过 5 个，那么 Oracle 就先合并 5 个得到一个 rowids 的集合，通过这个 rowids 集合来获取表中的行，再判断这些行是否符合剩下的条件。

Bounded range search on indexed columns   ：在 where 子句中有以下条件时（既有上限也有下限）
column = expr
column >[=] expr AND column <[=] expr
column BETWEEN expr AND expr
column LIKE 'c%'

Unbounded range search on indexed columns  ：在 where 子句中有以下条件时（只有上限或者只有下限）
WHERE column >[=] expr
WHERE column <[=] expr

Sort-merge join  ：如这样的语句
SELECT *
    FROM emp, dept
    WHERE emp.deptno = dept.deptno;
   
优化模式、计划的稳定性和提示
◎使用 Cost-based 优化器
为了使用 CBO ，需要收集统计信息和启用 CBO 。启用 CBO 有以下集中方法：
确定 OPTIMIZER_MODE  初始化参数被设置为 CHOOSE ；
可以用有 ALL_ROWS 或者 FIRST_ROWS 选项的  ALTER SESSION SET OPTIMIZER_MODE 语句来使当前的 session 使用 CBO ；
在 sql 语句中使用除了 RULE 的任意提示；
确定 CBO 的目标：是要 best throughput （吞吐量）还是 best reponse time（反应时间） ?
举一个例子来说，一个联合语句可以 nested loop 执行，也可以 sort-merge 执行，sort-merge 执行会返回整个查询结果比较快，而 sort-merge 则返回第一行比较快。所以就看你的目的是什么，是要好的吞吐量还是好的发应时间。
选择 CBO 的目标取决于应用的需要：
※ 对于应用程序执行批量处理，例如 Oracle Reports ，用户只关心最终的处理结果，发应时间就不是很重要了；
※ 对于交互式的应用，比如 Oracle Forms 应用或者 SQL*Plus 查询，反映时间就比较重要了；
※ 对于使用 rownum 的查询语句，反映时间就是优化的目标了。
Oracle 系统默认吞吐量好 （best throughput）为 CBO 的优化目标，但你可以通过以下的方式改变系统的默认设置：
※ 在 session 级别用 ALTER SESSION SET OPTIMIZER_MODE ＝ FIRST_ROWS
※ 以 statement 级别用 first_rows 提示
※ 可以在 instance 级别修改初始化参数 OPTIMIZER_MODE
使用柱状图来描述不平均分布的数据
对平均分布的数据来说，优化器不需要柱状图来估计查询的成本。但对不平均分布的数据来说，Oracle 允许你创建描述某一特定列的数据分布的柱状图，Oracle 将这些柱状图存储在数据字典中提供给 CBO 来使用。柱状图是永久存在的对象，所以它们占用空间并需要维护，和所有的优化统计信息一样，Oracle 用来建立柱状图的统计信息都是静态的。如果一个列的数据分布变化频繁，那么就需要重新统计。在以下的情况下，列的柱状图是无效的：
※ All predicates on the column use bind variables;
※ 列中的数据是均匀分布的；
※ 列没有在 where 子句中被使用；
※ 列中的数据都是唯一的，并只使用在等于操作中；
创建柱状图
要为那些在 where 子句中频繁使用并且数据分布很不均匀的列创建柱状图。包 DBMS_STATS 的存储过程GATHER_TABLE_STATS 可以用来创建柱状图。例如，为 emp 表中的 sal 列创建10柱的柱状图：
EXECUTE DBMS_STATS.GATHER_TABLE_STATS
   ('scott','emp', METHOD_OPT => 'FOR COLUMNS SIZE 10 sal');
统计信息在这些视图中可以查找到   USER_TAB_COLUMNS, ALL_TAB_COLUMNS, and DBA_TAB_COLUMNS ，
柱状图的信息可以查询这些视图：USER_HISTOGRAMS, DBA_HISTOGRAMS, 和 ALL_HISTOGRAMS.
确定柱状图的柱的数量（采样的比率）：柱状图默认的柱的数量的75，这个值对大多数数据分布来说应该是合适的。当然，柱的数量和数据的分布都影响柱状图的可用性，你可以用不同数量的柱进行测试以获得最优的结果。

◎生成统计信息
因为 CBO 依赖从表、簇和索引中得到的统计信息，如果数据的尺寸和分布变化频繁，那么就要定期地对更新统计信息，以精确地反映数据。Oracle 可以通过以下的技术来产生统计信息：
※ 随机采样估计
※ 精确计算
※ 用户定义的统计方法
由于计算统计信息需要时间和空间，所以经常使用估计而不是计算，除非你想要精确的数据，理由如下：
※ 精确计算总是能提供精确的数值，但需要花费更多的时间。计算一个表的统计信息所需要的时间相当于进行一个全表扫描和排序的所花费的时间。
※ 对于大表来说，大致估计比精确计算要快的多。
为了进行一个精确的计算，Oracle 需要足够的空间去执行扫描和排序。如果内存中没有足够的空间，那么就需要临时空间。但对索引来说，精确计算不需要占用那么多的空间和时间，所以索引比较适合用来做精确计算。当你为一个表、一个列或者索引生成了统计信息，如果数据字典中已经存在这些对象的统计信息，那么Oracle 会更新这些统计信息，并且使访问这些对象的分析过的 sql 语句无效。这样下次这些语句再执行，优化器就会自动地根据新的统计信息选择一个新的执行计划。
通过 DBMS_STATS 包来收集统计信息：DBMS_STATS 提供以下的存储过程来收集统计信息。
GATHER_ INDEX_STATS   收集索引的统计信息
GATHER_TABLE_STATS    收集表、列和索引的统计信息
GATHER_SCHEMA_STATS   收集模式中的所有对象的信息
GATHER_DATABASE_STATS  收集数据库中的所有对象的统计信息
收集新的优化器的统计信息：Oracle 建议通过下面的方法来为特定的模式收集新的统计信息。
在收集新的统计信息之前，可以使用 DBMS_STATS.EXPORT_SCHEMA_STATS 去保存原有的统计信息，然后用DBMS_STATS.GATHER_SCHEMA_STATS 来收集新的统计信息。当然，你可以完成用一个存储过程 GATHER_SCHEMA_STATS 来完成上述两个功能。
如果发现关键的 sql 语句的执行性能有很大程度的降低，可以用更大的样本来重新统计，或者用 DBMS_STATS.IMPORT_SCHEMA_STATS 来恢复以前的统计信息。
也许你发现新的统计使大部分的 sql 语句提高了性能，有问题的 sql 语句的数量很少，那么可以这样做：
1. 用旧的统计信息为有问题的 sql 语句创建一个存储大纲；
2. 使用 DBMS_STATS.IMPORT_SCHEMA_STATS 来恢复新的统计信息；
3. 这样的应用程序就会使用新的统计信息来执行 sql 语句，另外，你的那些有问题的 sql 语句还可以获得以前的执行性能。

◎统计信息的自动收集
这个特性使你能自动地收集统计信息，你也可以建立有失效统计信息的表的列表或者创建没有统计信息的表的列表。这就要使用 GATHER_SCHEMA_STATS 和 GATHER_DATABASE_STATS 过程中的 options 和 objlist 参数。
影响 CBO 执行计划的初始化参数：
OPTIMIZER_FEATURES_ENABLED 
OPTIMIZER_MODE 
OPTIMIZER_PERCENT_PARALLEL 
HASH_AREA_SIZE 
SORT_AREA_SIZE 
DB_FILE_MULTIBLOCK_READ_COUNT 
在数据仓库中使用下列参数：
ALWAYS_ANTI_JOIN 
HASH_JOIN_ENABLED 
下列参数很少需要改动：
HASH_MULTIBLOCK_IO_COUNT 
OPTIMIZER_SEARCH_LIMIT 
BITMAP_MERGE_AREA_SIZE 
下列参数影响索引的使用：
OPTIMIZER_INDEX_COST_ADJ
OPTIMIZER_INDEX_CACHING

CBO 的点滴
※ 大缓存系统的查询计划：如果 CBO 的执行计划是在多用户，缓存命中率很低的的情况下运行的很好，但在单用户，缓存命中率高的情况下就不一定运行的好。反过来也一样。
※ 在分析表之前分析索引：分析表所占用的系统资源要比分析索引多的多，因此，将表的分析和索引的分析分开将是非常有利的。
※  尽可能产生统计信息：使用提示会激发 CBO 优化器。由于 CBO 优化器是独立于统计信息的。所以对那些有提示的语句中引用的表进行统计是非常有必要的，即使系统默认的优化器是 RBO .
※ 为用户自定义的结构提供统计信息的收集，选择，和成本计算。

◎使用 Rule-Based 优化器
Oracle 也支持使用 RBO ，但你在设计新的应用使，应该使用 CBO ，在数据仓库应用中，尤其如此，因为 CBO 对DSS 系统增加了很多特性。这些增强的特性，比如 hash joins, improved star query processing, and histograms 只在 CBO 中有效。
如果你在 Oracle 6 中开发了 OLTP 应用并对 sql 的执行按照 RBO 进行了优化，那么在将应用升级到更高版本的 Oracle 中时，你可以继续使用 RBO 。
如果你既没有收集统计信息，也没有在你的 sql 语句中使用提示，那么你的语句就会使用 RBO 。当然最终你必须地将你目前的应用移植到 CBO 中，因为，Oracle 服务器会最终不支持 RBO 。
如果你的应用是第三方开发的，那么要和开发商讨论决定使用什么优化器最适合你的应用。
你可以通过收集统计信息来 Oracle 使用 CBO 优化器，也可以通过删除统计信息来转而使用 RBO 优化器。或者在初始化参数中设置 OPTIMIZER_MODE ，或者用 alter session 命令来确定是使用 CBO 还是使用 RBO 。

◎使用计划的稳定性（Plan Stability）来保护执行计划
计划稳定性能够使你的应用在数据库环境发生变化而受到影响。数据库环境的变化包括优化模式的变化，诸如 SORT_AREA_SIZE 和 BITMAP_MERGE_AREA_SIZE 等影响内存结构的参数的变化。当你的应用的性能不能冒风险的时候，计划稳定性是非常有用的。
计划稳定性用存储大纲来保存执行计划。Oracle 可以为一个或所有的 sql 语句创建存储大纲。当你使用存储大纲时，优化器可以从大纲中生成等同的执行计划。
保存在存储大纲中的计划会保持不变，即使你的系统配置或统计信息发生了改变。由于在后来的 Oracle  版本中优化器发生了改变，存储大纲也能稳定地生成执行计划。你可以将大纲分组成类并对类别进行控制，以简化大纲的管理和配置。
计划稳定性也可以使得从 RBO 到 CBO 的移植更容易，当你升级你的 Oracle 的版本时。
计划稳定性使用提示和精确文本匹配
Oracle 用提示来记录存储计划，计划稳定性也依赖查询的精确文本匹配，以确定查询是否有存储大纲。
相似的 sql 语句可以共享存储大纲，当然，在 sql 语句和存储大纲之间时一对一的关系。语句上数值的不同，就会导致使用不同的存储大纲。为了避免这个问题，用帮定变量来替代具体的数值。
计划稳定性依赖于性能比较满意时刻的存储的执行计划。在很多环境中，诸如 dates 和 order numbers 之类的数据类型经常会发生变化。在这些情况下，当数据特征发生大的变化时，还持久地使用存储计划会降低系统的性能。这就暗示着计划稳定性和 CBO 有某种程度上时相反的。CBO 总是试图在基于精确反映数据的状态的前提下产生执行计划。因此，你必须权衡控制使用计划稳定性。
大纲是如何使用提示的？
一个大纲主要由一组提示组成，就相当于优化器为特定的 sql 语句生成的执行计划。当 Oracle 创建了大纲，计划稳定性使用那些产生执行计划的相同数据来检查优化结果。也就是说，Oracle 使用执行计划的输入来产生一个大纲，而不是执行计划本身。
你不能修改一个大纲。你可以在 sql 语句种嵌入提示，但这对 Oracle 如何使用大纲是没有影响的，因为 Oracle 会将修改提示的 sql 语句看成是和存储在大纲种不同的 sql 语句。
将大纲和 sql 语句匹配
当编译 sql 语句并将他们和大纲匹配时，使用下面两种方案种的一种。第一种方案就是，如果你通过设置系统或会话的USE_STORED_OUTLINES 参数为 false。这样 Oracle 就不会试图将 sql 语句和大纲进行匹配。第二种方案包含以下两个匹配步骤：
第一，如果你制定 Oracle 必须使用一个特定类的大纲，那么只用那个类种的大纲才能成为匹配的候选；第二，如果 sql 语句的文本和大纲种的文本精确匹配，那么 Oracle 认为这两个文本时一致的，并使用这个大纲。如果有任何的不同，比如空格不同，回车换行的变化，内嵌的提示的不同，甚至注释的不同，就不会进行匹配。
Oracle 如何存储大纲？
Oracle 在 OL$ 表大纲数据，在 OL$HINTS 存储提示数据。除非你删除他们，否则 Oracle 会保留这些大纲。Oracle 将执行计划保留再缓存中，如果没有足够的空间保留他们就需要重新创建。
下面几个初始化参数可以启用大纲
QUERY_REWRITE_ENABLED
STAR_TRANSFORMATION_ENABLED
OPTIMIZER_FEATURES_ENABLE

◎创建大纲
Oracle 可以自动地为所有的 sql 语句创建大纲，或者你可以为一个特定的 sql 语句创建大纲。不管是哪一种情况，大纲可以从 RBO 中获得输入，也可以从 CBO 中获得。
当你将参数 CREATE_STORED_OUTLINES 设置为 TRUE，那么 Oracle 就会自动地创建存储大纲。一旦被激活，Oracle 就会为所有的执行的 sql 语句创建大纲。你也可以使用 CREATE OUTLINE 来为特定的 sql 语句创建存储大纲。
为存储大纲创建和指定类别
你可以创建大纲类别，并将一些存储大纲指定给它。这会给管理一组存储大纲带来方便。
参数 CREATE_STORED_OUTLINES 和 CREATE OUTLINE 语句都接受类别的名称，在这两种钱情况下，如果你在其中指定一个类别的名称，Oracle 会将所有后来创建的存储大纲指定到这个类别中，除非重新设置这个类别的名称或者将参数CREATE_STORED_OUTLINES 设置为 FALSE。
如果你在参数 CREATE_STORED_OUTLINES 和 CREATE OUTLINE 语句中都没有指定类别的名称，Oracle 会将大纲指定为 DEFALT 的类别中。
使用存储大纲
指定的存储大纲只对有大纲的 sql 语句的编译进行控制，如果你将参数 USE_STORED_OUTLINES to FALSE 设置为 FALSE ，Oracle 就不会使用存储大纲。当你将 USE_STORED_OUTLINES 设置为 FALSE ，而将CREATE_STORED_OUTLINES 设置为 TRUE，Oracle 会创建存储大纲，但不会使用它们。当你激活存储大纲时，Oracle 总是使用 CBO ，这是因为大纲依赖于提示。
你可以通过这两个数据字典 USER_OUTLINES，USER_OUTLINE_HINTS  来查看查看大纲。

◎用 outln_pkg 包来管理概要
包 outln_pkg 有下面三个存储过程：drop_unused, drop_by_cat, update_by_cat
移动大纲表：
Oracle 利用 OL$ 和 OL$HINTS 表创建了视图 USER_OUTLINES 和 USER_OUTLINE_HINTS ，Oracle 在 sys 表空间中使用模式 OUTLN 创建了这些表。如果大纲在 sys 表空间中使用了太多的空间，你可以将它们移到另外的表空间中去。


◎使用提示
作为一个程序设计者，你可能知道一些优化器不知道的信息，例如，你知道某个索引对某中查询特别有效。基于这种信息，你可以选择一个比优化器更为有效的执行计划，这就是提示。你可以勇提示来说明：
※ sql 的优化路径
※ sql 的基于成本的路径的目标
※ 从表中获取数据的路径
※ 合并语句的合并顺序
※ 合并语句中的合并操作
说明提示，你可以在以下三种语句中使用提示：简单的 select , update, 或 delete 语句中，一个复杂查询中的父句或者子句部分，复合查询中的一部分（由 union 连接的 ）。
一个语句块只能有一个包含提示的注释，注释只能跟在 select, update, 或者 delete 关键词的后面，有两种形式：
select  /*+ hint text */
select - - + hint text
加号就会使得 Oracle 将注释翻译为一系列的提示，加号必须紧跟在注释符的后面，不可以存在空格。如果注释中包含多个提示，那么提示之间必须至少用一个空格分隔开。如果提示表示的不正确，那么 Oracle 会忽略但不返回错误。

决定优化路径和目标的提示：ALL_ROWS, FIRST_ROWS, CHOOSE, RULE 如果在 sql 语句中使用了决定优化路径和目标的提示，那么优化器会忽略统计信息的存在，初始化参数 OPTIMIZER_MODE 的值和 alter session 语句对 OPTIMIZER_MODE 的设置。
决定获取方法的提示：FULL, ROWID, HASH ...
决定合并操作的提示：USE_NL, USE_MERGE, USE_HASH, ...
决定并行执行的提示：PARALLEL , NOPARALLEL , PQ_DISTRIBUTE , APPEND ...
其他提示：CACHE ，NOCACHE ，MERGE ，NO_MERGE
******************************************************************

分享到：

Oracle优化器和索引原 | Oracle 优化器详解

• 2012-07-13 00:25
• 浏览 2403
• 评论(0)
• 分类:数据库
• 查看更多