本文要分析的是下面这个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;

近来越来越觉得自己有种回归过去的感觉。

在2007年底开始想os2ora这个名字时其实是这样解释的: os2分别代表Operating System和Open Source， ora当然是代表Oracle了。后来2009年初自己把os2ora简化为OS与Oracle。不过，现在又开始觉得其实这里的东西有些还是与Open Source密不可分的。

同样的，在2009年初，自己定的目标是专注在OS与Database的性能监控与调优上面。现在又觉得其实这里面很多东西涉及到系统架构，软件设计方面的东西，而关于系统架构与软件设计的理论其实在2006年之前的某段时间就比较系统的了解过了。

也许这也算是自己在软件领域思想认识的一个迭代过程吧，但愿这次回归是去除了浮躁的一次真正的回归。

与回顾相比，其实展望更有其实际意义，起码可以做为一个前进的指引标志。为了证明自己或许更擅长于右脑思维:-)，还是以一个思维发散图做下展望吧。

os2ora.com过去的文章应该基本上可以在上面这个图中找到对应的位置。而2010年的文章应该也逃不出这个框架罢。

或许随着自己的进一步迭代，这个思维发散图就会变成2.0版的了，期待这种变化!

2009年基本上是属于Exadata的一年，随着在中国的第一个大型的Benchmark拉开序幕，这个benchmark基本上涵盖了所有Benchmark可能涵盖的内容，比如:

• Data Loading
• Data ETL Processing
• DSS Queries
• OLTP Stress Testing
• DSS Stress Testing
• Mix-workload Stress Testing
• Ad-Hoc Queries
• Scalability Testing
• HA Testing

一个Benchmark，基本上离不开这些方面，当然，这些方面也是一个典型的数据库系统(DSS)进行设计与实施时必须考虑的主要方面。在这些不下5个benchmarks中的经验的积累应该是2009年的一笔很大的财富。

经验的分享是2009年的另一个主题，当然主要还是关于Exadata，既有和站在市场前线的销售支持团队的分享活动，也有和主要客户的经验交流，每次分享都带来了意想不到的收获，认识了更多志同道合的朋友。同时，一方面开阔了自己的视角，一方面也让自己以后的工作更有针对性。

另一个成绩可能是对os2ora.com的更新，从2009年3月份改版以来，基本上坚持了一周一篇文章的频率，好象与开始自己的预期挺接近的。更重要的是，通过对网站的维护，使自己对web 2.0有了更深一步的体会，同时也让自己成为了google reader的忠实用户(My Google Profile)。对os2ora.com的更新，现在看来，只是属于知识的获取与分享中的一个环节而已了。在知识分享领域，期望2010年会做得更好。

工作当然不是2009的全部，在这里，我更愿意分享一下在2009里面用相机拍到的精彩瞬间，期望能带来一点亮丽的光彩。

香格里拉, 普达措

丽江，黑龙潭公园

早上5点钟的Angel Fall,世界上落差最大的瀑布。

珊瑚群岛Los Rogues，加勒比海上的一颗明珠。

随着业务的发展，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功能的。

周末翻阅了以前写在msn space上的文章，不经意间找到了一篇2006年写的关于Linux内核的文章，那时想不到自己会变成一个Database Performance Engineer，不过里面的一些观点却和现在的工作不谋而合，只不过那时面对的Linux Kernel，现在面对的却是Oracle Database，看来有一些根本的东西是不会变的。

quote begin“

最早接触Linux内核是在大三的时候，那时《操作系统》的课程设计就是进行Linux内核源代码的分析与进程调度的改进。题目是大的有点吓人，特别是对那时一个涉足未深的年轻人看来。不过那时做的事情很简单，认认真真的看了《Linux内核源代码情景分析》的前言部分（主要讲的AT&T汇编语言，内核中一些特殊的编程规则），与进程调度相关的部分，包括进程的管理，进程的切换，进程与中断，软中断，系统调用，进程互斥与同步机制。并画了几张图阐述了进程调度的路线，对spinlock机制进行了深入的剖析。明白了2.4的内核为何是非抢占式内核，进程调度器其实也不是什么神奇的东 东—— 一个函数罢了，啥叫process context。同时，为了完成“进程调度机制的改进”，看了实现可抢占的两个补丁，哦，现在已经整合进2.6了，也怪不得昨天看2.6进程调度的介绍有种似曾相识的感觉。

可以说，那时的分析完全是理论学习。对于内核编程的实践几乎没有。带来的好处最主要的在于提高了对操作系统运行的认识与提高了代码的阅读能力。

回头去看这段往事，总觉得存在着有所改进的地方。

现在看来，内核是啥呢？只是一个比较大的软件项目，可以拿它与Eclipse相比，或者mplayer相比，或者就是与任何一个开源软件处于同层次的东西，只是它更具复杂性，涉及到的软件与硬件的东西更全面罢了。

或者说，经过这几年对开源项目的接触，对软件项目的参与，Linux内核在我心目中的神秘感已然消失，Eclipse在软件架框方面应该可以算出类拔萃，EFI在BIOS这一层上也实现了新的可扩展的和良好的设备管理模型，而Linux在操作系统的层次上也应该是一个典范，值得去学习，去揣摩，去玩味。

2.6内核之于2.4内核，无疑是前进了一大步，进程调度，设备管理等等方面都形成了更良好的framework。同时也涌现出了好多优秀的传道士及其杰作，如《Linux Kernel Development Second Edition》《Linux Device Driver Third Edition》。我更想把这些带有浓厚实践性质的书籍当做进入Linux 内核世界的一个极佳的“切入点”。想起Eclipse世界一本与此类似的书《contributing to eclipse》，一个提倡的规则就是“MONKEY SEE/MONKEY DO RULE Always start by copying the structure of a similar plug-in.”。从内核中学习内核，增强内核，应该是内核编程的一个原则。

不可否认地，“情景分析”是《Linux内核源代码情景分析》的一个亮点，为过去乏味的Linux内核源代码阅读注入了一丝亮色。可是，不管怎样，这还是一个静态的过程，我更期望能从一个动态的系统中获取关于她的内幕与运作规律。

所以，如果能够设想出一些观测内核运行的切入点，并藉此实现对内核机制的动态掌握，真真切切感知内核的运行，有时更能得出一些独具特色的结论进而做出更进一步的改进。

例如对内核调度机制的分析，有以下几个简单的问题：一秒钟内内核大概会做多少次进程切换。系统一般会存在着哪些进程，哪些系统因素会显著地加剧进程切换的次数。这些进程的运行与时间存在着怎样的分布关系（即进程与时间的函数关系）。通过在内核代码中加入相应的进行统计的代码，就可以画出这种函数图出来。再通过对它的分析，就更能从中发现出一些共性东西，数学性的东西，改进的空间。

内核中的调试机制，是与内核打交道首当其冲的问题，也是进行窥探内核的途径。做为一个工具，是实现此种学习的一个必经之路。如printk，如proc文件系统等。

而实践的过程，就是一个发现问题的过程，bottom halves有几种机制，softirq, workqueue, tasklet,他们之间有哪些区别，timer的实现有哪些，在进行实践的过程中，必定会碰到这些问题，并会主动地去寻找这类问题的答案，最后的结果就是自己编写的代码能够良好的运行于内核之中。

这里有另一问题，在内核中是否可以调用一般的系统调用？如open,close,read等等。会存在什么问题？又当如何解决？呵呵，当一个一个的问题被你解决之后，与Linux内核之间的接触又亲密了一层。

从实践中来，到实践中去吧。

当从一个业余者的角度来看Linux内核时，我想，有趣才是最好的导师，寓学于乐吧。

“quote end

遗憾的是，自从做完了研究生的毕业论文之后，就基本上不去做Linux Kernel相关的东西了，但从现在一个Database Performance Engineer的观点看，那时的一些想法和现在的工作还是有一些共性的。比如从一个动态的系统中获取关于她的内幕与运作规律; 通过在内核代码中加入相应的进行统计的代码，就可以画出这种函数图出来,再通过对它的分析，就更能从中发现出一些共性东西，数学性的东西，改进的空间; 内核中的调试机制，是与内核打交道首当其冲的问题，也是进行窥探内核的途径,做为一个工具，是实现此种学习的一个必经之路。如printk，如proc文件系统等。

在做Exadata相关的培训时，Ad-Hoc Query是经常被提及的一个词，中文的翻译应该就叫做随机查询吧，望文生义，就是随机的，不能预料到的查询。但究竟有多随机呢，一些活生生的例子可能更能说明问题。

我们组设计了一个查询，每次show出来的时候，底下总有人暗底里偷笑不止。挺好玩的一件事情。这个查询是这样的：

我们要查询在2009年5月份第一个星期在北京市的所有百货超市里最受某一类型的消费者欢迎的前十个商品，这一类型的购物者有以下的购物癖好：购物的时候不买banana。

这个查询其实是基于一个零售业系统，里面存贮着全国所有超市的交易记录，这是一个TB级的数据库。如果有人说他能通过设计索引让这个查询跑得飞快，我可真不敢相信。

这种查询是有可能的，或许某天某位业务经理就跑到你(DBA)面前，帮我查查…，多久能给我结果？你的答案会是分钟，小时，天，还是月呢？

做个类推，中国移动版的:

我们要查询在2009年5月份第一个星期在北京市最受某一类型的手机用户欢迎的前十个热线号码，这一类型的手机用户有以下的癖好：发送的短消息里面从没有出现过类似”I love you”的语句。

或者你可以针对任一个数据库系统构造出类似的ad-hoc查询语句了。

有一次跟一个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报告进行分析可能会更加方便和清晰。