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;