1

我有一个查询，通过在 SQL*PLus 和 autotrace traceonly 中设置时间，发现需要 40 秒才能完成。

然而，从收集的 SQL 跟踪文件来看，查询大约需要 10 秒才能完成。

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.02       0.02          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch    19537      2.66       6.49         77      61929          0      293035
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total    19539      2.68       6.52         77      61929          0      293035

运行 SQL*Plus 客户端和数据库的机器在地理位置上位于同一个中心，并且在同一个本地 LAN 上。

显示已被抑制，因此渲染应该不是问题。正在访问的表是压缩的。

那么这 30 秒能去哪里呢？谢谢。

4

1 回答 1

1

抱歉各位回复晚了。在相当长的一段时间内被取消路由以从事其他工作。我想我得到了答案。我以前没有意识到的那种愚蠢的错误。这是 SQLPlus 的获取大小问题。通过将 arraysize 设置为 5000（默认为 15），我得到了接近获取时间的执行时间。客户端和服务器之间的往返显着减少。

并回应您的一些建议/问题： 1. 检查 v$session_wait？很遗憾我没有第一眼执行它。通过查看 SQLPlus 统计信息，我注意到了这个缺陷。感谢您的建议。下次我也会检查这个。2. 跟踪文件中还有其他内容吗？跟踪文件中没有其他内容。好吧，我的意思是在同一会话期间没有执行其他主要 SQL。3.实际查询？对不起，我可以在这里发布。但预计金额。4. 查询后直接运行trace？不，我先清除了缓存。然后启用跟踪并执行查询。所以结果不是由任何缓存驱动的。

再次感谢大家:)

于 2012-09-28T01:59:07.213 回答