oracle 10G和oracle 9i的optimizer_index_cost_adj参数的区别

最近公司买了一台新的服务器，用来做质量采集系统的主服务器，我就在这台新机器上安装了oralce 10g release 2
，把数据从9i老数据库上导出来，然后导入到10g里面。导入 完后，正常启动服务后，一查询，发现速度奇慢无比，原以为数据库刚刚启动，sga区还没有充满，也就没有去管它。一周后，质量分析人员报告，自从换到新数据库后，查询几乎查询不出来，查询都要几个小时。于是登陆进服务器，察看占用时间最长的sql，把这个sql拷出来到老数据库下查询，很快就查询了。我察看了两个数据库的参数，基本一致。 见鬼了，为什么时间相差这么久，
我决定看看这个语句在两个数据库下的执行计划， 发现在9i下sql走的是索引，在10g下走的是全表扫描。晕死，原来区别在这里，现在数据库中数据达到16亿条，走全表扫描还不要人命。在sqlplus下连接到10g数据库下
sql  〉show parameter opt
 NAME                                 TYPE        VA
------------------------------------ ----------- --
filesystemio_options                 string
object_cache_optimal_size            integer     10
optimizer_dynamic_sampling           integer     2
optimizer_features_enable            string      10
optimizer_index_caching              integer     0
optimizer_index_cost_adj             integer     100
optimizer_mode                       string      AL
optimizer_secure_view_merging        boolean     TR
plsql_optimize_level                 integer     2
看到optimizer_index_cost_adj =100，记得上次看到eygle的一个文章里说一般10g里面的oltp系统这个参数设为50左右，
sql 〉alter session set optimizer_index_cost_adj   =  50
在执行一下sql，看执行计划，发现走索引了 。
不过我又回去看9i的optimizer_index_cost_adj 参数，发现他的值是默认的100，
我想10g的系统的执行计划方面算法应该做了大的改动，这个默认的optimizer_index_cost_adj 的100数值不再适合于大数据量的查询了，在默认下，大数据量表会偏向走全表扫描，所以如果是大数据量的oltp系统，安装完毕后记得吧optimizer_index_cost_adj改小