本文要分析的是下面这个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行，其实背后发生的事情远没有这么简单。以后有机会再对这个话题进行展开吧。

随着业务的发展，IT部门的服务器数量会越来越庞大，另一方面，这些服务器的利用率却得不到充分利用，于是，服务器的资源整合就被提上了议事日程，这方面的相应的解决方案一般有

1. Hardware Partitions,
2. O/S Workload Managers,
3. Virtualization
4. 等等。

在11gR2中，Oracle也提供了一种简单有效的方法实现对服务器资源的整合，这就是Instance Caging技术。

下面的描述实际上来源于Oracle发表的一篇白皮书，下载地址

http://www.oracle.com/technology/products/manageability/database/pdf/owp_instance_caging.pdf

下面是两种应用资源整合的场合：

1. 对性能要求不严格的数据库，一般我们可以把多个数据库放在同个服务器上，没有突发负载的情况下，所有数据库共享服务器的资源，与把服务器的资源划分隔离给不同的数据库相比，这一方面可以充分利用服务器的计算资源，另一方面也省去了管理的开销。这时，要处理的主要问题在于当某个数据库有突发的工作负载的时候，我们不能让这个数据库占用整台机器的资源，以防止对其它数据库资源的争用。这时，我们说出现了资源过度分配的问题。

举个例子来说，一个有4个CPU的系统，运行着4个数据库，我们可以规定任一个数据库用CPU的最高额度是3个CPU。于是，当4个数据库同时处于业务高峰时，理论上的主机最高压力就会达到12CPU。不过，当启用Instance Caging之后，每个数据库能运行的进程数将受到控制，OS根据每个数据库能运行的进程数分配给每个数据库相应的CPU资源。这样，多个同时处于业务高峰的数据库将会根据预设的最高额度值共享服务器的资源。

2. 对性能要求苛刻的数据库，一般而言，我们希望对CPU进行分区，分配给不同的数据库不同的CPU数目，这样不同的数据库之间就不会造成相互的影响。比如有4个CPU，两个数据库，那么我们可以为第一个数据库分配1个CPU，第二个数据库分配3个CPU。

那么，如何启用Instance Caging呢？简单的两步：

1. 设置cpu_count

2. 启用任何一个Resource Manager Plan.

下面是一个实际案例，利用Instance Caging实现对服务器资源的分区的一个测试结果。

可以看到，Instance Caging还是实现了它所宣称的partition功能的。

有一次跟一个QQ上的朋友一起探讨了另一个对系统CPU进行度量的指标: CPU used by this session。

他刚好有一份AWR报告，在这份报告里，出现了严重的CPU used by this session和DB CPU不一致的现象。

下面是这份报告的一些片断

再做进一步的归纳：

OS Busy% = 1821080/(1821080+5384293) = 25%

Inst CPU% (using DB CPU) = 8934.22*100/(1821080+5384293)=12%

Inst CPU% (using CPU used by this session) = 418035/(1821080+5384293) = 6%

用CPU used by this session计算出的CPU利用率竟然只是用DB CPU计算出来的利用通率的一半！

我的第一个反应是在Jonathan lewis网站看到的一篇相关文章，里面提到了DB CPU和CPU used by this session计算时的不同之处:

“prior to 10g Oracle usually updated time figures at the end of each database call; but from 10g there are some views where time is updated more regularly.

The “DB CPU” from v$sess_time_model increases every six seconds, while the “CPU used by this session” from v$sesstat changes only at the end of the test.”

如何验证这一点呢？

在浏览这份报告的TOP SQL时，我们发现了下面的现象：

这是从SQL ordered by Elapsed Time截取出来的Top 3 SQL。TOP 1的SQL用了DB Time的30.10%，用了2517s 的CPU Time。但请注意它的Executions的值却为0。也就是说，这里的CPU Time是还没有被计算入CPU used by this session这个指标里面的。

我们再把2517s加回来，看出误差缩小多少:(251700+418035)/(1821080+5384293) = 9%

这时和用DB CPU计算出来的12%还是有1/4的差距。

从这个例子可以看出，用DB CPU度量还是比用CPU used by this session来得准确的。特别在有大查询在跑的过程中抓的AWR，这个误差很有可能会被放大。

一个有趣的实际例子。

如果这个系列是按“总-分-总”组织的话，接下来的系列应该是进行“分”这一部分了。

构建DSS系统的第一步离不开数据加载，通过文本文件加载是最常见的方式，Oracle提供了外部表加载的方法，即把一个文本文件当成一个正常的表来进行操作，通过类似insert /*+ append */ into table select from external_table的方式进行加载。

数据加载是一个CPU-Bound的过程，不过是通过什么工具，external table也好，sqlldr也好，imp也好，impdp也好。换句话说，如果连数据加载都出现IO瓶颈，这个系统的配置就说不过去了。

这个过程的AWR报告会是怎么样子的呢？

先做个一般的假定，从外部表加载数据到一个本地分区表。

Top 5 Timed Events类似下面：

如果去抓取这段时间DBA_HIST_ACTIVE_SESS_HISTORY的数据，并转换为图表的话，我们会得到更形象的Top 10 Wait Events.

（如何实现这一步可以参考用Oracle实现ASH的数据透视图）

enq: HV – contention是什么东西呢？

在11.2以前，对于分区表的parallel direct-path load，Oracle采用的是brokered load的方式，即所有的PX Slaves共享对每个分区的high water mark的访问，通过轮流持有high water mark实现对每个segment添加新的blocks。这种方法对于充分利用extent的空间是有帮助的，不过带来的问题就是对high water mark的竞争，也就是这里的enq: HV – contention。在执行计划中，这以RANDOM LOCAL 标记。下面是一个例子:

--------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name     | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
--------------------------------------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT                 |          |  8168 |    14M|     2   (0)| 00:00:01 |        |      |            |
|   1 |  PX COORDINATOR                  |          |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)            | :TQ10001 |  8168 |    14M|     2   (0)| 00:00:01 |  Q1,01 | P->S | QC (RAND)  |
|   3 |    LOAD AS SELECT                | TAB      |       |       |            |          |  Q1,01 | PCWP |            |
|   4 |     PX RECEIVE                   |          |  8168 |    14M|     2   (0)| 00:00:01 |  Q1,01 | PCWP |            |
|   5 |      PX SEND RANDOM LOCAL        | :TQ10000 |  8168 |    14M|     2   (0)| 00:00:01 |  Q1,00 | P->P | RANDOM LOCA|
|   6 |       PX BLOCK ITERATOR          |          |  8168 |    14M|     2   (0)| 00:00:01 |  Q1,00 | PCWC |            |
|   7 |        EXTERNAL TABLE ACCESS FULL| ET_TAB   |  8168 |    14M|     2   (0)| 00:00:01 |  Q1,00 | PCWP |            |
--------------------------------------------------------------------------------------------------------------------------

一个好消息是，11.2引入了一种新的方式，叫做PKEY distribution。在这种方式下，一个特定的分区只交给一个或多个特定的PX slave负责，这种方式不仅减少了对high water mark的争用，而且可以实现partition内更好的压缩率。

除了DB CPU，DB Time，或许另一个比较常用的指标应该是IO的利用情况。关于IO的指标就比较多了，单单在Load Profile里面就有5个，在DB Time和DB CPU的下面：

这5个指标的值都来自v$systat视图，分别是：

• Redo Size: ‘redo size’
• Logical reads = ‘session logical reads’ or (‘db block gets’ + ‘consistent gets’)
• Blocks Changes = ‘db block changes’
• Physical reads = ‘physical reads’
• Physical writes = ‘physical writes’

具体指标的解释参考Database Reference.

如何得到系统大致的MBPS呢？

MBPS= (Physical reads + Physical writes) * Block_Size = (196,271.4+2.0)*8*1024/1024/1024 = 1533 MB/s

更准确的MBPS可以从Instance Activity Stats部分获得。

physical IO disk bytes = physical read total bytes + physical write total bytes

值得注意的是这里physical write total bytes大致是physical write bytes的两倍。这应该是physical write total bytes统计的是磁盘的IO，而这里，我们做了ASM，normal redundancy，一份数据写了两遍的原因。

Load Profile剩下的部分主要是关于各种执行情况的统计，除了W/A MB processed来自v$pgastat（单位其实也是Byte，不是MB），其它数据都是来自于v$sysstat。

• Blocks Changes: ‘db block changes’
• User calls:  ‘user calls’
• Parses: ‘parse count (total)’
• Hard parses: ‘parse count (hard)’
• Logons: ‘logons cumulative’
• Executes:  ‘execute count’
• Rollbacks: ‘user rollbacks’
• Tranasactions: ‘user rollbacks’ + ‘user commits’
• W/A MB processed: ‘bytes processed’

一般而言，Hard parses < Parses < Executes < User Calls。

AWR的一般性介绍我想差不多就这些了，其它部分的介绍借助于一些更具体的AWR报告进行分析可能会更加方便和清晰。

写了Linux上的监控与分析工具之后，写写Oracle上相应的监控与分析工具还是挺有意思的，一方面可以更加完整，一方面可以进行横向对比。

Linux上的性能数据一般都来自于/proc文件系统，而Oracle则是来自于V$视图。因此，所有的Oracle监控工具的实现都万变不离V$ 视图。而这些个视图里面，最重要的应推v$sysstat。里面记录着Instance一级的各个统计数据的当前值，例如CPU利用情况，逻辑读，Redo Size等等。10g后有了另一个重要的视图，叫v$active_session_history,通过它可以容易地得知当前Instance的活动状态，主要是各个时刻系统都在等待哪些事件，通过对这些等待事件和相应等待次数的统计，就可以清晰地了解系统的历史工作负载特征和压力情况。如果想获取当前正在执行的SQL，则可查询v$sql视图。如果想获取当前SQL的执行计划，则可调用dbms_xplan.display_cursor。从这方面讲，每一个DBA都具备着写一个Oracle的监控工具的能力。它应该比写一个Linux的监控工具来得容易简单得多。

如果对监控工具做下分类的话，可以分成两类，一类是基于文本模式的，一类是基于GUI模式的。大部分DBA都自己收集了一些很常见的监控脚本，我想可以把这一类归为基于文本模式的工具。文本模式的好处在于轻量级，反应速度快，比较适合在shell模式下和sqlplus协同工作。大部分DBA可能也比较习惯这个模式，包括我在内。

GUI模式用得较多的工具应该是Toad。很不错的一个工具，用它来监控sessions，session正在执行的语句，session的等待事件是我最常用的一个功能。

也有一些后起之秀，有个工具也许值得一提，叫做DB Optimizer。最主要的是这个产品的主要参与者：参与了10g EM里的Performance Page的重新设计的Kyle Hailey。以一个截图做为结尾吧:

上一篇提到了DB CPU，这是一个用于衡量CPU的使用率的重要指标。假设系统有N个CPU，那么如果CPU全忙的话，一秒钟内的DB CPU就是N秒。

如何去表征一个系统的繁忙程度呢？除了利用CPU进行计算外，数据库还会利用其它计算资源，如网络，硬盘，内存等等，这些对资源的利用同样可以利用时间进行度量。假设系统有M个session在运行，同一时刻，有的session可能在利用CPU，有的session可能在访问硬盘，那么，在一秒钟内，所有session的时间加起来就可以表征系统在这一秒内的繁忙程度，一般的，这个和的最大值应该为M。这其实就是Oracle提供的另一个重要指标：DB time，它用以衡量前端进程所消耗的总时间。

对除CPU以后的计算资源的访问，Oracle用等待事件进行描述。同样地，和CPU可分为前台消耗CPU和后台消耗CPU一样，等待事件也可以分为前台等待事件和后台等待事件。

DB Time一般的应该等于DB CPU + 前台等待事件所消耗时间的总和。等待时间通过v$system_event视图进行统计，DB Time和DB CPU则是通过同一个视图，即v$sys_time_model进行统计。

Load Profile一节就有了对DB Time的描述:

这个系统的CPU个数是8，因此我们可以知道前台进程用了系统CPU的7.1/8=88.75%。DB Time/s为11.7，可以看出这个系统是CPU非常繁忙的。里面CPU占了7.1，则其它前台等待事件占了11.7 – 7.1 = 4.6 Wait Time/s。DB Time 占 DB CPU的比重呢？ 7.1/11.7= 60.68%

Top 5 Timed Events，或许很多人都对它有所耳闻，按照CPU/等待事件占DB Time的比例大小，这里列出了Top 5。如果一个工作负载是CPU繁忙型的话，那么在这里应该可以看到 DB CPU的影子。

注意到，我们刚刚已经算出了DB CPU 的%DB time，60%。

其它的external table read, direct path write, PX Deq: read credit, PX Deq: Slave Session Stats这些就是占比重40的等待事件里的Top 4了。

回过头再再研究下这个Top 5 Timed Foreground Events，如果先不看Load Profile，你能说出这个一个CPU-Bound的工作负载吗？

答案是否定的，要知道系统CPU的繁忙程序，还要知道这个AWR所基于两个snapshot的时间间隔，还要知道系统CPU的个数。要不，系统可以是一个很IDLE的系统呢。记住CPU利用率 = DB CPU/(CPU_COUNT*Elapsed TIME)。

这个Top 5 给我们的信息只是这个工作负载应该是并行查询，从外部表读取数据，并用insert append的方式写入磁盘，同时，主要时间耗费在CPU的运算上。

上面提到，DB Time一般的应该等于DB CPU + 前台等待事件所消耗时间的总和。在下面有对这三个值的统计：

• DB CPU = 6474.65
• DB TIME = 10711.2
• FG Wait Time = 1182.63

明显的，DB CPU + FG Wait Time < DB Time，只占了71.5%

其它的28.5%被消耗到哪里去了呢？这里其实又隐含着一个Oracle如何计算DB CPU和DB Time的问题。当CPU很忙时，如果系统里存在着很多进程，就会发生进程排队等待CPU的现象。在这样，DB TIME是把进程排队等待CPU的时间算在内的，而DB CPU是不包括这一部分时间。这是造成 DB CPU + FG Wait Time < DB Time的一个重要原因。如果一个系统CPU不忙，这这两者应该就比较接近了。

不要忘了在这个例子中，这是一个CPU非常繁忙的系统，而71.5%就是一个信号，它提示着这个系统可能是一个CPU-Bound的系统。

如果关注数据库的性能，那么当拿到一份AWR报告的时候，最想知道的第一件事情可能就是系统资源的利用情况了，而首当其冲的，就是CPU。

而细分起来，CPU可能指的是

1. OS级的User%, Sys%, Idle%
2. DB所占OS CPU资源的Busy%
3. DB CPU又可以分为前台所消耗的CPU和后台所消耗的CPU

如果数据库的版本是11g，那么很幸运的，这些信息在AWR报告中一目了然:

OS级的%User为75.4，%Sys为2.8，%Idle为21.2，所以%Busy应该是78.8。

DB占了OS CPU资源的69.1，%Busy CPU则可以通过上面的数据得到：
%Busy CPU = %Total CPU/(%Busy) * 100 = 69.1/78.8 * 100 = 87.69，和报告的87.7相吻合。

如果是10g呢，则需要手工对Report里的一些数据进行计算了。

Host CPU的结果来源于DBA_HIST_OSSTAT，AWR 报告里已经帮忙整出了这段时间内的绝对数据(这里的时间单位是centi second,也就是1/100秒)

这里，

%User = USER_TIME/(BUSY_TIME+IDLE_TIME)*100 = 146355/(152946+41230)*100 = 75.37

%Sys  = SYS_TIME/(BUSY_TIME+IDLE_TIME)*100

%Idle = IDLE_TIME/(BUSY_TIME+IDLE_TIME)*100

值得注意的，这里已经隐含着这个AWR报告所捕捉的两个snapshot之间的时间长短了。有下面的公式

BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT

正确的理解这个公式可以对系统CPU资源的使用及其度量的方式有更深一步的理解。

因此ELAPSED_TIME = (152946+41230)/8/100 =  242.72 seconds

当然，这正确无误。

至于DB对CPU的利用情况，这就涉及到10g新引入的一个关于时间统计的视图了， v$sys_time_model，简单而言，Oracle采用了一个统一的时间模型对一些重要的时间指标进行了记录，具体而言，这些指标包括:

1) background elapsed time
    2) background cpu time
          3) RMAN cpu time (backup/restore)
1) DB time
    2) DB CPU
    2) connection management call elapsed time
    2) sequence load elapsed time
    2) sql execute elapsed time
    2) parse time elapsed
          3) hard parse elapsed time
                4) hard parse (sharing criteria) elapsed time
                    5) hard parse (bind mismatch) elapsed time
          3) failed parse elapsed time
                4) failed parse (out of shared memory) elapsed time
    2) PL/SQL execution elapsed time
    2) inbound PL/SQL rpc elapsed time
    2) PL/SQL compilation elapsed time
    2) Java execution elapsed time
    2) repeated bind elapsed time

我们这里关注的只有和CPU相关的两个: background cpu time 和 DB CPU。

这两个值在AWR里面也有记录:

Total DB CPU = DB CPU + background cpu time = 1305.89 + 35.91 = 1341.8 seconds

再除以总的 BUSY_TIME + IDLE_TIME

% Total CPU = 1341.8/1941.76 = 69.1%，这刚好与上面Report的值相吻合。

其实，在Load Profile部分，我们也可以看出DB对系统CPU的资源利用情况。

用DB CPU per Second除以CPU Count就可以得到DB在前台所消耗的CPU%了。

这里 5.3/8 = 66.25 %

比69.1%稍小，说明DB在后台也消耗了大约3%的CPU，这是不是一个最简单的方法了呢？

Automatic Workload Repository是10g引入的一个重要组件。在里面存贮着近期一段时间内，默认是7天，数据库活动状态的详细信息。

AWR报告是对AWR视图进行查询而得到的一份自动生成的报告。可以通过下面的脚本手工得到一份AWR报告。

exec dbms_workload_repository.create_snapshot;
... running the specified workload
exec dbms_workload_repository.create_snapshot;
@?/rdbms/admin/awrrpt

通过AWR和AWR报告，DBA可以容易地获知最近数据库的活动状态，数据库的各种性能指标的变化趋势曲线，最近数据库可能存在的异常，分析数据库可能存在的性能瓶颈从而对数据库进行优化。

AWR报告所有的数据来源于AWR视图，即以DBA_HIST_开头的所有系统表，Database Reference有对所有这些系统表的描述，这应该是Oracle官方对AWR报告的官方注释了。

而对于如何有效地去分析AWR报告，这可能更需要DBA经验的日积月累。

AWR的前身是Statspack，Statspack在10g和11g中也有提供，同时和AWR一起做了同步更新，而且Statspack是公开源代码的，因此，关于Statspack的资料，还有Statspack的源代码，都是理解AWR的一个有用的辅助。

本系列文章准备着重对AWR中的一些要点进行剖析，欢迎一起讨论AWR相关的问题。

这是11g引入的一套新的自动化机制。Oracle的官方文档大而全，不过想理清楚里面的来龙去脉可不是一件容易的事情。

不过下面几点知识要点是应该记住的。
1. Oracle有三个已定义好的automated maintenance tasks.

1. Automatic Optimizer Statistics Collection—用于收集各种数据库对象的统计信息。这里又有三种模式：
   • ‘ALL’ – Statistics are collected for all objects in the system
   • ‘ORACLE’ – Statistics are collected for all Oracle owned objects
   • ‘AUTO’ – Oracle decides for which objects to collect statistics
      
   • 可以通过以下API进行设置

           DBMS_STATS.SET_GLOBAL_PREFS (
             pname VARCHAR2,
             pval VARCHAR2);

       pname为”AUTOSTATS_TARGET”，pval为以上三个值之一。

2. Automatic Segment Advisor—Identifies segments that have space available for reclamation, and makes recommendations on how to defragment those segments. You can also run the Segment Advisor manually to obtain more up-to-the-minute recommendations or to obtain recommendations on segments that the Automatic Segment Advisor did not examine for possible space reclamation.
3. Automatic SQL Tuning Advisor—Examines the performance of high-load SQL statements, and makes recommendations on how to tune those statements. You can configure this advisor to automatically implement SQL profile recommendations.

2. 这些automated maintenace tasks在maintenance windows里得到执行。同样，Oracle已经定义好的7个windows，对应每周的每一天。周一到周五是从22:00到次日的02:00，周六和周日是从06:00到次日的02:00。

3. 如果不想这些automated maintenance tasks在一些windows里不被执行，或者完全不希望执行这些tasks。可以通过下面的API。

DBMS_AUTO_TASK_ADMIN.DISABLE(...)

4. 对于maintenance windows，系统会切换到相应的resource plan。如果你不想你原来的resource plan 被切换掉的话，记得在你设置resource plan时，在resource plan的名字前面加上force:。如下面所示：

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'FORCE:mydb_plan';

自动化是个好东西，不过这建立上你正确理解了它们的基础上，要不有时就会出现莫名其妙的结果了。

举个简单的例子：如果你在某个时候truncate了一个表，之后重新加载了海量的数据，如果在你truncate后,加载数据之前，收集统计信息的任务启动了，那么它会把这个表的统计信息更新为空表的数据。于是，你的很多涉及到这个表的SQL语句就会莫名其妙的慢下来甚至于执行不完了，原因就在于统计信息的错误变化(海量->空)，导致CBO对很多语句从原来的索引访问者变成了致命的全表扫描了。