Oracle11g R2 -相同的查询有时快，有时慢

Question

对于一个包含大约100行的表，我有一个简单的更新查询：

UPDATE RESULTS_DATA 
     SET IMAGE_BLOB=:myBlob 
WHERE MEASUREMENT_INDEX=:mIndex 
  AND BATCH_ID=:batchId 
  AND SYSTEM_ID=:sysId

在我搜索的所有3列上都有索引。这个水珠的大小是1.2毫巴。有时，查询需要0.5秒才能完成，而另一些时候则需要3-4秒。查看V$SQL表可以发现，在同一查询的多次运行之间，几乎所有内容都是相同的，但是以下字段非常不同：

IO_INTERCONNECT_BYTES (1277952用于快速查询，2818048用于慢速查询) PHYSICAL_READ_REQUESTS (1用于快速查询，27用于慢速查询)

 PHYSICAL\_READ\_BYTES (8192 on fast query, 393216 on slow query)

 PHYSICAL\_WRITE\_REQUESTS (155 on fast query, 164 on slow query)

 PHYSICAL\_WRITE\_BYTES (1269760 on fast query, 2424832 on slow query)

这是因为运行完全相同的查询，发送完全相同的BLOB。有人能告诉我为什么会发生这种事吗？

谢谢!

Answer 1

查询有时是快速的，因为它位于数据库的缓存中。

做一个测试：

1. 更改系统刷新shared_pool；(作为sysdba -不在生产中！)
2. 执行查询和显示执行计划；
3. 执行查询和显示执行计划(应该更快，因为查询不是解析的，而是只执行的)；
4. 更改系统刷新shared_pool；(作为sysdba)
5. 执行查询和显示执行计划(应该慢一点，首先解析查询，然后执行)

在理想的世界中，查询被解析一次，绑定/执行一遍又一遍。

Answer 2

计划总是一样的吗？甲骨文优化器是一个相当复杂的野兽-只要问乔纳森刘易斯谁写了一个书关于它- 536页，这只是“基本面”！来自这里

您是否曾经遇到过这样一种情况，即以前行为良好的数据库查询突然开始执行不佳？更有可能的是，您将原因追溯到执行计划中的更改。

可能是为你写的！:-)这可能也很有趣--它似乎是建立在“你比你不喜欢的魔鬼更好”的哲学之上的--也就是说，只需要在大多数情况下都能很好地执行一个查询，而不是冒着优化器脑力劳动和偶尔敲打磁盘的风险--缺点是也会错过优秀的计划--啊.工程-这都是关于妥协..。

另一个想法--你提到“这是在我的PC上托管的测试数据库上的”--我知道，在我使用过的许多开发机器上，偶尔会出现I/O中的尖峰，原因只能由Oracle (在经典意义上而不是RDBMS意义上)来预测。如果您没有将操作系统、服务器、temp和数据隔离到不同的磁盘和/或阵列上，那么所有开发机器测试都将受到准量子变化的影响。

我注意到(这是轶事，我不认为是无所不知的)，这似乎更多地发生在带有RDBMS的机器上(特别是在RDBMS上)。( Oracle) -缓存/刷新/检查点？如果您可以在RAIDed系统上测试这一点，那么您可能获得更一致的查询响应时间吗？

我知道这是“手卷”和“华夫利”，但是.