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

Job description:

Real World Performance Group is part of the Oracle Database product management team. We do customer benchmarks and post-product escalations to help to shorten sales cycle, to make quality insurance of the Oracle database product, and master the competitive intelligence of the Oracle database product. We are a global team including people in US, EMEA and APAC and we need people to cooperating with people in other time zones.

Responsibilities:

1. Perform database benchmarks 
2. File bugs and get rapid resolutions 
3. Cooperate with other people in a global team 

Qualifications

1. Bachelor or master degree of computer science, or have firm computer science basic knowledge 
2. Deep understanding of Oracle database and operating system 
3. Skilled in SQL tuning 
4. Proficient in writing shell scripts 
5. Minimum 3 years of work experiences, better in DBA area, SQL development area or OS area 
6. Self-motivated and can work under tight timeline 
7. Good team work spirit and can work in a global team 
8. Fluent in English and Mandarin 

How to Apply

Send your English C.V. to kaiyao.huang##oracle.com and/or christine.qu##oracle.com

做下回顾与思考。

从第一篇开始到现在，Cell Flash Cache, Exadata Hybrid Columnar Compression, Storage Index轮番上场，加上V1版本里出现的Smart Scan，Infiniband等等，多少会给人以眼花缭乱的感觉。

最根本的一点，当然在于Exadata本身是一个balanced system。

不过，这些技术做为一个整体对实际应用会带来多大的好处呢？这不是一个很好回答的问题，当然也可以用一句话回答——具体问题具体分析。

思路应该是这样的，首先明了当前系统的现状

• 如果当前系统运作得很好，简直完美的设计，分区，并行，并发控制等都无可挑剔，业务量也没超过系统极限，那么也许只有一些技术会对性能提升比较明显，如Smart Scan。举个例子，如果原来系统没存在IO上的瓶颈，Cell Flash Cache就英雄无用武之地了。
• 如果当前系统运作得很好，简直完美的设计，分区，并行，并发控制等都无可挑剔，业务量大大超过系统极限，系统出现CPU或者IO或者Network上的瓶颈了，这时或许就是考虑升级的时候了。
• 如果当前系统为小数据量所设计，如刚开始没有分区，但随着业务量的增长，系统出现CPU或者IO或者Network上的瓶颈了，这时可以有两条途径，改进原来的设计，或者考虑硬件升级了。

设计上的改进包括

• 分区
• 压缩
• etc.

硬件上的升级包括

• Smart Scan
• Flash Cache
• Storage Index
• etc.

最后，做为一个例子，可以考核一个原来的系统（没分区，没压缩，没Flash Cache，没Storage Index），分区，压缩，Flash Cache，Storage Index，分别能带来的性能上的提升，及做为一个整体带来的性能提升。

感性认识还是更重要的，虽然我把它放在最后面了。

Exadata上另一个聪明的软件设计是实现了storage index.

另一篇白皮书中有对Storage Index的一个描述 A Technical Overview of the Sun Oracle Exadata Storage Server and Database Machine

Storage Indexing

Storage Indexes are a very powerful capability provided in Exadata storage that helps avoid I/O operations. The Exadata Storage Server Software creates and maintains a Storage Index in Exadata memory. The Storage Index keeps track of minimum and maximum values of columns for tables stored on that cell. When a query specifies a WHERE clause, but before any I/O is done, the Exadata software examines the Storage Index to determine if rows with the specified column value exists in the cell by comparing the column value to the minimum and maximum values maintained in the Storage Index. If the column value is outside the minimum and maximum range, scan I/O for that query is avoided. Many SQL Operations will run dramatically faster because large numbers of I/O operations are automatically replaced by a few in-memory lookups. To minimize operational overhead, Storage Indexes are created and maintained transparently and automatically by the Exadata Storage Server Software.

如果Exadata给你的印象就是有很强大的硬件，却不会利用传统的性能优化方法，比如索引，去加快查询速度的话，那么Storage Index的出现或许会改变你的这种观念。而且，storage index是完全自动化的，它甚至不需要人工的干涉就能工作得很好。

Smart Scan之所以冠名以Smart，是因为它在扫描数据的时候同时做过滤操作，只把必需的数据返回给数据服务器端；而Storage Index在这里却直接避免了对Disks的访问，其Smart的程度与Smart Scan相比，或许已经到了超凡脱俗的境界了。

如果真要找一个类比的话，DB2中有个特性或许可以与Storage Index做下对比，那就是Multi Dimensional Clustering. 仔细阅读下MDC的介绍，两者真的有异曲同工之妙。

下一个要出场的是HCC, Hybrid Columnar Compression. 目前它是Exadata上面才有的一个特性，所以又叫做Exadata Hybrid Columnar Compression。

在Exadata V2 架构分析 (1)中，曾提到“在软件设计上，还有另一个重头戏，它更是大大的利用起了存贮节点上的CPU处理能力，同时还能减少对带宽的争用”。Exadata的很多设计，或许从根本上讲，就在于充分利用起存贮节点上的处理能力，Smart Scan和这里所要提及的HCC，就是两个典型的代表了。HCC中文翻译过来或许就叫做混合列压缩，它是在单纯的行存贮和列存贮之间取得的一个折衷。

一个比较好的参考文档是这篇白皮书Exadata Hybrid Columnar Compression.

上图中，典型地，4个8KB的blocks被当成一个Compression Unit。在这个CU所能存贮的rows中，每个column被分开存贮。可以想像到，每个column里的内容是很相似的，如果与row之间的内容做比较的话。于是，对每个column的内容进行压缩，会得到很好的压缩率。根据压缩算法的不同，Oracle提供了四种不同的压缩等级，详见上面提到的白皮书，这里就不详细列出了。

到底EHCC的压缩率可以达到多少呢？白皮书中提到两个数据，可以做为参考，对于Warehouse Compression，有10x的压缩率，对于Archive Compression，有15x的压缩率。

EHCC相对于单纯的Column Compression而言，有一个极其突出的优点，这点是不得不提及的。当进行行级访问数据时，如根据rowid返回一行数据，EHCC只要一个IO就够了，不管所访问的表有多少列，而对于单纯的Column Compression而言，对于每个Column，都必须有一个IO操作。那么，随着表设计的复杂，如一个表拥有成百上千列，两种存贮方式的性能就能体现出成百上千倍的差距了。

RWP(Oracle RealWorld Database Performance Group)准备在中国多招一员干将，有没朋友有兴趣。工作地点最好在深圳，北京也可以接受。工作内容主要在于性能调优(OLTP/OLAP)还有可扩展性方面，希望有这方面比较丰富的经验。

仅仅是先做个不正式的预告，不过有兴趣&&有疑问的朋友也可以给我发邮件。

在检查客户的代码中，有时会深刻地感觉到原代码编写者在调试代码时的无奈。

这使我想起以前调试代码时的经历。一个SQL迟迟不返回结果，一小时过去了，又一小时过去了…… 于是，想了好多调优的方法，调整系统参数，为这个SQL建立很多Index，加上各种各样的Hint ……

于是，现在在代码中看到似曾相识的/*+ index(t_xx, idx_xx) */时，有时会发自内心的笑了，同时，轻巧地把里面的+号删掉了，我就让这些个hint不起作用，不强迫CBO走index了，结果当然是CBO选择了Hash Join，而不是原代码编写者指定的Nested Loop，于是，执行速度嗖一下上去了。

还有另一个有趣的事情，对大表的操作DSS查询或DML操作，检查客户的执行计划，无一例外地没有用并行查询或者并行DML，当然，里面会用到很多类似上面的/*+ index(t_xx, idx_xx) */。于是，心里很纳闷，这样跑DSS查询或DML操作，要跑到啥时候才跑完啊？有趣的地方在于，发现了原代码编写者的一个可能的workaround，对大表进行分割分片处理，一次跑不完，我跑它个几百上千次还可以吧。很聪明的做法，不过也感觉到一阵阵深深的无奈。

不可否以地，很多客户有很复杂的业务逻辑要处理，DBA们和开发者们也很聪明地运用着Oracle的技术。编写的代码质量其实也是可圈可点的。不过，在代码实现与现实世界之间，我们却不得不面对一个折衷，优雅的代码，在糟糕的机器配置之前，只能无能为力，于是，过度的调优也就理所当然，顺理成章的成为了主流。

或许，我们的DBA们要主动地进行呐喊；或许，我们还需要有这样的职位，能够从大局上对系统进行规划，包括对系统硬件的容量规划，系统软件实现上的总体设计，最佳实践上的运用等等；或许，也应该是架构师工作的一部分？

之前曾提到如何利用SQL Monitor Report对SQL进行诊断与调优，对于具体的SQL调优而言，SQL Monitor Report提供的信息无疑比AWR更有针对性，当然，AWR在信息的全面性方面会更胜一筹。本文提供一个具体的例子，同样的SQL，同样的执行计划，第一次执行的时间远远大于第二次执行的时间。

SQL Monitor Report详细提供了SQL执行所消耗的系统资源曲线，每一步骤的显著等待事件。通过对比上面两种情形下的系统资源曲线，执行计划中提供的等待事件分布，基本上应该可以诊断出第二次执行为什么比第一次执行快的原因。

下面是两个Reports的链接，你不妨试着对比对比。也借此体验下11.2 中的SQL Monitor Report在展现信息方面的灵活性(让鼠标指向每一个可能隐藏信息的地方，如每个可能的bar)。

• 第一次执行的SQL Monitor Report
• 第二次执行的SQL Monitor Report

关于Cell Flash Cache，好象大家都余兴未尽，例如：
1. 一个真正的生产系统，真的需要1,000,000 IOPS吗？
2. Cell Flash Cache对用户带来的真正的好处在哪里？

假设用户的逻辑IOPS达到1,000,000 IO/s. buffer cache命中率为98%。则落在Cell Flash Cache中的IOPS为20,000次。这个数据对于1/4配，即一个quarter的Exadata来说，当然是小菜一碟，不过对于一般磁盘呢？一般的磁盘每秒大约为300 IOPS，这意味着需要有20,000/300=66个磁盘，这已经是一个不低的配置了。

再进一步考虑，如果系统想支持混合负载，即系统同时支持数据仓库查询和OLTP在线系统。那么这时OLTP的性能将会受到严重影响。要知道，数据仓库查询要求的MBPS，而OLTP要求的则是IOPS，这两个指标是会相互影响的，用户一般考虑的是OLTP优先。甚至于出现一种情形，我不清楚下面这种情况会多普遍：

在IO受限的情形下，不敢对OLAP查询启用并行，由于不启用并行，OLAP查询很久不返回结果，进一步地，用户会在表上建更多的索引来“优化”这些OLAP查询。最终，整个混合型的系统就变成了一个类似OLTP的系统了。

在这种情形下，Cell Flash Cache或许会带有性能上的实质提升，通过Flash Cache会大大提升OLTP的查询性能，同时，后端的磁盘和Flash Cache会一起提供足够的带宽给OLAP查询(很聪明吧)，这在硬件上保证了两者并存的可能性。另一方面，由于在IO上的财大气粗，对原有OLAP的过度优化终于可以停止了，系统设计因些会回归简单，与此对应地，系统维护成本也会大大降低。

或许这是Cell Flash Cache可能给大家带来的一个很诱人的地方。

既然提到了Flash Cache,如果不提下对OLTP的提速好象会缺少点什么。对OLTP系统而言，缓存是一个极其重要的设计，不管是数据库节点上的内存上的Buffer Cache，还是存贮节点上的Flash Cache（Exadata)，还有数据库节点上的Flash Cache(某些平台，如Linux)。

前几天在Eygle的性能调优课程上听过他提过的一句话，缓存为王（致敬，呵呵），深以为然，这应该是他极其重要的实践总结，对于OLTP系统而言，这真是一点不为过。

下面的表格列出了一个实际场景，分别测试了不同的buffer 命中率和引入Flash Cache之后的性能变化。

上面的三行对应的OLTP负载是相同的，但总的执行时间却是大大不同的，从2分多钟到10几秒到2秒。唯一的区别就在于Cell Flash Cache, Buffer Cache 的介入。

上面这些数据起码可以得出几个结论：

1. Buffer Cache会减少CPU Time,但Cell Flash Cache不会。这从另一个方面说明，IO调度是需要CPU的。

2. Cell Flash Cache和Buffer Cache都大大减少了User IO Time。最终的结果就是大大提升了响应时间，例如上面我们得到了从13倍到158倍的性能提升。

3. Cell Flash Cache和Buffer Cache都提高了DB节点的CPU利用率。例如上面我们的CPU利用率从3%提高到36%和61%。

Exadata V2宣传的一个令人惊诧的数字之一是每秒钟一百万个8K的随机IO。很恐怖吧，1,000,000 IO/s.

其实，如果只是进行读操作而没有写操作的话，这个数字会更令人恐怖。下面是一个截图。把里面的峰值(300k)除以3乘以14，就得到整个机器14个cell可以达到的一个IOPS: 1.4 million IO/s.