oracle优化器RBO和CBO
这段时间，别oracle折磨，无语啦，所自己懂oracle，工作中确实经常的用，但是对配置，优化的东西，处在一种朦胧的状态。说不太清，做不太明白，所以，花点时间研究下，并且将看到的内容总结下，看到的别人好文章，就转载过来，谢谢大家
转载自：http://blog.csdn.net/newhappy2008/archive/2009/02/26/3940785.aspx
作者：牛海彬（专家）
Oracle 的优化器 有两种优化方式，即基于规则的优化方式RBO（RULE-BASED OPTIMIZIATION）和基于代价（COST）的优化方式CBO（COST-BASED OPTIMIZATION），在Oracle8及以后的版本，Oracle强烈推荐使用CBO方式。
RBO方式：优化器在分析SQL语句时，所遵循的是Oracle内部预定的一些规则。比如：我们常见的，当一个where子句中的一列有索引的时候去走索引。
CBO方式：他是看语句的代价（COST），这里的代价主要指CPU和内存。优化器在判断是否使用这种方式时，主要参照的是表及索引的统计信息。统计信息给出表的大小、有多少行、每行的长度等信息。这些统计信息起初在库内是没有的，是做analyze之后才出现的，很多时候过期统计信息会令优化器做出一个错误的执行计划，因此应及时更新这些信息。
注意：走索引不一定就是优的，比如一个表，只有两行数据（当然也可以理解为数据量很少）一次IO可以完成全表的检索，而此时走索引时则需要两次IO，此时全表扫描（full table scan）是最好的。
优化模式包括：RULE、CHOOSE、FIRST ROWS、ALL ROWS四种方式。
RULE：基于规则的方式；
CHOOSE:默认的情况下Oracle用的便是这种方式。指的是：指的是当一个表或索引有统计信息，则走CBO方式，如果表或索引没有统计信息，表有特别小，而且相应的列有索引时，那么就走索引，走RBO方式；
FIRST ROWS：它与CHOOSE方式类似，所不同的是，当一个表有统计信息时，它将是以最快的方式返回查询的最先几行，从总体上减少响应时间。
ALL ROWS：也就是我们所的Cost方式，当一个表有统计信息时，他将以最快的方式返回表的所有行，从总体上提高查询的吞吐量。没有统计信息则走RBO的方式。
设定选用哪种优化模式：
1、Instance级别 可以通过在 initSID.ora文件中设定OPTIMIZER_MODE=RULE/CHOOSE/RIRST_ROWS/ALL_ROWS设定，如果没有设定,那么OPTIMIZER_MODE 参数默认的是CHOOSE方式。
2、Sessions 级别通过 ALTER SESSION SET OPTIMIZER_MODE = RULE/CHOSE/FIRST_ROWS/ALL_ROWS 来设定。
3、语句级别用HINT(英文翻译为“提示”)来设定,格式为：（/*+....*/）
为什么表的某个字段明明有索引但是执行计划不走索引：
1、优化模式是 ALL ROWS 的方式
2、表做过analyze，有统计信息
3、表很小，Oracle优化器认为不值得走索引。
下面附一下 Oracle的查询原理：
转载自：http://www.uml.org.cn/sjjm/20100420.asp
原理：
第一步：应用程序把查询SQL语句发给服务器端执行。
我们在数据层执行SQL语句时,应用程序会连接到相应的数据库服务器,把SQL语句发送给服务器处理。
第二步：服务器解析请求的SQL语句。
1:SQL计划缓存,经常用查询分析器的朋友大概都知道这样一个事实,往往一个查询语句在第一次运行的时候需要执行特别长的时间,但是如果你马上或者在一定时间内运行同样的语句,会在很短的时间内返回查询结果。
原因:
1):服务器在接收到查询请求后,并不会马上去数据库查询,而是在数据库中的计划缓存中找是否有相对应的执行计划,如果存在,就直接调用已经编译好的执行计划,节省了执行计划的编译时间。
2):如果所查询的行已经存在于数据缓冲存储区中,就不用查询物理文件了,而是从缓存中取数据,这样从内存中取数据就会比从硬盘上读取数据快很多,提高了查询效率.数据缓冲存储区会在后面提到。
2:如果在SQL计划缓存中没有对应的执行计划,服务器首先会对用户请求的SQL语句进行语法效验,如果有语法错误,服务器会结束查询操作,并用返回相应的错误信息给调用它的应用程序。
注意:此时返回的错误信息中,只会包含基本的语法错误信息,例如select 写成selec等,错误信息中如果包含一列表中本没有的列,此时服务器是不会检查出来的,因为只是语法验证,语义是否正确放在下一步进行。
3:语法符合后,就开始验证它的语义是否正确,例如,表名,列名,存储过程等等数据库对象是否真正存在,如果发现有不存在的,就会报错给应用程序,同时结束查询。
4:接下来就是获得对象的解析锁,我们在查询一个表时,首先服务器会对这个对象加锁,这是为了保证数据的统一性,如果不加锁,此时有数据插入,但因为没有加锁的原因,查询已经将这条记录读入,而有的插入会因为事务的失败会回滚,就会形成脏读的现象。
5:接下来就是对数据库用户权限的验证,SQL语句语法,语义都正确,此时并不一定能够得到查询结果,如果数据库用户没有相应的访问权限,服务器会报出权限不足的错误给应用程序,在稍大的项目中,往往一个项目里面会包含好几个数据库连接串,这些数据库用户具有不同的权限,有的是只读权限,有的是只写权限,有的是可读可写,根据不同的操作选取不同的用户来执行,稍微不注意,无论你的SQL语句写的多么完善,完美无缺都没用。
6:解析的最后一步,就是确定最终的执行计划。当语法,语义,权限都验证后,服务器并不会马上给你返回结果,而是会针对你的SQL进行优化,选择不同的查询算法以最高效的形式返回给应用程序。例如在做表联合查询时,服务器会根据开销成本来最终决定采用hash join,merge join ,还是loop join,采用哪一个索引会更高效等等,不过它的自动化优化是有限的,要想写出高效的查询SQL还是要优化自己的SQL查询语句。
当确定好执行计划后,就会把这个执行计划保存到SQL计划缓存中,下次在有相同的执行请求时,就直接从计划缓存中取,避免重新编译执行计划。
第三步：语句执行。
服务器对SQL语句解析完成后,服务器才会知道这条语句到底表态了什么意思,接下来才会真正的执行SQL语句。
此时分两种情况:
1):如果查询语句所包含的数据行已经读取到数据缓冲存储区的话,服务器会直接从数据缓冲存储区中读取数据返回给应用程序,避免了从物理文件中读取,提高查询速度。
2):如果数据行没有在数据缓冲存储区中,则会从物理文件中读取记录返回给应用程序,同时把数据行写入数据缓冲存储区中,供下次使用。
转载自：http://blog.csdn.net/newhappy2008/archive/2009/02/26/3940785.aspx
作者：牛海彬（专家）
Oracle 的优化器 有两种优化方式，即基于规则的优化方式RBO（RULE-BASED OPTIMIZIATION）和基于代价（COST）的优化方式CBO（COST-BASED OPTIMIZATION），在Oracle8及以后的版本，Oracle强烈推荐使用CBO方式。
RBO方式：优化器在分析SQL语句时，所遵循的是Oracle内部预定的一些规则。比如：我们常见的，当一个where子句中的一列有索引的时候去走索引。
CBO方式：他是看语句的代价（COST），这里的代价主要指CPU和内存。优化器在判断是否使用这种方式时，主要参照的是表及索引的统计信息。统计信息给出表的大小、有多少行、每行的长度等信息。这些统计信息起初在库内是没有的，是做analyze之后才出现的，很多时候过期统计信息会令优化器做出一个错误的执行计划，因此应及时更新这些信息。
注意：走索引不一定就是优的，比如一个表，只有两行数据（当然也可以理解为数据量很少）一次IO可以完成全表的检索，而此时走索引时则需要两次IO，此时全表扫描（full table scan）是最好的。
优化模式包括：RULE、CHOOSE、FIRST ROWS、ALL ROWS四种方式。
RULE：基于规则的方式；
CHOOSE:默认的情况下Oracle用的便是这种方式。指的是：指的是当一个表或索引有统计信息，则走CBO方式，如果表或索引没有统计信息，表有特别小，而且相应的列有索引时，那么就走索引，走RBO方式；
FIRST ROWS：它与CHOOSE方式类似，所不同的是，当一个表有统计信息时，它将是以最快的方式返回查询的最先几行，从总体上减少响应时间。
ALL ROWS：也就是我们所的Cost方式，当一个表有统计信息时，他将以最快的方式返回表的所有行，从总体上提高查询的吞吐量。没有统计信息则走RBO的方式。
设定选用哪种优化模式：
1、Instance级别 可以通过在 initSID.ora文件中设定OPTIMIZER_MODE=RULE/CHOOSE/RIRST_ROWS/ALL_ROWS设定，如果没有设定,那么OPTIMIZER_MODE 参数默认的是CHOOSE方式。
2、Sessions 级别通过 ALTER SESSION SET OPTIMIZER_MODE = RULE/CHOSE/FIRST_ROWS/ALL_ROWS 来设定。
3、语句级别用HINT(英文翻译为“提示”)来设定,格式为：（/*+....*/）
为什么表的某个字段明明有索引但是执行计划不走索引：
1、优化模式是 ALL ROWS 的方式
2、表做过analyze，有统计信息
3、表很小，Oracle优化器认为不值得走索引。
下面附一下 Oracle的查询原理：
转载自：http://www.uml.org.cn/sjjm/20100420.asp
原理：
第一步：应用程序把查询SQL语句发给服务器端执行。
我们在数据层执行SQL语句时,应用程序会连接到相应的数据库服务器,把SQL语句发送给服务器处理。
第二步：服务器解析请求的SQL语句。
1:SQL计划缓存,经常用查询分析器的朋友大概都知道这样一个事实,往往一个查询语句在第一次运行的时候需要执行特别长的时间,但是如果你马上或者在一定时间内运行同样的语句,会在很短的时间内返回查询结果。
原因:
1):服务器在接收到查询请求后,并不会马上去数据库查询,而是在数据库中的计划缓存中找是否有相对应的执行计划,如果存在,就直接调用已经编译好的执行计划,节省了执行计划的编译时间。
2):如果所查询的行已经存在于数据缓冲存储区中,就不用查询物理文件了,而是从缓存中取数据,这样从内存中取数据就会比从硬盘上读取数据快很多,提高了查询效率.数据缓冲存储区会在后面提到。
2:如果在SQL计划缓存中没有对应的执行计划,服务器首先会对用户请求的SQL语句进行语法效验,如果有语法错误,服务器会结束查询操作,并用返回相应的错误信息给调用它的应用程序。
注意:此时返回的错误信息中,只会包含基本的语法错误信息,例如select 写成selec等,错误信息中如果包含一列表中本没有的列,此时服务器是不会检查出来的,因为只是语法验证,语义是否正确放在下一步进行。
3:语法符合后,就开始验证它的语义是否正确,例如,表名,列名,存储过程等等数据库对象是否真正存在,如果发现有不存在的,就会报错给应用程序,同时结束查询。
4:接下来就是获得对象的解析锁,我们在查询一个表时,首先服务器会对这个对象加锁,这是为了保证数据的统一性,如果不加锁,此时有数据插入,但因为没有加锁的原因,查询已经将这条记录读入,而有的插入会因为事务的失败会回滚,就会形成脏读的现象。
5:接下来就是对数据库用户权限的验证,SQL语句语法,语义都正确,此时并不一定能够得到查询结果,如果数据库用户没有相应的访问权限,服务器会报出权限不足的错误给应用程序,在稍大的项目中,往往一个项目里面会包含好几个数据库连接串,这些数据库用户具有不同的权限,有的是只读权限,有的是只写权限,有的是可读可写,根据不同的操作选取不同的用户来执行,稍微不注意,无论你的SQL语句写的多么完善,完美无缺都没用。
6:解析的最后一步,就是确定最终的执行计划。当语法,语义,权限都验证后,服务器并不会马上给你返回结果,而是会针对你的SQL进行优化,选择不同的查询算法以最高效的形式返回给应用程序。例如在做表联合查询时,服务器会根据开销成本来最终决定采用hash join,merge join ,还是loop join,采用哪一个索引会更高效等等,不过它的自动化优化是有限的,要想写出高效的查询SQL还是要优化自己的SQL查询语句。
当确定好执行计划后,就会把这个执行计划保存到SQL计划缓存中,下次在有相同的执行请求时,就直接从计划缓存中取,避免重新编译执行计划。
第三步：语句执行。
服务器对SQL语句解析完成后,服务器才会知道这条语句到底表态了什么意思,接下来才会真正的执行SQL语句。
此时分两种情况:
1):如果查询语句所包含的数据行已经读取到数据缓冲存储区的话,服务器会直接从数据缓冲存储区中读取数据返回给应用程序,避免了从物理文件中读取,提高查询速度。
2):如果数据行没有在数据缓冲存储区中,则会从物理文件中读取记录返回给应用程序,同时把数据行写入数据缓冲存储区中,供下次使用。