performance - Oracle:同一服务器上的数据库之间的性能差异为 300 倍

Question

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

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

这些数据库非常相似，但也有一些差异:

我在旧表中测试的表有 1 个 CHAR 列(已索引)和 12 个 NUMBER 列。 我在新表中测试的表有 1 个 NUMBER 列(已索引)而不是 CHAR 列、13 个 NUMBER 列和 10 个新的 VARCHAR2 列，大小限制为 40-100。 两个表都以相同的方式建立索引(除了列的类型...)

两个表都有大约 1900000 条记录。 我的查询在两种情况下都获得相同的执行计划(使用索引，没有完整扫描) 这些数据库位于不同的表空间中，但位于同一磁盘上。 旧表空间的使用率约为 70%，新表空间的使用率为 94%，否则设置相同(据我所知)。 表空间中的碎片还不错，但旧表空间中的碎片更严重(是的!) 由于新表有更多列，因此它使用的 block 是旧表的三倍。

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

更新 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并按照通过按索引列对表重新排序来优化聚类因子的说明进行操作。问题解决了!

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(*))和 block 数的比较(DBA_SEGMENTS.BLOCKS) 来自基础表。