查询根据SQL_TRACE快速运行，但实际完成时间要长得多

Question

我有一个查询，通过在SQL * PLus中设置计时和自动跟踪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秒可以去哪儿？感谢。

Answer 1

对不起家伙迟到的回复。在相当长的一段时间内被解决了其他问题。我想我得到了答案。我以前没有意识到的那种愚蠢的错误。这是SQLPlus的获取大小。通过将arraysize设置为5000（默认值为15），我将执行时间接近获取时间作为no。客户端和服务器之间的往返次数显着减少。

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

再次感谢所有人：）