关于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.

准备写一系列的文章，专门分析下Exadata的架构。时间真过得很快，自从Exadata问世以来，一直围绕着它做各种各样的性能测试，从V1过渡到V2。Exadata在大踏步地前进着，我总认为，这应该是一个很优秀的产品，而我也相信时间会证明这一点的。

这些文章不会有很严谨的结构，或许某天，某时发现的一个特性，一个特点，一个最佳实践，一个有意思的地方，一个令人惊讶的数据，一个令人鼓舞的图形，都会成为这一系列文章的一部分。

Flash Cache是V2里引入的一个特性，大家或许都认为Flash Cache 主要是用于OLTP场合，为OLTP提高更高的IOPS，这点当然没错，Flash Cache相比于一般磁盘，会带来上十倍的IOPS的性能提升。但即使对于DSS场合，Flash Cache也是提升性能的一个利器。

下面是看图说话时间。

左图中，MBPS达到了4.5 GB/s。但是存贮节点上的CPU和数据库节点上的CPU的利用率却在20%左右。如果在存贮节点加入Flash Cache，整个系统会发生什么样的改变呢？右图就是加入了flash cache后的CPU/IO情况。MBPS达到了14G/s，存贮节点的CPU利用率超过了60%，DB节点上的CPU利用率也超过了40%。

仔细地对比研究这个图，对系统间资源的协作会有进一步的认识。

可以说, Flash Cache除了提供更高的带宽外，还大大解放了存贮节点上的CPU处理能力。这种处理能力可是单纯的高端存贮都不具备的，这就是Exadata上独有的Smart Scan特性。Exadata V1实现了对磁盘的Smart Scan，而V2则实现了对Flash Cache的更快，更强大的Smart Scan。当然，在软件设计上，还有另一个重头戏，它更是大大的利用起了存贮节点上的CPU处理能力，同时还能减少对带宽的争用。至于更具体的信息，留在另一篇介绍啦。

除了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报告进行分析可能会更加方便和清晰。

如果问我Exadata给我的最深刻印象是什么？我脑海里最先浮现的莫过于每秒14GB的IO吞吐量。Exadata有14个Cell Node,我们以每行一个节点的方式显示其IO/CPU的使用情况，并每隔5秒刷新一次，当每行都持续显示着1100MB/s，最后一行显示TOTOAL 15000MB/s时，心里唯一的感觉就是兴奋，就是觉得不可思议。

曾记得第一次做数据仓库的benchmark时，用的是HP的HP-UX上的Oracle 11g。硬件是SuperDome加上两个EVA8100。那时最大的遗憾莫过于IO老上不去，总IO能上2.5GB/s已经是觉得兴奋不已了！

说到吞吐量，另一个不得不说的当然是CPU的处理能力。Exadata有8个Compute Node。其实就是数据库Instance所在的Server。也就是说，这是一个8节点的RAC。每个节点是两个4核的Intel Xeon CPU, 2.66GHz。因此，整个cluster总共有64个CPU/core。

说到不可思议，今天和同事闲聊时发现还有更加不可思议的事情。Steven的亲身经历，在现场，客户突然拿出几条SQL，说是一般情况下要跑几小时甚至几天的，Greg被他吓了一跳，想不到的是在Exadata上不到几分钟就跑出来了。还有Mike说的另一个例子，最不可思议的事情莫过于客户拿着一个从未跑出结果的SQL过来，在Exadata上不到十分钟就跑出来了!