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

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

比如在机器A上所有的表的执行计划都走索引.
而在机器B上却是有的表走索引,有的表不走索引.

找过DBA,他说两机器配置是一样的.
现在很晕啊.
也不知道这位DBA大哥说的是不是正确的.

来这里请大家帮帮忙.
大家都有什么见解都说出来.也好讨论一下,也为了解决我的问题.
谢谢大家啊!!!

17 个解决方案

#1

看看这两个表的最后一次分析时间是否一致，若是不一致，执行计划不一致很正常。

将两个表再同时分析一次即可。

若是最后一次分析时间一致，则可能是两个表的数据量不同了。

#2

select TABLE_NAME,LAST_ANALYZED from all_tables where table_name=upper('yourtablename');

查询表最后一次分析的时间点

还有，两个数据库的优化模式是否一致呢？
执行计划里面是否都是有cost值？

#3

lz将
select TABLE_NAME,LAST_ANALYZED from all_tables where table_name=upper('yourtablename');

结果贴出来看看

#4

1. 检查一下上次统计信息收集的时间两个数据库是否都是一致；如果不一致，重新收集一下统计信息（两个数据库都需要收集统计信息），再看看执行计划是不是还是不一致
2. 检查表上的索引是否都一致
3. 看看不一致的执行计划涉及的表的数据量两个库差异是不是较大

#5

说明一下

现在的情况是将A机器的表导入到B机器中.

请问这样能发上象你说的这种情况吗??

:)

还有怎么来查看两个数据库的优化模式是否一致?

怎么才能知道执行计划里面是否都是有cost值?

我对oralce不是非常了解,谢谢你不厌其烦的讲解.

#6

结果如下

1 TM_F_SUBSCRB 2007-1-10 18:33:19

#7

可能是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

optimizer_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*/

#8

另外一个的最后分析时间呢？

#9

另一个的时间是空,但是时间为空的整个系统快些,而且是全部都走索引的.

#10

两边执行计划不一致就是应为两边最后分析时间不一致造成的了。

两边分别执行：

exec dbms_stats.gather_table_stats (ownname=>'cch',tabname=>'cch_interactions_motive',degree=>2,cascade=>TRUE);

将ownname和tabname替换成你的用户名和表名即可。

#11

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      CHOOSE

B库结果
SQL>  show parameter optimizer;

B库结果为空.

#12

错了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是一样的

#13

执行时报错了
内容如下

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

#14

lz我的意思你误解了

应该是：

exec dbms_stats.gather_table_stats (ownname=>'rep_hlj',tabname=>'tm_f_subscrb',degree=>2,cascade=>TRUE);

你执行即可

#15

哈哈
误会了

这段代码是什么作用啊!

跑起来很慢啊.===

这段代码执行后,将表中数据truncate后,执行计划会不会改变.

#16

跑起来是比较慢。

需要耐心等待，truncate表之后，数据量差别很大的话，有可能会改变执行计划

#17

好的
我先试一下
下班前一定给分

嘿嘿

谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊谢谢啊

#1

#2

#3