ORACLE 版本升级问题

1.升级时候一定要明确，对于使用analyze table的时候会分析索引信息的，但是dbms_stats不会。

2.oracle 10g method_opt的默认值为for all columns size auto，那么我们可能会得到错误的直方图信息。

3.oracle 10g会自动创建一个job每24小时没有统计信息或者统计信息过期的表进行统计。

4.oracle 中dbms_status中的一些设计原则，对于index  的的采样得到的leaf block 小于919时候，可能会得到一个不够优化的执行计划，在metalink 上说在9.2.0.3上该问题已经fix了，但还需要确认。

5.对于ORACLE 10G的系统统计中有的时候会使用强行启用一些系统的CPU成本计算，这回严重影响表扫描的成本。当然有的时候需要采用CPU COST的收集，但仍然需要严格测试，比如我们的OLTP系统在白天和夜晚对CPU的使用时不同的，我们可以将白天的负载和晚上的负载存放在stats表中，然后写一个job import相关的统计信息，以满足需要。但是如果我们并不需要这些系统统计信息，可以执行delete 相关aux_status$这张表的相关记录，使用相关的dbms_stats.delete_sys_stats并不起作用。

6.可以使用optimizer_index_cost_adj可以按比例驱动索引单块读的成本。

7.and_equal在ORACLE 9I和10G的默认行为中已经废除，如果想继续使用and_equal的特性，需要设置隐含参数_b_tree_bitmap_plans设置为false,10G取而代之的是index_combile因为其没有单列非唯一索引和等值的限制，但是该操作通常比rowid合并集合上的操作将更耗费CPU资源。

8.另外对于index_join更是突破了and_equal对于索引必须是单列的要求，而且谓词也比一定是等值。

9.8I中对于in_list总是将其转化为多个or的语句，在9I中引入了in_list的修正工具，可能会导致成本过高，导致全表扫描的发生。

10.闭包传递对执行计划的影响，主要是和query_rewrite_enabled参数的设置有关系。

11.对于索引中的多列都为空的时候，有可能影响执行计划的判断。

12.单个操作的工作区可以达到pga_aggredate_target的5%，总和操作不能超过30%，对于9I中的MTS方式的连接仍然需要手动设置sort_area_size和hash_area_size.

 

 

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

转载于:http://blog.itpub.net/48620/viewspace-410285/