Performance 是什么导致Oracle tkprof文件中CPU时间和运行时间之间的差异

在分析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时间非常相似

---

我无法访问生成跟踪文件的数据库（它来自客户端站点），但我想了解发生了什么，以便就如何减少运行时间提出建议。

CPU时间是查询实际需要的时间；其余的则在等待资源。在繁忙的服务器上，这主要是由于等待其他用户当前使用的CPU；这不会显示在等待统计信息中。

系统有多忙，体系结构是什么，查询看起来如何？ sga的尺寸如何

本示例中最令人惊奇的是解析时间。那个可怜的服务器得到了一些看起来不太有趣的东西

通常，经过的时间是处理完整查询所用的挂钟时间。cpu时间，cpu被使用的时间。对于您的系统，我将尝试找出解析花费如此长时间的原因。如果你解决了这个问题，很有可能你也解决了获取时间问题。

---

请求查询运行期间的addm报告并研究该报告。是在addm报告中获得一些理解的好地方。

正如Tony所说，对于跟踪中未说明的时间，一个常见的解释是等待CPU的时间。我经历过的另一个问题是，如果有什么事情导致跟踪文件发生缓慢，那么写入跟踪文件本身所花费的时间；但是如果是这种情况，在运行带有或不带有跟踪的查询时，您应该会看到时钟时间上的巨大差异

解析时间非常长。解析通常是CPU受限的，而这表明没有CPU时间和大量的运行时间。您有大量的

无锁存

等待，这一事实可能表明存在大量解析争用，但归因于等待的时间仅为您已用解析时间的1/10左右

---

因此，我同意Tony的观点，在这种情况下，CPU严重争用是一个可能的问题。大量解析可能是导致此问题的原因。

+1在试图找出导致查询运行缓慢的原因时，我看到的最大消耗是其他正在运行的查询和磁盘IO。查看此语句的等待统计信息，大约花了21秒等待物理I/O（db文件顺序读取和db文件分散读取）这超过了处理查询所需的14秒CPU。您有权访问原始跟踪文件，还是仅访问tkprof输出？目前没有，但我可以请求。我会在原始跟踪中寻找什么？有时逐行遍历跟踪并查看

tim

值中出现大跳跃的地方会很有帮助。此外，如果您有原始跟踪，您可以选择通过更详细的工具（如Hotsos Profiler）运行它。