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，诸如此类根据语境判断便可，也不要过于较真，本身内心要有个认识能明白对方的意思便可。