Oracle Exadata 學習筆記之核心特性Part1
- 2020 年 2 月 17 日
- 筆記
近年來，中國眾多廠商都有一體機的產品，不過更多都是圍繞硬體本身的堆砌和優化，那麼這些產品和Oracle一體機最大的區別在哪裡呢？最近讀了李亞的《Oracle Exadata技術詳解》，系統的了解了Exadata的一些核心特性，我個人認為這些特性就是Oracle一體機最大的優勢。為什麼這麼說呢？舉例來說這就好比我們熟悉的iPhone手機，眾所周知都知道它的硬體配置並不如同年其他品牌的旗艦機高，但是給使用者的體驗確是最穩定的，這很大程度就是因為iPhone軟硬體一體，可以進行針對性的訂製優化。下面簡單介紹下這些屬於Exadata的核心特性。
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，諸如此類根據語境判斷即可，也不要過於較真，自己心裡要有個認識能明白對方的意思即可。
