在分析Oracle tkprof跟踪文件时，我注意到cpu时间和经过时间之间有时存在很大差异，我不知道是什么原因造成的。
例如：
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 42.09 0 0 0 0
Execute 1 0.01 0.01 0 0 0 0
Fetch 45 14.44 62.71 48664 505513 0 1871
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 47 14.45 104.82 48664 505513 0 1871
等待统计信息如下：
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 46 0.00 0.00
SQL*Net message from client 46 0.19 1.68
buffer busy waits 559 0.23 8.59
db file scattered read 5204 0.21 7.49
db file sequential read 4240 0.20 13.49
latch free 215 0.11 3.62
我是一名软件开发人员（不是DBA）所以我通常会查看这些跟踪文件以查找效率低下的查询或查看是否可以使用索引来停止全表扫描等等。为此我倾向于继续使用cpu时间。在大多数情况下，经过的时间与cpu时间非常相似。
我无法访问生成跟踪文件的数据库（它来自客户端站点），但我想了解发生了什么，以便我可以就如何减少已用时间提出建议。 / p>
答案 0 :(得分：9)
CPU时间是您的查询实际需要的时间;其余的都在等待资源。在繁忙的服务器上，这可能主要是由于等待其他用户当前正在使用的CPU;这不会出现在等待统计数据中。
答案 1 :(得分：3)
系统有多忙，架构是什么，查询是什么样的？ sga的尺寸如何？
此示例中最令人惊讶的是解析时间。那个糟糕的服务器会把一些东西扔给它，看起来不是很有趣......
通常，经过的时间是处理完整查询所花费的挂钟时间。 cpu时间，使用cpu的时间。对于你的系统，我会去尝试找出为什么解析花了这么长时间。很有可能，如果你解决了这个问题，你也可以解决获取时间问题。 请求查询运行期间的addm报告并研究该报告。Oracle® Database 2 Day + Performance Tuning Guide 11g Release 2 (11.2)是在addm报告中获得一些理解的好地方。
答案 2 :(得分：2)
正如托尼所说，跟踪中未计入时间的一个常见解释是等待CPU花费的时间。我遇到的另一个问题是写入跟踪文件本身所花费的时间，如果有什么事情导致这种情况发生得很慢;但如果是这种情况，那么在运行带或不带跟踪的查询时，您应该看到时钟时间的巨大差异。
解析时间很长。解析通常是CPU限制的，而这表示没有CPU时间和大量的经过时间。您有大量latch free等待的事实可能表明存在大量解析争用，但归因于等待的时间仅为您经过的解析时间的1/10。
所以我同意Tony的观点，即在这种情况下，CPU争用很大。大量的解析可能会导致这个问题。