【问题标题】:ORACLE: same query, same environment, same execution plan, same server, BUT DIFFERENT EXECUTION TIMEORACLE:相同的查询,相同的环境,相同的执行计划,相同的服务器,但不同的执行时间
【发布时间】:2018-03-29 12:48:05
【问题描述】:

谁能想象一个简单的 SELECT 执行了 14 次,得到不同的执行时间?

我的 SQL 查询如下所示:

select count(*) 
from myTable_1 x
left join myTable_2 y ON x.id = y.id
where y.id is null;

这 2 个表包含超过 1.500.000 条数据。通过 LEFT 加入他们,我应该得到更少。

第一次执行时,我在 40 秒后强制停止。 在第二次执行时,7 秒后我得到了一个结果集。 在第三次执行时,10 秒后我得到了相同的结果集。 在第 4 次执行时,我在 >600 秒后强制停止。 从第 4 次到第 19 次执行,我只是强制停止,因为它持续了超过 1 分钟,没有结果。

据我所知:只要查询完全执行(第二次执行),一些“数据”就会保存在高速缓存中。在下一次执行(第 3 次,第 4 次...)时,执行的持续时间必须

它有什么问题? 它在相同的环境中执行,将相同的数据放入表中。 我不再考虑硬件配置,因为它发生在同一个环境中。我没有看到“索引提示”的使用。我找不到关于这种不同执行时间的解释......

【问题讨论】:

标签: sql oracle query-performance


【解决方案1】:

当您的 SQL 正在运行查询 v$session 以获取您的 sql_id

一旦你有了sql_id 查询v$sql 来获取这个sql_id

这个视图v$sql 给出了你的 sql 执行的磁盘读取、缓冲区获取、并发等待时间、用户 io 等待时间、cpu 时间、经过时间和许多其他属性。提取这些数据并进行比较。这将显示您的 sql 在哪里花费更多时间。

在执行测试时,还要检查哪些其他数据库活动正在消耗数据库资源。上述视图也可用于此目的。

还要检查您的服务器是否被任何其他数据库或进程使用,而没有正确的最大资源配置。

【讨论】:

    猜你喜欢
    • 2023-03-09
    • 2018-07-29
    • 2011-08-19
    • 1970-01-01
    • 1970-01-01
    • 2018-11-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多