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，諸如此類根據語境判斷便可，也不要過於較真，本身內心要有個認識能明白對方的意思便可。