Exadata为DW而生 对OLTP有无现实帮助？

其次，分析一下Exadata的几大技术亮点：

(1) 最最核心的技术是叫做smart scan，其它重要技术如HCC和Storage Index都必须依赖它才能运行：其核心目的是把部分工作从DB服务器offload到存储服务器上，利用存储服务器的CPU参与SQL的处理。 Offload之所以重要是因为在大容量数据库DW应用中传统的瓶颈就在于大量数据的传输，而且传统数据库必须将所有的裸数据块装载到数据库里面。 Smart scan减少DB服务器的CPU占用、减少数据传输量(只传输符合条件的数据)、减少磁盘访问的时间。所以比如在执行单纯的全表扫描的时候，smart scan对于访问速度的提升确实有所帮助。相对而言，减少DB服务器CPU占用对于性能提升所起到的帮助最小，主要的“收益”来自于DB服务器和存储服务器之间数据传输量的减少。

a. Column Projection：只返回所需要的“列”，减少数据传输

b. Predicate Filtering,：只返回所需要的“行”，减少数据传输

c. Storage Indexes：每一列的数据以1MB为分割单位，建立“分区”索引，每个index entry记录一段数据区间的最大值、最小值和它们的物理位置。它的作用不是为了返回少量的数据给DB服务器，而是为了缩短存储服务器访问磁盘的时间。可以把它看做某种形式上的“分区”机制。从这里可以看到Exadata的存储和访问形式，其本质是一个典型的列式数据库。

d. Simple Joins (Bloom Filters)：把bloom filter也offload到存储服务器上去做，减少DB服务器CPU占用。“事实上， Smart Scan 只能处理Join filtering，而真正Join的工作必须在DB Server上完成，而且Smart Scan 仅适合于处理 DSS 环境的复杂Join，对于 OLTP 类型的简单Join，Smart Scan 并不能发挥其优势。~ 冯大辉《深入Oracle数据库机：Oracle Exadata五大技术亮点浅析》”

e. Function Offloading：部分内建的SQL函数可以offload到存储服务器上做，减少DB服务器CPU占用。

f. Hybrid Columnar Compression (HCC) ：假如使用smart scan，解压缩的工作在存储服务器上完成。但是它的作用与smart scan减少传输量的初衷相反。所以需要权衡减少CPU占用和介绍传输量之间谁带来的好处大，比如在cellsrv version 11.2.2.3.1中，在存储服务器忙的时候，cell server可以返回未解压的数据给DB服务器。

g. Encryption/Decryption：跟HCC类似，可以在cell server上运行解密的工作，在ORALCE特定版本和相应CPU的配合之下，解密可以得到硬件加速的帮助。

h. Virtual column运算可以offload

i. data model scoring function运算可以offload

j. Non-Smart Scan Offloading：与查询无关的offload

i. Smart File Creation：数据块初始化加速，由cell server执行数据块的格式化

ii. RMAN Incremental Backups：提高tracking的颗粒度~每一个block，而不是一组blocks

iii. RMAN Restores：在cell server上恢复

k. 触发smart scan的前提(以下三条都满足)：

i. “全段落”扫描：Full Table Scan 或是 Fast Full Index Scan。TABLE ACCESS FULL= TABLE ACCESS STORAGE FULL，INDEX FAST FULL SCAN= INDEX STORAGE FAST FULL SCAN，MAT_VIEW ACCESS STORAGE FULL

ii. Direct Path Reads：并发读取数据到program global area(PGA)。即使对于non-parallel scans ，ORACLE也可以根据情况自动的选择Direct Path Reads。

iii. 数据保存在exadata storage上。假如ASM管理之下的存储空间全部或者部分的不存放在cell server上，则不可以使用smart scan offloading。

(2) 第二大技术：HCC。只有当数据被用direct path loads的方式访问的时候，可以做HCC压缩。传统的访问仍然使用OLTP的压缩方式。

a. HCC有四种压缩方式

i. QUERY LOW(WAREHOUSE LOW)：LZO compression algorithm，压缩率最低

ii. QUERY HIGH(WAREHOUSE HIGH)：ZLIB (gzip) compression algorithm，压缩率中等

iii. ARCHIVE LOW：ZLIB (gzip) compression algorithm，但是压缩率比QUERY HIGH高得多

iv. ARCHIVE HIGH：Bzip2 compression，压缩率最高

b. CU=多个blocks(32/64KB)，CU内部数据的组织形式是按“列”而不是按“行”。优点是由于列的数据类型相同，压缩比率会很高，其作用在于提高压缩比例，而不是提高访问性能，“Here’s an example of running a CPU-intensive procedure：The compression slowed down the processing enough to outweigh the gains from the reduced number of data blocks that needed to be read。From 《Expert ORACLE Exadata》”。缺点是读取任意一行的数据都需要装载多个block组成的CU，所以特别不适合于需要做很多单行操作的访问。

c. 当现存记录被更改时，数据会被转存到新的block中，而这个block是OLTP压缩的。所以当HCC表被频繁update时，所占空间会像“气球”一样膨胀。

d. Locking的机制使得单行操作会锁住整个CU，这对于绝大多数OLTP环境来说是致命的。

(3) 第三大技术：Storage Index，按照列字段值的索引。其设计目的是eliminate disk I/O，凡是不符合条件的区段都被跳过了。

(4) Smart Flash Cache

a. Sun recommends that the ESM modules be replaced every two years as the stored energy degrades over time (like a battery)

b. the Oracle Exadata Storage Software User’s Guide recommends powering down the storage servers before replacing one of these cards

c. 可按照任意比例划分为ESFC和SSD盘(由ASM管理)使用，如果用于ASM管理的SSD盘，那么必须有足够的redundancy，就降低了实际可用容量。

d. ESFC的独特二叉读取功能：在系统忙的时候，可以有选择的从flash cache或者盘上读取数据

e. Smart Scan通常读盘而非读取ESFC，但是可以通过开关指定Smart Scan去读ESFC

f. 也可以用开关把特定的数据对象pin在ESFC里面

(5) Resource Management：DBRM和IORM

a. IORM only manages I/O for physical disks. I/O requests for objects in the flash cache or on flash-based grid disks are not managed by IORM.