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

Question

我正在使用 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-tree 索引和集群因子 http://richardfoote.files.wordpress.com/2007/12/index-internals-rebuilding-the-truth.pdf 的文章，并按照说明通过按索引列重新排序表来优化集群因子.问题解决了！

Answer 1

您是否注意到坏查询的 I/O 是好查询的 50-100 倍？

Fast Version I/O:
    182  consistent gets 
    101  physical reads 

Slow Version I/O
  11019  consistent gets 
  11018  physical reads 

我很想看看每个系统的驱动索引（每月的一个？）的聚类因子 (ALL_INDEXES.CLUSTERING_FACTOR) 以及它与行数 (COUNT(*)) 和块数的比较(DBA_SEGMENTS.BLOCKS) 来自基础表。

Answer 2

新数据库的统计信息是最新的吗？

Answer 3

1.它是否始终慢 300 倍？或者旧数据库是否已经缓存了所有内容？

2.另外，你说的话让我很奇怪。

数据库是分开的 表空间但在同一个磁盘上。

当然，它们在不同的表空间中——它们必须在。你是想说别的吗？

3.是否在两个数据库都运行时进行比较？换句话说，旧数据库是否具有相同数量的可用资源？您是否将所有内存分配给旧数据库而没有为新数据库留下任何内容？我会关闭旧数据库，为新数据库腾出内存，然后再次尝试比较。

Answer 4

如果查询相同，列类型更改是否会强制索引数据的隐式 to_char()？这会使事情变慢很多；尽管如果执行计划说它仍在使用索引，那么这似乎不太可能。听起来您正在对一个表进行简单查询，但如果没有，是否存在从索引（数字）列到另一个表中的一个仍然是 char 的连接？我原以为更改列类型至少需要对查询进行一些调整。

Answer 5

fhin 是改变类型的列吗？在这种情况下，仍在将值与字符进行比较的 in 列表可以解释问题。