
下面是Oracle AWR report中的"SQL Statistics"部分的“SQL ordered by Elapsed Time” 列表:

从上表中可以看到,主要包含三类语句:
对于 SELECT 语句,%CPU 和 %IO 之和通常接近 100%,这说明它们的等待时间几乎全部由 CPU计算 和 I/O操作 构成,属于“健康”的SQL。
但对于 INSERT 语句, %CPU + %IO 之和明显低于 100%,意味着还有大量时间花在没有产出的等待上。
为了定量分析这部分“缺失的时间”,我们可以用以下公式计算:
Missing Portion = (100% - %CPU - %IO) × %Total
以下是几个INSERT语句的计算结果:
SQL ID | 计算过程 | 缺失比例 |
|---|---|---|
3fw75k1snsddx | (100%−5.23%−39.24%) × 17.29% | 9.60% |
f7rxuxzt64k87 | (100%−10.95%−60.24%) × 10.15% | 2.92% |
9t3n2wpr7my63 | (100%−6.08%−59.00%) × 7.59% | 2.65% |
gh2g2tynpcpv1 | (100%−4.69%−55.00%) × 3.93% | 1.58% |
gzhkw1qu6fwxm | (100%−2.08%−0.01%) × 3.61% | 3.53% |
budtrjayjnvw3 | (100%−11.36%−68.03%) × 2.21% | 0.46% |
合计后,“缺失”的DB Time比例约为 20.74%。这部分时间,这是在SQL层面上无法用CPU和I/O解释的“空白时间”。
为了找出SQL在这段“空白时间”到底在干什么,我们看看AWR报告的 Top 10 Foreground Events by Total Wait Time 部分:

我们可以看到除了CPU和IO外的等待主要有三类:
等待事件 | %DB Time | 等待类别 |
|---|---|---|
log file switch (checkpoint incomplete) | 19.9% | Configuration |
buffer busy waits | 3.3% | Commit |
log file sync | 1.4% | Commit |
都与 INSERT 操作 相关,而非 SELECT。具体来说:
三者的总和为 19.9% + 3.3% + 1.4% = 24.6%,与我们在SQL层面计算出的 20.74% 缺口很接近。
启示:如果在AWR报告中发现某些SQL的 %CPU + %IO 远低于100%,那就意味着它在进行无效等待,这时可以试图从“Top Events”中找找是谁偷走了那段时间。