执行几次后查询很慢答案

【问题标题】：Query very slow after a few execution执行几次后查询很慢
【发布时间】：2015-04-29 13:05:34
【问题描述】：

我是甲骨文的新手，现在我对以下情况感到疯狂。我正在开发一个 oracle 11g 数据库，并且很多时候我使用 sql developer 运行查询，这在 5/6 秒内正确执行，而其他时间则相同的查询需要 300/400 秒才能执行。有一些工具可以调试查询使用 300/400 秒时发生的情况？

更新 1 这是我的 sql 开发者截图问题似乎是 direct path read temp

更新 2 report

更新 3 report2

有什么建议吗？

【问题讨论】：

你能运行这个并发布输出吗？ select dbms_sqltune.report_sql_monitor(sql_id => 'gvqwuz1u29s0f', type => 'text') from dual;
只是一个猜测（顺便说一句，我看不到您的图像），如果有时您运行查询并且它比其他时间快得多，您可能会从缓存中提取块，并且执行速度较慢可能意味着块已经过时并且必须重新加载。只是一个猜测，但运行跟踪会告诉你更多发生了什么
@JonHeller 我用以下 sql 语句的报告更新了我的问题dbms_sqltune.report_sql_monitor(sql_id => 'SQL_ID', type => 'text') from dual;
@Skizzo 该文件在 4K 字节处被截断。您可以尝试再次导出它吗？
@JonHeller 我更新了我的问题

【解决方案1】：

尝试设置跟踪。用户是遇到延迟的任何用户
作为系统：

GRANT ALTER SESSION TO USER;

作为执行跟踪的用户：

ALTER SESSION SET EVENTS '10046 trace name context forever, level 8';
ALTER SESSION SET TRACEFILE_IDENTIFIER = "MY_TEST_SESSION";

产生错误/问题，然后作为用户测试：

ALTER SESSION SET EVENTS '10046 trace name context off';

当系统找出跟踪文件的保存位置时：

show parameter background_dump_dest;

转到该目录并查找包含MY_TEST_SESSION 的 .trc/.trm 文件。例如 ORCL_ora_29772_MY_TEST_SESSION.trc。
之后 tkprof 那些文件。在linux中：

tkprof ORCL_ora_29772_MY_TEST_SESSION.trc output=ORCL_ora_29772_MY_TEST_SESSION.tkprof explain=user/password sys=no

阅读 tkprof 文件，它将显示给定语句的等待时间。
有关 TKPROF 的更多信息，请阅读 this。有关启用/禁用跟踪的更多信息，请阅读 this。

【讨论】：

【解决方案2】：

最好的工具是Real-Time SQL Monitoring。它不需要更改代码或访问操作系统。唯一的缺点是它需要对 Tuning Pack 进行许可。

将此单行代码与另一个答案中的跟踪步骤进行比较。此外，输出看起来更好。

select dbms_sqltune.report_sql_monitor(sql_id => 'your sql id', type => 'text') from dual;

几乎从不需要在 11g 及更高版本中使用跟踪。

【讨论】：

所以唯一的缺点是 15k 美元？ ;)
@mmmmmpie 是的，就是这样！嘿嘿，贵公司已经为甲骨文支付了几百万，还不如拿下这个很酷的选择。 :) 如果调整包不可用，您可以使用an open source tool I built 重新创建该功能。不过，这取决于 AWR，这也需要钱。无论如何，重点是 Oracle 拥有所有这些机制，以静默方式记录性能数据。如果可能，使用其中之一通常比处理跟踪更方便。
我可以确认，如果您处理 oracle 支持，他们将需要 tkprof 跟踪，仅此而已。
@mmmmmpie 您对 Oracle 支持的看法是正确的。上周，我的同事花了几天时间和他们一起试图追踪一些东西。我使用了监控并在几个小时内解决了它。设置跟踪可能需要很长时间 - 在许多环境中，很难获得更改或重新运行任何内容的许可。当监控可以在几秒钟内为您提供等待信息时，为什么要花那么多时间呢？但最终了解所有这些工具很有用。
同意。不幸的是，痕迹是我们生活的世界。我不记得在没有 tkprof 的情况下使用过 Oracle 实例（我从 9i 开始），支持也是如此。应用程序跟踪通常是最难跟踪的，但优秀应用程序内部将具有跟踪用户不同会话的种子能力，而不是跟踪整个应用程序数据库帐户。

【解决方案3】：

此行为可能是由 11gR2 中的基数反馈错误/问题引起的。我有一个类似的问题。您可以通过_optimizer_use_feedback=false关闭此功能来测试是否是这种情况

也尝试应用最新的更新。

【讨论】：