为什么在具有相同硬件/数据的Oracle服务器上，此SQL运行速度比另一个Oracle服务器快得多？

并发性，locking和锁存可能起一部分作用。 我假设生产服务器正在做的事情，而不是等待这个特定的查询？

内存策略是否设置为auto？ 也许生产服务器已经分配了它的SGA池。

这也是共享池和缓冲区caching中实际存在哪些数据的问题。 testing服务器可能在缓冲区中有更多的相关数据，而不会被其他生产查询冲掉。

然后是硬件configuration。 简单的写回caching可能会造成巨大的差异。

尽情享受，不要把我们所有的时间浪费在猜测上。 跟踪完整的时间查询，看看到底是怎么回事:)

需要考虑的事项：

1. 初始化参数是否相同？ 你暗示caching…这可能是重要的。
2. 每台服务器的相对负载是多less？ “快”服务器勉强使用，所以数据不会快速老化超出caching？
3. 硬件是真的一样吗？ 小的差异，例如，RAID控制器，可以造成巨大的差异。

欢迎来到性能调优的世界： – /

“即使是SQL执行计划也完全一样。”

首先，你怎么知道的。 在10g中，您应该在v $ sql中find游标，然后在调用DBMS_XPLAN.DISPLAY_CURSOR时使用sql_id。 这显示了实际使用的解释计划，而不是EXPLAIN PLAN语句，它是对可能使用什么计划的预测。

“与运行SQL的服务器的物理读取相比，我注意到大量的缓冲区获得了”

Daft的问题，但数据是一样的？

如果“快速框”比“慢速框”less得多缓冲区，那么它正在处理更less的数据。 如果缓冲区比慢速缓冲区多，它正在处理更多的数据。

不要专注于自己的物理读取。 如果数据和查询计划相同，则相同的逻辑块将按照相同的顺序处理。 如果它们碰巧在caching中并且不需要物理读取，它将运行得更快，但是这不是你可以控制的东西。

从理论上讲，这种情况可能表明快速caching中的内存比慢速caching更多，但是如果硬件相同，则意味着您的产品和testing实例在硬件级别具有可用内存，而数据库被configuration为不使用它，这是相当不可能的。 运行在这些盒子上的其他东西更有可能强迫不同的数据块进入caching。

Oracle服务器Seam也适应预期的负载而不是当前的负载。 所以如果你使用不同的服务器，你会得到不同的caching行为。 仔细检查执行计划。 如果在大的select上有一个略微不同的执行，就像跳过扫描而不是索引扫描那样，它可能会解释一切。

你的解释计划可能会有所不同。

做这个：

设置线路200解释计划

你的SQL将不会执行。 你会得到一个消息

“解释”

然后做这个

select * from table（dbms_xplan.display）;

在这两个数据库中进行比较。 这是oracle如何访问表。 几率是不同的。

确保在DB和索引中分析了表，并且数据是相同的。