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操作。那么，随着表设计的复杂，如一个表拥有成百上千列，两种存贮方式的性能就能体现出成百上千倍的差距了。

既然提到了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处理能力，同时还能减少对带宽的争用。至于更具体的信息，留在另一篇介绍啦。

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';

前面分析的主要是Exadata如何高效地进行计算。通过在存贮结点加入数据处理能力，Exdata不仅大大地提升了处理性能，而且解决了以前的Oracle架构上可能存在的CPU和网络的瓶颈问题。

一个Database Machine有8个DB节点，14个Cell (存贮)结点。在V1版本中，一个Cell可以提供1GB/s的带宽，14个Cell节点总共能提供的带宽为14GB/s。对于8个DB节点，每个节点都是两个CPU，每个CPU 4 个Cores。所以一个Database Machine中DB节点总共有64个Cores。

8 DB Nodes + 14 Cell Nodes = Balanced System

这是一个经过实践证明过的平衡的一个配置。对于一个典型的DW并行查询，类似我们在第一篇文章里提到的，也就是下面的这个查询:

SELECT a.no,
       sum(case
             when a.KEY IN ('A') then
              a.score * 2
             else
              a.score * 5
           end) score1,
       sum(....
           ...
              ) scoreN
  FROM fact_table a
 GROUP BY a.no
;

在运行的大部分时间，DB节点的64个Cores保持100%的利用率，14个Cell节点的总IO吞吐量保持在14GB/s上。

记得今年9月底和阿里巴巴的DBA的一个关于Exadata的交流活动上，新成立的阿里云的同事也到场了。Exadata的架构引起了大家的共鸣，会后一个反应是，有人觉得Exadata与云计算有些异曲同工之妙。其实这也难怪，Exadata本来就是一个关注大规模并行计算的集群系统。特别是智能的存贮节点的引入，更使得每个存贮节点能够分担一个大计算里的一小部分，并且这些智能的存贮节点还有线性的可扩展性，当需要更好的性能时，只要简单地相应增加存贮节点和/或DB节点就可以实现了。这难道不是一个“云计算”的例子吗？

下一个问题，Exadata如何解决CPU方面的瓶颈呢？

在Exadata之前，我想无非两种思路，第一在原来节点上用更多更强的CPU，第二采用更多的RAC节点。

不过在Exadata的架构中，CPU的瓶颈已经从基本上得到很大的缓解，这就是存贮节点上CPU处理能力的介入。

还是以一个实际SQL为例:

SELECT t0.id
   FROM
  (SELECT id
 FROM t0
    WHERE id LIKE '%54234245%'
  ) t0,
  (SELECT id
     FROM t1
    WHERE id LIKE '%54234245%'
  ) t1,
  (SELECT id
     FROM t2
    WHERE id LIKE '%54234245%'
  ) t2,
  (SELECT id
     FROM t3
    WHERE id LIKE '%54234245%'
  ) t3,
  (SELECT id
     FROM t4
    WHERE id LIKE '%54234245%'
  ) t4,
  (SELECT id
     FROM t5
    WHERE id LIKE '%54234245%'
  ) t5,
  (SELECT id
     FROM t6
    WHERE id LIKE '%54234245%'
  ) t6
  WHERE
    t0.id=t1.id
AND t0.id=t2.id
AND t0.id=t3.id
AND t0.id=t4.id
AND t0.id=t5.id
AND t0.id=t6.id
;

下面是一个可能的结果，第一行的数据是没有启用Smart Scan技术的结果，第二行是启用了Smart Scan的结果。

第一行比较容易理解，存贮阵列/结点的数据以400 MB/s的速度通过Storage network传输到DB结点进行，DB CPU的利用率达到了99%。

显而易见，这时瓶颈出现在DB结点的CPU上，如果启用了Smart Scan，则Exadata会在存贮结点上首先对数据进行处理(存贮结点的CPU利用率为50%)，然后把其中有效的数据以8 MB/s的速度传输到DB结点进行处理，这时DB结点的CPU利用率下降为80%。SQL的完成时间却变为原来的一半。

Exadata在这里做了哪些事情呢？

1. 只进行有效数据的传输，这里，只传输满足条件id like ‘%54234245%’的7个表的指定列 id 的数据。

2. 解决了原来pre-Exadata可能碰到的网络瓶颈问题

3. 分担了DB 节点的工作负载

Exadata应该说代表着Oracle Database未来的发展方向。这句话可不是一句广告词，依我看来，Exadata完全有这个资格享受这种待遇。

一个计算系统，最主要的是追求CPU，IO，Network之间的平衡。使这些计算资源能充分地发挥潜能。比如说，如果IO的扫描能力能达到10GB/s，如果存贮阵列到计算结点的带宽不能达到10GB/s，那么IO的扫描能力就不能得到充分发挥。又比如，如果CPU每秒钟只能处理6GB/s的数据量，10GB/s的IO扫描能力也不能能到充分发挥。

对一个计算系统另一个重要的衡量指标是如何有效地利用计算资源，这同样地包括CPU，IO，Network。比如说，虽然Network可以达到每秒10GB/s的带宽，但如果这些数据都是无效的(与本次操作无关的其它业务数据)，那么这只是对网络带宽的浪费。这就涉及到一个重要的课题：如何高效地利用最少的计算资源在最适当的时候对数据进行操作。

在原来Oracle Database的基础上，为满足上面提到的两个基本点，Exadata进行了富有创新的对基本设施的改进。举一个例子，当数据刚从存贮结点扫描出来时，马上进行初步的加工，把无效的数据丢弃。同时，Exadata推出了一个实现了CPU，IO，Network之间平衡的典型的机器配置。这可以说是Oracle为业界推出了自己在Oracle Database的最佳实践的一个最佳解决方案。

那么，Exadata如何解决Network方面的瓶颈呢？

首先是Infiniband的运用。一个Infiniband的端口一般可以提供2GB/s的流量，这是千兆网的16倍以上，4Gb的光纤网络的5倍以上。

同时，Exadata只进行有效数据的传输，最具体讲，则是Smart Scan 技术的运用。举个例子，对于下面这个查询

SELECT a.no,
       sum(case
             when a.KEY IN ('A') then
              a.score * 2
             else
              a.score * 5
           end) score
  FROM fact_table a
 GROUP BY a.no

下面是一个可能的结果，第一行的数据是没有启用Smart Scan技术的结果，第二行是启用了Smart Scan的结果。

第一行比较容易理解，存贮阵列/结点的数据以7GB/s的速度通过Storage network传输到DB结点进行，DB CPU的利用率达到了57%。

显而易见，这时瓶颈出现在存贮网络上，如果启用了Smart Scan，则Exadata会在存贮结点上首先对数据进行处理(存贮结点的CPU利用率为30%)，然后把其中有效的数据以4GB/s的速度传输到DB结点进行处理，由于DB结点接收到更多的有效数据(90*7/45=14GB/s)，CPU也变得更加繁忙起来(81%)。

Exadata在这里做了哪些事情呢？

1. 只进行有效数据的传输，这里，只传输表fact_table里三列的数据(no, key和score)

2. 解决了原来pre-Exadata可能碰到的网络瓶颈问题

3. 让DB结点的CPU更加高效的利用起来