到了10g的时代，cardinality feedback这个词正在变得越来越流行。我想，开始导致这个词流行的或许不是来自Oracle官方的推广，而是来自Wolfgang Breitling在Hotsos Symposium 2006上的一个演讲: Tuning by Cardinality Feedback: Method and Examples. 从作者的网站有下面的信息:

Tuning by Cardinality Feedback

Tuning by cardinality feedback looks at discrepancies between estimated and real row source cardinalities of an execution plan and attempts to find ways to correct the CBO’s error in estimation and trusting it to find a better plan based on the corrected, more accurate estimates.

Faced with an underperforming SQL, the question the TCF method is trying to answer is not
    What would be a better access plan?
But instead
    Why is this plan, which the CBO chose as optimal, performing so poorly?

Once the answer to that question is found, the next goal is to find a way to remedy the cause for the miscalculation, but ultimately get out of the way and let the CBO do its job again.

The presentation was given at the 2006 Hotsos Symposium on Oracle® System Performance March 5–9, 2006 in Dallas, Texas and at CBO Days June 21-22 in Zurich, Switzerland.

Paper  Presentation

这种方法，也是我们平常调优SQL的最主要方法。虽然以前没有专门介绍过，不过有一些文章还是偶尔提及的，例如这篇: 11gR2出色的SQL Monitor Report, 提到了用SQL Monitor Report查看actual rows与estimate rows的方法。

网上的另一个介绍cardinality feedback的演讲可以参考这一篇，http://jonathanlewis.wordpress.com/2009/05/11/cardinality-feedback/,作者是Michelle Deng，Sanofi Aventis.注意这里已经是2009年的事情了。

看看Oracle内部开发人员的演讲吧，这是VLDB 2008上的一个演讲.

Allison W. Lee, Mohamed Zaït: Closing the query processing loop in Oracle 11g: Paper, Presentation

这俨然成为了11g的一个new feature，如何你手头有Oracle 11g，你甚至现在就可以演练一下。

下面是一个用到了cardinality feedback的执行计划，注意最后一行: cardinality feedback used for this statement

---------------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name                         | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                              |       |       | 98089 (100)|          |
|   1 |  SORT ORDER BY                 |                              |     1 |    97 | 98089   (1)| 00:19:38 |
|*  2 |   HASH JOIN                    |                              |     1 |    97 | 98088   (1)| 00:19:38 |
|   3 |    VIEW                        | VW_NSO_1                     |     4 |    36 | 47108   (1)| 00:09:26 |
|   4 |     SORT UNIQUE                |                              |     4 |   148 | 47108  (51)| 00:09:26 |
|   5 |      UNION-ALL                 |                              |       |       |            |          |
|*  6 |       TABLE ACCESS STORAGE FULL| TA                           |     2 |    62 | 23549   (1)| 00:04:43 |
|*  7 |       TABLE ACCESS STORAGE FULL| TA                           |     2 |    86 | 23558   (1)| 00:04:43 |
|*  8 |    TABLE ACCESS STORAGE FULL   | TB                           |   469K|    39M| 50978   (1)| 00:10:12 |
---------------------------------------------------------------------------------------------------------------
 
....
 
Note
-----
   - cardinality feedback used FOR this statement

可以google下”cardinality feedback”。会有人其它人的演练报告。

想想吧，以后的DBA，回顾这段历史，想想以前的人们如何用手工的方法用cardinality feedback 进行调优，是不是会和我们现在想着过去人们如何用手工方法进行space management, memory management的场景类似？ evolving, evolving, evolving…

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