到了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…

direct read是直接把数据块读到PGA的一种操作，在并行查询中这是唯一的模式。这明显地区别于非并行查询把数据块读到SGA的做法。读到SGA的目的主要是为了共享，这特别适用于OLTP场合。不过，与此同时，访问SGA会引入更多的latch等待，例如cache buffer chains, cache buffer lru等等。

在非并行查询中也可以使用direct read，可以通过一个隐含参数_serial_direct_read进行设置。

值得注意，_serial_direct_read对解析过程起作用，这意味着为了使_serial_direct_read对当前运行中的SQL起作用，我们必须先flush当前的shared_pool。

11g中，Oracle有了一个自适应的算法决定是否对serial execution启用direct read。不过，这是在运行时才决定的。它取决于多个统计信息，例如当前buffer cache的大小，_small_table_threshold的大小，当前dirty blocks还占的比例等等。因此，即使在11g中_serial_direct_read的值为false，serial direct read也可能起作用。这个算法其实就叫做Adaptive Direct Read.

下面是两个模式对资源的利用情况对比:

当使用direct read时，cache buffers chains明显减少，但物理读每次都保持恒定。对于传统方法，物理读只发生在第一次执行时。

对于等待事件也有所不同，direct read的等待事件是’cell smart table scan’，而非direct read的等待事件是’cell multiblock physical read’。这体现出Exadata的独有的优势: direct read可以利用Exadata的smart scan功能，从而实现把DB节点的CPU负载offload到存贮节点上。

一些Tips:

利用下面这个event 可以disable 这个特性:

alter session set events '10949 trace name context forever, level 1';

在10G, Oracle已经有了Database Resource Manager，在数据仓库中，有两个系统资源非常重要，它们可以通过DBRM进行控制，它们就是Active Sessions和DoP(Degree of Parallelism)。一般而言，不同的工作负载会有一个最优的Active Sessions和DoP。甚至于有时必须对工作负载再进行细分，分别应用不同的策略(active sessions + DoP)。这有时是一个烦琐的调优过程。

在即将到来的11G中，有两个新的特性，Auto DoP和Statement Queuing机制。相信对上面的DBRM会带来一定的冲击。

“Storage Index”，对Oracle中已有的Index大家耳熟能详，B-Tree Index, Bitmap Index。这些都是基于行的，有没基于更大的存贮单元的呢？例如1M的存贮区域？Storage Index来了，这以于Cluster的列而说，pruning功能会使一个查询提高成千上万倍。这可能又是一个后来者居上的特性。

“Hybrid Columnar Compression”, 不甘落后的，又一个Oracle新引入的技术。对于数据仓库查询这无疑是天大的福音。

还有很多很多……

就让我们一起疯狂吧!