[轉帖]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，諸如此類根據語境判斷即可，也不要過於較真，自己心裏要有個認識能明白對方的意思即可。