"为什么同样表结构在不同机器上执行计划不一致"? 急.....

Question

"为什么同样表结构在不同机器上执行计划不一致"?比如在机器A上所有的表的执行计划都走索引.
而在机器B上却是有的表走索引,有的表不走索引.找过DBA,他说两机器配置是一样的.
现在很晕啊.
也不知道这位DBA大哥说的是不是正确的.来这里请大家帮帮忙.
大家都有什么见解都说出来.也好讨论一下,也为了解决我的问题.
谢谢大家啊!!!

Answer 1

select TABLE_NAME,LAST_ANALYZED from all_tables where table_name=upper('yourtablename');
查询表最后一次分析的时间点还有，两个数据库的优化模式是否一致呢？
执行计划里面是否都是有cost值？

Answer 2

lz将
select TABLE_NAME,LAST_ANALYZED from all_tables where table_name=upper('yourtablename');
结果贴出来看看

Answer 3

说明一下现在的情况是将A机器的表导入到B机器中.请问这样能发上象你说的这种情况吗??:)还有怎么来查看两个数据库的优化模式是否一致?怎么才能知道执行计划里面是否都是有cost值?我对oralce不是非常了解,谢谢你不厌其烦的讲解.

Answer 4

结果如下1 TM_F_SUBSCRB 2007-1-10 18:33:19

Answer 5

可能是b库没有分析怎么看执行计划优化模式：SQL> show parameter optimizer;
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_dynamic_sampling           integer     1
optimizer_features_enable            string      9.2.0
optimizer_index_caching              integer     0
optimizer_index_cost_adj             integer     100
optimizer_max_permutations           integer     2000
optimizer_mode                       string      CHOOSEoptimizer_mode = first_row
optimizer_mode = all_rows
optimizer_mode = choose 的时候，如果sql from 子句后面任何一个的表或表的索引带有statictics(dba_tables.last_analyzed 字段非空)，则采用cbo，否则采用rbo。例如：
Select last_analyzed,table_name from dba_tables where table_name in ('SAS_COLLECT', 'SAS_EMPLOYEE', 'SAS_GROUP',’ PSCP_SMS_SENT’)
若结果为：
LAST_ANALY TABLE_NAME
---------- ------------------------------
           SAS_COLLECT
10-10月-05 SAS_EMPLOYEE            ――则整个sql语句为CBO优化模式
           SAS_GROUP 使用了hints的sql必定是cbo！
 使用了ordered提示，必定是cbo！如：/*+ORDERED*/

Answer 6

两边执行计划不一致就是应为两边最后分析时间不一致造成的了。两边分别执行：exec dbms_stats.gather_table_stats (ownname=>'cch',tabname=>'cch_interactions_motive',degree=>2,cascade=>TRUE);将ownname和tabname替换成你的用户名和表名即可。

Answer 7

A库结果:
SQL> show parameter optimizer;NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_dynamic_sampling           integer     1
optimizer_features_enable            string      9.2.0
optimizer_index_caching              integer     0
optimizer_index_cost_adj             integer     100
optimizer_max_permutations           integer     2000
optimizer_mode                       string      CHOOSEB库结果
SQL>  show parameter optimizer;B库结果为空.

Answer 8

错了B库结果为
SQL> show parameter optimizer;NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_dynamic_sampling           integer     1
optimizer_features_enable            string      9.2.0
optimizer_index_caching              integer     0
optimizer_index_cost_adj             integer     100
optimizer_max_permutations           integer     2000
optimizer_mode                       string      CHOOSE
和A是一样的

Answer 9

执行时报错了
内容如下SQL> exec dbms_stats.gather_table_stats (rep_hlj=>'cch',tm_f_subscrb=>'cch_interactions_motive',degree=>2,cascade=>TRUE);begin dbms_stats.gather_table_stats (rep_hlj=>'cch',tm_f_subscrb=>'cch_interactions_motive',degree=>2,cascade=>TRUE); end;ORA-06550: line 1, column 7:
PLS-00306: wrong number or types of arguments in call to 'GATHER_TABLE_STATS'
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored

Answer 10

lz我的意思你误解了应该是：
exec dbms_stats.gather_table_stats (ownname=>'rep_hlj',tabname=>'tm_f_subscrb',degree=>2,cascade=>TRUE);你执行即可

Answer 11

哈哈
误会了这段代码是什么作用啊!跑起来很慢啊.===这段代码执行后,将表中数据truncate后,执行计划会不会改变.

Answer 12

跑起来是比较慢。需要耐心等待，truncate表之后，数据量差别很大的话，有可能会改变执行计划