之前曾提到如何利用SQL Monitor Report对SQL进行诊断与调优，对于具体的SQL调优而言，SQL Monitor Report提供的信息无疑比AWR更有针对性，当然，AWR在信息的全面性方面会更胜一筹。本文提供一个具体的例子，同样的SQL，同样的执行计划，第一次执行的时间远远大于第二次执行的时间。

SQL Monitor Report详细提供了SQL执行所消耗的系统资源曲线，每一步骤的显著等待事件。通过对比上面两种情形下的系统资源曲线，执行计划中提供的等待事件分布，基本上应该可以诊断出第二次执行为什么比第一次执行快的原因。

下面是两个Reports的链接，你不妨试着对比对比。也借此体验下11.2 中的SQL Monitor Report在展现信息方面的灵活性(让鼠标指向每一个可能隐藏信息的地方，如每个可能的bar)。

• 第一次执行的SQL Monitor Report
• 第二次执行的SQL Monitor Report

本文要分析的是下面这个SQL，执行了半个多钟头还没返回结果。

INSERT /*+ APPEND */
INTO
 T_D
SELECT
 *
FROM
 T_A a
,T_B b
,T_C c
WHERE a.id = b.id
AND   b.number = c.number
;

Wait events 是了解Oracle运行状态的一个重要途径。对于某个具体的SQL，SQL Monitor Report提供了drill down的方式得到这个具体SQL在运行中的wait events的分布情况，下面是SQL Monitor Report的相应图形。

这里最突出的等待事件是enq: TS – contention，这是关于临时segment的等待事件，这可能是一般的表空间的争用(例如并行直接路径加载数据)，也可能是临时表空间的争用(例如为了hash join或者sort)。那么这时临时表空间的增长状态是怎么样子的呢？SQL Monitor Report提供了这方面的信息。

可以看出，temp space从开始的3G慢慢增长到20G，整个过程2800 seconds，如果算下速度的话17GB/2800=6MB/s。这刚好与上面的等待事件 enq: TS – contention相吻合。

这是一个直接加载数据的例子，在这个例子中，最后表的大小是30GB左右。可以怀疑，这些临时表空间的分配是为了存放最后放入目标表的数据。

这于这个等待事件enq: TS – contention发生在这个SQL执行过程中的哪一步呢？SQL Monitor Report也给出了答案，在执行计划那一页：

注意上图鼠标位置，标志着位于HASH JOIN BUFFERED这个步骤的等待事件enq: TS – contention占了这个SQL所有等待活动的97%！

问题到这里已经基本明了了：

1. 优化器采用Hash Join Buffered的方式返回三个表Join的结果，当为这些结果集分配临时表的空间时，碰到了严重的竞争。

2. 由于分配速度极其缓慢，导致了整个SQL超过97%的时间花在了这个等待事件上，通过去掉这个等待事件，这个SQL应该能提升上百倍的速度。

解决这个问题的根本在于加速临时表空间的回收速度，不过，也有workaround的办法，那就是预先分配足够的临时表空间，避免回收临时表空间时出现TS – contention竞争。

另外一种思路，则在于减少对临时表空间的利用，在这里，为什么要用到这么多临时表空间在于Oracle采用Hash Join Buffered而不是采用Hash Join，这意味着Oracle会先对Join的结果集进行buffer，等到所有结果ready之后再写到目标表，另一种思路当然是让结果直接写到目标表中，也就是实现并行的DML插入操作。方法很简单：在运行这个SQL之前加上

ALTER session enable parallel dml;

即可，在这种情形下，Oracle不需要再为结果集分配临时表空间，同时，由于采用并于DML操作，整个SQL的运行时间会得到很大的提速。下面是相应的执行计划。

可以看出，Hash Join Buffered变成了Hash Join，同时，等待事件enq: TS contention已然消失，换成了”喜闻乐见”的ON CPU。同时，整个SQL在小于30s的时间内完成了。

不可否认，Hash Join Buffered是这里极其隐蔽，可能不小心就被忽略了，以为上面两个执行计划就是LOAD AS SELECT的位置从第2行搬到了第4行，其实背后发生的事情远没有这么简单。以后有机会再对这个话题进行展开吧。

SQL Monitor Report是11g推出的一个新特性。如果说11gR1里的SQL Monitor Report已经达到可圈可点的程度，那么11gR2里的SQL Monitor Report可以说已经接近完美了。

这个SQL Monitor Report包含的信息比单纯的Execution Plan可全面多了，基本上，有了这份报告之后，troubleshooting所需要的大部分信息都已经具备了。

这个Report主要包括以下五部分:

1. 执行计划，包括SQL执行时年actual rows，我们一般根据它与estimate rows的吻合程度判断一个执行计划的正确与否。在10g的时候，一般可以通过hint gather_plan_statistics来让执行计划显示actural rows，而在11g中，不用相关的hint，SQL Monitor Report就能显示这部分信息了。

2. 还是执行计划，不过没有详细的statistics，但是提供了以图形方式进行执行计划的展示。

3. 并行进程在各个节点上的分布情况，还有每个slave进程的资源消耗情况(DB Time, wait events, physical IO, logical IO etc.)

4. SQL对应的数据库活动情况，从这里可以看到SQL的负载特征，如在这里，这条SQL是典型的CPU密集型的SQL。

5. 系统资源利用情况曲线图，包括CPU, IOPS, MBPS, PGA Usage, Temp Usage etc.

可以想像，这个工具将能大幅度提高DBA的工作效率，对于离线分析SQL的执行性能带来了极大的方便。

一个最常提到的问题当然是如何去获取这一份Report，除了通过EM的界面去访问之外，我更趋向于用命令行的方式，这时，有两种选择

1. 如果想在一个SQL执行完之后马上生成SQL Monitor Report，可以简单地调用下面的脚本

SET linesize 300
SET pages 50000
SET long 200000000
SET longchunksize 20000000
SET heading off
SET termout off
SET timing off
SET time off
SET echo off
SET verify off
 
define f=&1
spool &f..html
 
SELECT
DBMS_SQLTUNE.REPORT_SQL_MONITOR(
session_id=>sys_context('userenv','sid'),
report_level=>'ALL',
type=>'active') AS report
FROM dual;
 
spool off

2. 如果想在SQL执行过程中或执行结束后在另一个session捕捉SQL Monitor Report，首先必须得到这个SQL的sql_id，然后就可以利用下面的脚本进行调用了。

SET linesize 300
SET pages 50000
SET long 200000000
SET longchunksize 20000000
SET heading off
SET termout off
SET timing off
SET time off
SET echo off
SET verify off
 
SELECT
DBMS_SQLTUNE.REPORT_SQL_MONITOR(
sql_id=>'&sql_id.',
report_level=>'ALL',
type=>'active') AS report
FROM dual;