今天，现场人员报告说，历史查询服务器很慢，一样的SQL放到主库中运行比转发到历史查询库上要快很多。

于是要来SQL，在两个库中分别查看执行计划。
select /*+rule*/ cola,colb
from tablea
where  colc in (....)
and cold >= 111 and cold <=222;

主库中是使用了cold上的索引，而历史库中则使用了全表扫描，这是导致查询速度差异的原因。

但是问题是，仔细检查了两个库中的表，所有的列定义，索引定义，分区定义都是一样的，而且由于SQL中明确指定了/*+RULE*/的提示，所以也排除了数据在两个库中分布不一样的问题。

cold是表的PK中的第一个字段。

以下所有的操作都是在历史库中进行的：
1。去除了/*+RULE*/提示，改用FIRST_ROWS，执行计划没有变化，仍然使用了全表扫描，改为/*+use_index(table,index)*/，仍然全表扫描。

2。作了一次25%的estimate，使用FIRST_ROWS，执行计划改变为使用正确的索引了。但是/*+RULE*/和/*+use_index(table,index)*/仍然全表扫描

3。作100053的trace，奇怪的问题出现了，居然udump目录中不生成任何trace文件。
alter session set events '10053 trace name context forever, level 1';
explain plan for ...
alter session set events '10053 trace name context off';

4。于是禁用主键，同时删除了index，然后重新启用主键，此时unique index自动创建了。再次查看执行计划，全部正常了。

5。用dbms_stats包gather_table_stats，重新执行SQL，发现又再次变为全表扫描

6。用dbms_stats包delete_table_stats之后重新开始使用索引。

至此基本上明白是统计信息的收集导致了在使用/*+RULE*/时，SQL没有正确地遵守RBO的规则。
奇怪的问题。

100053没有trace生成也是奇怪的问题。

数据库 是8174
optimizer_mode设置为first_rows

你有沒有試過用alter session set OPTIMIZER_MODE=ture?
然後用select cola,colb
from tablea
where colc in (....)
and cold >= 111 and cold <=222;
?

是不是就是/*+RULE*/ 的 HINTS没起作用？
817在+后面还需要空格吧，有吗？

以前发现过，在有的时候确实HINTS不起作用。

alter session set events '10053 trace name context forever, level 1';
explain plan for ...
alter session set events '10053 trace name context off';
10053只适用于cbo,rbo的情况下不会产生trace文件


5。用dbms_stats包gather_table_stats，重新执行SQL，发现又再次变为全表扫描
6。用dbms_stats包delete_table_stats之后重新开始使用索引。

就很奇怪。

QUOTE:

---

最初由 abcd 发布
是不是就是/*+RULE*/ 的 HINTS没起作用？
817在+后面还需要空格吧，有吗？

以前发现过，在有的时候确实HINTS不起作用。

---

似乎不加空格也可以。 注意  Optimizer=HINT: RULE


Connected to:
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production

SQL> set atuottrace on
SP2-0158: unknown SET option "atuottrace"
SQL> set autotrace on
SQL> select /*+ rule */ count(*) from t;
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=HINT: RULE
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'T'


SQL> select /*+rule*/ count(*) from t;

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=HINT: RULE
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'T'


SQL> select /*+rule */ count(*) from t;

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=HINT: RULE
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'T'


SQL> select /*+ rule*/ count(*) from t;

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=HINT: RULE
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'T'

analyze是否产生同样的影响？

把索引重建一下,再把表重新分析一下看看呢

MD，现在可以作trace了，莫名其妙

.full是在作了分析以后，再抓取SQL执行计划的trace文件
.indx是在删除了分析数据以后，再抓取SQL执行计划的trace文件


重新上传了

附件有问题，无法下载

QUOTE:

---

最初由 yangtingkun 发布
analyze是否产生同样的影响？

---

同样的影响