oracle性能 服务器,Oracle：同一服务器上的数据库之间的性能差异为300倍

我正在使用oracle 9.2.0.3.0服务器上的新旧数据库。

对新数据库中的表的查询比对旧数据库中的表的相同查询慢约300倍。

这些数据库非常相似，但存在一些差异：

我在旧表中测试的表有一个CHAR列(索引)和12个NUMBER列。

我在新表中测试的表有一个NUMBER列(索引)而不是CHAR列，13个NUMBER列和10个新的VARCHAR2列，大小限制为40-100。

两个表都以相同的方式编制索引(除了列的类型...)

两个表都有大约1900000条记录。

我的查询在两种情况下获得相同的执行计划(使用索引，没有完整扫描)

数据库位于单独的表空间中，但位于同一磁盘上。

旧表空间的使用率约为70％，新的表空间占94％，否则设置相同(据我所见)。

表空间中的碎片并不坏，但旧的碎片更糟糕(是的！)

由于新表有更多列，因此它使用的块比旧表多三倍。

关于如何进行的任何想法？

更新1：在新数据库上运行查询10次后，速度降低了大约80倍。改进！但是仍然没有解决。

更新2：由于列类型更改，查询确实略有不同。首先是旧的(快)然后是新的(慢80-300倍)。

SELECT fhin, SUM(cost)

FROM olddb.oldtable

WHERE month in ('1004 ') AND fhin IN ('1', '2', '3', '4', '5', '6', '7', '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '22', '23', '24', '25', '26', '27', '28', '29', '30', '40', '99')

GROUP BY fhin

SELECT fhin, SUM(cost)

FROM newdb.newtable

WHERE month IN (201004) AND fhin IN ('1', '2', '3', '4', '5', '6', '7', '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '22', '23', '24', '25', '26', '27', '28', '29', '30', '40', '99')

GROUP BY fhin;

请不要问为什么查询看起来像它，它不是我的;-)

更新3：使用旧查询解释统计信息：

execution schema (my translation to English)

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE

1 0 SORT (GROUP BY)

2 1 TABLE ACCESS (BY INDEX ROWID) OF 'OLDTABLE'

3 2 INDEX (RANGE SCAN) OF 'OLDTABLE' (NON-UNIQUE)

Statistics

----------------------------------------------------------

0 recursive calls

0 db block gets

182 consistent gets

101 physical reads

0 redo size

903 bytes sent via SQL*Net to client

398 bytes received via SQL*Net from client

3 SQL*Net round trips to/from client

1 sorts (memory)

0 sorts (disk)

28 rows processed

解释新查询的统计信息：

execution schema (my translation)

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=36 Card=30 Bytes=360)

1 0 SORT (GROUP BY) (Cost=36 Card=30 Bytes=360)

2 1 TABLE ACCESS (BY INDEX ROWID) OF 'NEWTABLE' (Cost=11 Card=13857 Bytes=166284)

3 2 INDEX (RANGE SCAN) OF 'NEWTABLE' (NON-UNIQUE) (Cost=1 Card=22502)

Statistics

----------------------------------------------------------

0 recursive calls

0 db block gets

11019 consistent gets

11018 physical reads

0 redo size

906 bytes sent via SQL*Net to client

398 bytes received via SQL*Net from client

3 SQL*Net roundtrips to/from client

1 sorts (memory)

0 sorts (disk)

28 rows processed

我猜他们毕竟不是那么相似。有任何想法吗？

更新4：感谢所有非常棒的帮助！问题仍未解决，但我的客户在接下来的两周内无法使用。我会尝试一切，然后再回到这里进行更新！

更新5：我回到了网站！我运行了A. Musch建议的聚类因子分析，发现了这个：

Table Clustering Factor Rows Blocks

Old 12633 1930000 12645

New 938379 1890000 39677

我猜测问题是我们在新数据库中有一个糟糕的集群因素。关于如何解决这个问题的任何想法或链接？

更新6：感谢Adam的暗示，我发现了这篇关于Oracle B树索引和聚类因子的文章http://richardfoote.files.wordpress.com/2007/12/index-internals-rebuilding-the-truth.pdf并遵循了通过索引列重新排序表来优化聚类因子的说明。问题解决了！