Oracle Exadata 学习笔记之核心特性Part1

近年来，国内众多厂商都有一体机的产品，不过更多都是围绕硬件本身的堆砌和优化，那么这些产品和Oracle一体机最大的区别在哪里呢？最近读了李亚的《Oracle Exadata技术详解》，系统的了解了Exadata的一些核心特性，我个人认为这些特性就是Oracle一体机最大的优势。为什么这么说呢？举例来说这就好比我们熟悉的iPhone手机，众所周知都知道它的硬件配置并不如同年其他品牌的旗舰机高，但是给使用者的体验确是最稳定的，这很大程度就是因为iPhone软硬件一体，可以进行针对性的定制优化。下面简单介绍下这些属于Exadata的核心特性。

• 1.Offloading
• 2.SmartScan
• 3.Storage Index

1.Offloading

Offloading可以理解为将一些处理工作“下沉”到Exadata的Cell存储节点来完成。早期被称为Smart I/O。
参数 cell_offload_processing 用来控制是否启用Offloading，默认值为true，也就是默认是启用Offloading功能的。
那么Offloading的功能具体包含哪些呢？
- Smart File Creation
- Smart File Restore
- Smart Scan
- Smart Incremental Backup

基本上从名字上就猜到这些功能的大概作用：

Smart File Creation：智能文件创建。注意真实的Offload并不是发生在创建文件的时候，而是发生在格式化新的数据块过程中。

Smart File Restore：智能文件恢复。可以认为是Smart File Creation的一种特殊形式，发生在数据文件恢复的过程中。

Smart Scan：智能扫描。作为Offloading中最出名的功能，后面会进一步介绍。

Smart Incremental Backup：智能增量备份。10g后引入的bct，在传统Oracle环境中，是以一组数据块变化为单位的；在Exadata环境中，粒度更细，是以一个数据块为单位的，这使得增量备份的数据量大量减少，从而降低了I/O消耗。

值得一提的是，Exadata的db节点和cell节点之间的负载可以互相感知，如果发现cell节点的CPU负载过高，db节点比较空闲时，很可能会发生一部分原本使用smart scan的查询不使用smart I/O过滤，称之为reverse offloading（逆向offloading）。等cell节点压力缓解后又可能会再次执行offloading。

Reverse offload feature enables a storage cell to push some offloaded work back to the database node when the storage cell’s CPU is saturated.

2.SmartScan

上面已经说到，我们耳熟能详的SmartScan其实就是Offloading大类中的一个功能特性。
那么SmartScan具体又包含哪些内容呢？
- Predicate Filter
- Column Filter
- Bloom Filter
- Storage Index
- Function Offload
- Compress/Decompress
- Encrypt/Decrypt
- Virtual Columns Offload

在李亚的书中提到一个非常简单且直观的例子，就是说这样一条SQL：

select customer_id from orders where order_amount > 20000;

如果是传统的数据库架构，数据库内核会发起读取这张表所有块的I/O动作，然后读到buffer cache，再进行SQL处理，最后才把所有满足条件的行与列找出来返回给客户端。

如果是Exadata，会为这个查询构造出一条Exadata特有的iDB指令，发给所有Exadata Cell存储节点上，存储软件会处理筛选数据，将符合要求的行与列返回汇总给数据库该进程的PGA，最终返回给客户端。

对比两种方式，不难发现Exadata的SmartScan大大减轻了数据库服务器的负担，将很大一部分的工作“下沉”到Exadata的Cell存储节点来完成。

这个例子用到的功能就是SmartScan中的Predicate Filter和Column Filter。

我们多思考下，如果是传统数据库架构，这类SQL我们一般都是通过创建合适的索引来减少数据库和存储之间的I/O操作。而Exadata的SmartScan特性，使得很多场景下我们甚至都不需要设计过多的索引也能有很好的性能体验，这也很大程度上减少了DBA的维护工作。

曾遇到过硬件堆砌的普通一体机，因为没有Exadata这样的特性，也没有设计合适的索引，当遭遇一张2.4TB的大表全表扫，扫描期间直接将56GB的IB卡跑满，I/O峰值达到12GB/s（假设单卡去掉损耗估算6GB/s，双卡正好是12GB/s），而该SQL最终返回给客户端的结果集并不多。

还曾听同事讲过，某Exadata的客户，在处理一些SQL优化的时候，经常会尝试使用删除表上索引的操作来让其使用SmartScan特性反而获得较好的优化效果（当然做这种事情一定要事先分析测试验证可行性）。

SmartScan的功能是Exadata特有的，ASM磁盘组有一个cell.smart_scan_capable的属性，可以通过lsattr查看，如果是Exadata存储，默认就是TRUE，且可以修改为FALSE；如果不是Exadata存储，这个属性默认就是FALSE，且无法修改为TRUE。

--方法1: 在SQL>下修改ASM磁盘组的属性
SQL> alter diskgroup DATA set attribute 'cell.smart_scan_capable' = 'FALSE';
Diskgroup altered.

--方法2: 在ASMCMD>下修改ASM磁盘组的属性
ASMCMD> setattr -G DATA cell.smart_scan_capable FALSE

如果是非Exadata的存储，无法将此属性修改为TRUE，会报错不兼容，类似如下：

ASMCMD> lsattr -G DATA -l
Name                     Value
access_control.enabled   FALSE
access_control.umask     066
au_size                  1048576
cell.smart_scan_capable  FALSE
compatible.asm           11.2.0.0.0
compatible.rdbms         11.2
disk_repair_time         3.6h
sector_size              512
ASMCMD> setattr -G DATA cell.smart_scan_capable TRUE
ORA-15032: not all alterations performed
ORA-15242: could not set attribute cell.smart_scan_capable
ORA-15287: could not set disk group attribute cell.smart_scan_capable due to incompatible disks
ORA-15285: disk '/dev/asm-diske' violates disk group attribute cell.smart_scan_capable (DBD ERROR: OCIStmtExecute)
ASMCMD>

3.Storage Index

Storage Index可以说是SmartScan的一部分，它是位于CELL存储节点上一块基于内存的数据结构，旨在过滤无效数据（主要针对有序字段的查询和查询条件包含Null或Not Null的SQL）、减少SmartScan产生的大量Cell物理I/O。
Storage Index是通过Exadata存储软件自动创建，自动维护的，如果存储节点发生重启，Storage Index也会自动被重置。
Storage Index包含存储区域特定字段（对于某一特定的表，每个Storage Index中最多包含8列数据分布信息）的最大值和最小值以及特殊标志位（用来标明字段是否包含Null值）。
首次查询不会用到Storage Index，因为查询条件的字段是第一次使用，在Storage Index中就不包含对应的索引条目，所以在POC等特殊场景下为了演示更好的性能需要预热。
参数_kcfis_storageidx_disabled用来控制是否禁用Storage Index，默认是FALSE，即默认是启用Storage Index特性的。

NAME                                DESCRIPTION                                                        VALUE
----------------------------------- ------------------------------------------------------------------ ------------------------------
_kcfis_storageidx_disabled          Don't use storage index optimization on the storage cell           FALSE
_kcfis_storageidx_diag_mode         Debug mode for storage index on the cell                           0

李亚的书中提到，设置参数只是让db层不使用Storage Index，如果需要彻底禁用Storage Index，可在CellCLI下进行设置：

--禁用Storage Index：
CellCLI> alter cell events = "immediate cellsrv.cellsrv_storidx('disable', 'ALL', 0, 0, 0)";

--启用Storage Index：
CellCLI> alter cell events = "immediate cellsrv.cellsrv_storidx('enable', 'ALL', 0, 0, 0)";

--清除Storage Index：
CellCLI> alter cell events = "immediate cellsrv.cellsrv_storidx('purge', 'ALL', 0, 0, 0)";

如果需要跟踪Storage Index的内部行为，可以通过将参数_kcfis_storageidx_diag_mode设置为2，这会在Cell存储节点上生成trace带来额外开销，需慎重评估使用。

还有一种方法是李亚在书中推荐使用的，直接在存储端CellCLI命令行下执行：

CellCLI> alter cell events = "immediate cellsrv.cellsrv_setparam('_cell_thread_max_trace_file_size', '17024')";
CellCLI> alter cell events = "immediate cellsrv.cellsrv_storidx(dumpridx, all, 0, 0, 0)";

通过前面对Offloading、SmartScan、Storage Index的概念学习，大概从范围来看可以简单理解为：Offloading > SmartScan > Storage Index。

但某些场景大家聊到这些概念可能不会区分的这么清楚，比如有时候人家说Offloading可能就是特指SmartScan，诸如此类根据语境判断即可，也不要过于较真，自己心里要有个认识能明白对方的意思即可。