簡介Oracle Exadata x9m產(chǎn)品介紹PPT面向數(shù)據(jù)庫管理員、架構(gòu)師及企業(yè)IT決策者系統(tǒng)梳理Exadata x9m作為Oracle數(shù)據(jù)庫專用工程化系統(tǒng)的定位與核心價值。內(nèi)容覆蓋產(chǎn)品在OLTP、數(shù)據(jù)倉庫、內(nèi)存分析等場景下的性能表現(xiàn)、硬件配置和關(guān)鍵參數(shù)并給出全架、半架、四分之一架、八分之一架配置下的SQL閃存帶寬、PMEM讀寫IOPS、數(shù)據(jù)加載速率等指標便于讀者快速評估與選型。資源包共1個文件為57.17MB的PPTX演示文稿適合內(nèi)部培訓(xùn)、方案匯報或技術(shù)學(xué)習(xí)已有230人學(xué)習(xí)。演示文稿還重點呈現(xiàn)Exadata X9M與Dell EMC PowerMax 8000在吞吐量、IOPS、延遲上的對比以及Exadata在金融服務(wù)、醫(yī)療、零售等行業(yè)的采用情況包括財富100強企業(yè)87%的使用占比同時結(jié)合“五個九”高可用性和IDC商業(yè)價值研究幫助讀者從產(chǎn)品特性、競品差異、行業(yè)實踐與運維效益多個維度理解Exadata x9m。1. 為什么數(shù)據(jù)庫跑在 Exadata X9M 上會和普通服務(wù)器差一個數(shù)量級做數(shù)據(jù)庫選型的人第一次看到 Exadata X9M 的性能表多半會愣一下一個標準機架能跑出 2760 萬次 8K 讀 IOPS、1TB/s 的分析掃描帶寬、19 微秒的 SQL 讀延遲。這不是“多塞幾塊閃存盤”能堆出來的數(shù)字而是把數(shù)據(jù)庫軟件、存儲軟件和硬件綁在一起協(xié)同設(shè)計的結(jié)果。X9M 是 Exadata 的第十一代產(chǎn)品2021 年發(fā)布距第一代 V1 已經(jīng)過了十多年。它解決的核心問題很直接讓 Oracle 數(shù)據(jù)庫在 OLTP、數(shù)據(jù)倉庫、數(shù)據(jù)庫整合和內(nèi)存分析這幾類負載下不用改應(yīng)用就能獲得遠高于通用服務(wù)器的性能和可用性。適合誰看打算采購或升級數(shù)據(jù)庫一體機、正在做 X8M 存量評估、或者想搞清楚 Exadata 性能參數(shù)為什么這么寫的架構(gòu)師和 DBA這份資料都值得過一遍。2. 拆解性能指標帶寬、IOPS 與延遲背后不是堆硬件而是數(shù)據(jù)路徑優(yōu)化2.1 先讀總表從機架比例看懂吞吐和 IOPS 的線性擴展Exadata 的性能表按機架比例給出從 Eighth Rack 到 Full Rack。這里面最容易被忽視的一點是它的性能幾乎隨規(guī)模線性增長而不是堆了更多盤之后因為爭用而打折。以 HCHigh Capacity存儲節(jié)點為例Full Rack 的 SQL Flash 帶寬是 630GB/sHalf Rack 是 315GB/sQuarter Rack 是 135GB/sEighth Rack 是 67.5GB/s逐級減半沒有損耗。同樣的規(guī)律也出現(xiàn)在 PMEM 讀 IOPS 上Full Rack 的 2240 萬次 8K 讀Half Rack 算下來正好約 1120 萬次。指標HC 存儲節(jié)點Full RackHalf RackQuarter RackEighth Rack最大 SQL 閃存帶寬630 GB/s315 GB/s135 GB/s67.5 GB/s最大 SQL PMEM 讀 IOPS22,400,00011,200,0005,600,0002,800,000最大 SQL 閃存寫 IOPS8,569,0004,298,0001,842,000921,000最大 SQL 磁盤帶寬25 GB/s12.5 GB/s5.4 GB/s2.7 GB/s最大數(shù)據(jù)加載速率35 TB/hour17.5 TB/hour7.5 TB/hour3.8 TB/hour第一列的數(shù)字是很多人選型時的參考基準。兩個容易誤讀的地方說明一下一是寫 IOPS 是在 ASM 鏡像之后于存儲服務(wù)器側(cè)測的也就是說已經(jīng)計入冗余副本的寫放大不是應(yīng)用側(cè)看到的裸寫 IOPS二是加載速率通常會受數(shù)據(jù)庫服務(wù)器 CPU 限制而不是存儲上限所以 35TB/hour 是理想峰值實際跑批量加載時先看計算節(jié)點夠不夠。2.2 HC、EF 和 XT高容量、極速閃存與擴展存儲的取舍Exadata 存儲服務(wù)器按盤型分成三類。HC 是 12 塊 18TB 7200 轉(zhuǎn) HDD 加 4 塊 NVMe 閃存卡適合容量敏感、有一定熱數(shù)據(jù)的場景EF 是 8 塊 NVMe 閃存卡、不帶 HDD適合追求極致 IOPS 和低延遲的 OLTP 場景XT 是純擴展盤柜只有硬盤沒有閃存適合做歸檔和冷數(shù)據(jù)分層。這三類節(jié)點在同一個機架里可以混用Exadata 會把熱塊自動放到閃存、冷數(shù)據(jù)留在 HDD不需要應(yīng)用干預(yù)。選型時別只看單塊盤容量。EF 節(jié)點雖然單機容量小但每個節(jié)點有 8 塊 6.4TB NVMe PCIe4.0 閃存卡全閃節(jié)點在小 IO 隨機讀場景下幾乎不受磁盤尋道影響HC 節(jié)點如果 flash cache 命中率上不去大批量掃描時還是會落到 HDD。XT 則更極端它連 PMEM 都不配只適合數(shù)據(jù)生命周期里“很少訪問但不能丟”的部分。常見做法是把熱表和索引放到 EF 或 HC 的閃存層把歷史分區(qū)表放到 XT再配合分區(qū)裁剪讓查詢不碰冷數(shù)據(jù)。2.3 Smart Scan 與存儲索引參數(shù)表讀不出來的數(shù)據(jù)庫感知能力Exadata 真正拉開差距的不是那幾塊 NVMe而是存儲節(jié)點上的智能掃描軟件。傳統(tǒng)架構(gòu)里數(shù)據(jù)庫把數(shù)據(jù)頁從存儲讀回數(shù)據(jù)庫服務(wù)器內(nèi)存再由 CPU 過濾行和列Exadata 的 Smart Scan 會在存儲節(jié)點上直接做謂詞判斷和列裁剪只把符合條件的行、需要的列返回給計算節(jié)點。如果表經(jīng)過混合列壓縮掃描時甚至能在壓縮態(tài)下做過濾返回的數(shù)據(jù)量能少一個數(shù)量級。存儲索引則是另一種“免費”優(yōu)化存儲節(jié)點在內(nèi)存里維護每個存儲區(qū)域的最大值和最小值查詢條件落在區(qū)間之外時整個區(qū)域的 IO 直接跳過。判斷 Smart Scan 是否生效不要只看 SQL 跑得快不快。一個常見誤用是拿包含 LOB 字段的查詢做測試或者對索引掃描執(zhí)行計劃做 offload 驗證結(jié)果發(fā)現(xiàn)沒走 Cell 多路徑就認為功能有問題。Smart Scan 主要覆蓋全表掃描、分區(qū)掃描和索引快速全掃描點查走 B-Tree 索引時本來就不會切到智能掃描路徑這是設(shè)計行為不是故障。2.4 為什么 19 微秒延遲能出現(xiàn)RDMA 與 PMEM 的配合Exadata 從 X8M 這一代引入 PMEM持久內(nèi)存和 RoCE 網(wǎng)絡(luò)X9M 把它推進到 PCIe4.0 和 100Gb/s RDMA。RDMA 的意思是一臺服務(wù)器可以不經(jīng)過操作系統(tǒng)協(xié)議棧和遠程 CPU直接通過網(wǎng)卡讀寫另一臺服務(wù)器的內(nèi)存。Exadata 把數(shù)據(jù)庫日志寫和塊傳輸放到這條路徑上redo 寫入延遲被壓到很低的水平這也是 8K SQL read 能達到 19 微秒延遲的關(guān)鍵。因為普通網(wǎng)絡(luò)存儲的延遲大頭都花在協(xié)議解析和上下文切換上RoCE RDMA 把這條路縮短成了網(wǎng)卡直通。這套機制對上層透明但底層依賴無損網(wǎng)絡(luò)。RoCE 本質(zhì)上是以太網(wǎng)上的 RDMA一旦網(wǎng)絡(luò)里出現(xiàn)丟包重傳懲罰遠高于傳統(tǒng) TCP性能曲線會瞬間崩塌。所以 X9M 對交換機的 PFC優(yōu)先級流控和 ECN 配置有嚴格要求安裝時這些參數(shù)如果不對就會出現(xiàn)“單機測速正常、集群跑起來延遲暴漲”的玄學(xué)問題。第 5 章會專門講這個坑。3. 硬件規(guī)格與選型X9M-2、X9M-8 和三種存儲節(jié)點怎么配3.1 計算節(jié)點選型兩路還是八路X9M 的計算節(jié)點分 X9M-2 和 X9M-8 兩條線。X9M-2 是兩路插槽配 2 顆 32 核 Ice Lake 8358 處理器2.6GHz默認 512GB 內(nèi)存、可擴到 2TB本地盤是 2 塊 3.84TB NVMe SSD可按需擴到 4 塊。X9M-8 是八路插槽配 8 顆 24 核 8268 處理器2.9GHz默認 3TB 內(nèi)存、可擴到 6TB本地是 2 塊 6.4TB NVMe PCIe3.0 閃存卡。兩者用途差異很明顯X9M-2 覆蓋從 1/8 機架到滿配的絕大多數(shù)場景性價比高X9M-8 面向單庫極大內(nèi)存需求通常是超大實例整合或 SAP 類負載。選兩路還是八路核心看兩點。第一是數(shù)據(jù)庫 SGA 需求有沒有超過單臺兩路節(jié)點的尋址上限第二是許可證成本X9M-8 的 CPU 基數(shù)更大Oracle 企業(yè)版按核授權(quán)時費用會明顯高出。常見做法是優(yōu)先用 X9M-2 橫向擴展單庫實在頂不住再切 X9M-8而不是一開始就上八路。3.2 存儲節(jié)點規(guī)格速查HC、EF、XT 以及 1/8 機架的差異三種存儲節(jié)點里HC 和 EF 都帶 2 顆 16 核 Ice Lake 8352Y 處理器、256GB 內(nèi)存和 12 條 128GB 第二代持久內(nèi)存。區(qū)別在閃存和硬盤的配比HC 是 12 塊 18TB HDD 4 塊 6.4TB NVMeEF 是 8 塊 6.4TB NVMeXT 則降到單 CPU、96GB 內(nèi)存、無 PMEM只有 12 塊 18TB HDD 和 2 塊 240GB M.2 啟動盤。存儲節(jié)點型號CPU內(nèi)存持久內(nèi)存閃存硬盤HC2×16 核 Xeon 8352Y256 GB12×128 GB4×6.4 TB NVMe12×18 TBEF2×16 核 Xeon 8352Y256 GB12×128 GB8×6.4 TB NVMe無XT1×16 核 Xeon 8352Y96 GB無無12×18 TB1/8 機架 HC2×16 核 Xeon 8352Y256 GB6×128 GB2×6.4 TB NVMe6×18 TB最容易看漏的是最后一行1/8 機架雖然也叫 HC 存儲節(jié)點但持久內(nèi)存只有 6 條而不是 12 條閃存卡 2 塊、硬盤 6 塊。也就是說1/8 機架的 PMEM 加速能力只有標準 HC 的一半如果業(yè)務(wù)對 redo 寫入延遲敏感起步配置別選 1/8 機架。3.3 機架組合與彈性配置從 1/8 到滿配怎么組合X9M-2 支持 1/8 機架、1/4 機架、1/2 機架4 個計算節(jié)點 7 個存儲節(jié)點和滿配8 個計算節(jié)點 14 個存儲節(jié)點。滿配整機架的容量上限是 3.8PB 原始磁盤、920TB NVMe 閃存和 27TB PMEM。除了固定比例X9M-2 還支持彈性配置以 1/4 機架為基礎(chǔ)計算節(jié)點最多擴到 19 個存儲節(jié)點最多擴到 18 個存儲和計算可以解耦擴容。X9M-8 則只有 1/2 機架23和滿配214兩種固定組合彈性時最多 3 個計算節(jié)點、14 個存儲節(jié)點。機架頂部預(yù)留了 2U 空間給客戶放自己的交換機這是很多人忽略的。如果你要用現(xiàn)有萬兆網(wǎng)絡(luò)做客戶端接入這 2U 正好放一臺接入交換機不用另占機柜位。內(nèi)部 RoCE 網(wǎng)絡(luò)則要求全冗余自帶雙交換機和冗余電源不需要額外采購網(wǎng)絡(luò)設(shè)備。3.4 X9M 與 X8M 的代際差異升級換來了什么對比上一代 X8MX9M-2 計算節(jié)點的核心數(shù)從 24 核升到 32 核內(nèi)存通道從 6 條 2600MT/s 升到 8 條 3200MT/sRoCE 網(wǎng)卡從 PCIe Gen3 升到 Gen4帶寬是原來的 1.8 倍。本地盤變化最明顯X8M 是 4 塊或 8 塊 1.2TB SAS HDDX9M 換成 2 塊或 4 塊 3.84TB NVMe SSD可用容量相近但隨機性能完全不是一個量級。存儲節(jié)點方面HC 的硬盤容量從 14TB 升到 18TB單機容量增加 28%內(nèi)存從 192GB 升到 256GB閃存卡從 PCIe Gen3 升到 Gen4。持久內(nèi)存容量沒變但換成了第二代 Optane 系列。整體看X9M 這代提升不靠重新發(fā)明架構(gòu)而是把 CPU、內(nèi)存通道、PCIe 帶寬和盤型全部換代再疊加 21.2 版本系統(tǒng)軟件的優(yōu)化。4. 版本對應(yīng)關(guān)系Exadata 軟件、Oracle Database 和固件矩陣4.1 Exadata System Software 21.2X9M 的準入門檻X9M 硬件只支持 Exadata System Software 21.2 及以上版本這是硬性門檻不是“建議升級”。原因很簡單21.2 才包含對 Ice Lake 處理器、PCIe4.0 NVMe 卡和第二代持久內(nèi)存的驅(qū)動與微碼支持。你拿到一臺 X9M 機器如果系統(tǒng)軟件版本低于 21.2存儲節(jié)點根本起不來或者能起來但 PMEM 和 RoCE 加速不生效。Exadata 硬件最低 Exadata 系統(tǒng)軟件版本X9M21.2.0.0.0 或更高X8M19.3.0.0.0 或更高X819.2.0.0.0 或更高X718.1.0.0.0 或更高X612.1.2.3.1 或更高X5-212.1.2.1.0 或更高X5-812.1.2.2.0 或更高這里面有個容易被忽略的細節(jié)X8M 和 X9M 都走 RoCE 網(wǎng)絡(luò)而 X8 及更早型號走 InfiniBand網(wǎng)絡(luò)架構(gòu)完全不同。做升級時不能把 X8 的存儲節(jié)點直接搬到 X9M 機架里必須按官方 RoCE 硬件要求重新配網(wǎng)。版本矩陣的具體細節(jié)以官方文檔 2724126.1 為準每次開工前先查一遍。4.2 Oracle Database 版本與 offload 功能完整度數(shù)據(jù)庫版本和 Exadata 系統(tǒng)軟件的匹配決定了 Smart Scan、存儲索引、IORM 等功能是否完整可用。比較典型的例子是 12.2 數(shù)據(jù)庫完整 offload 功能和 IORM 對 12.2 CDB/PDB 的支持要求 Exadata 12.2.1.1.0 以上只滿足最低啟動版本是不夠的。Oracle 數(shù)據(jù)庫版本Exadata 系統(tǒng)軟件最低要求完整 offload 功能要求21c21.2.0.0.0 或更高同最低要求19c19.1.2.0.0 或更高建議 19.1.6.0.0 以上18c18.1.4.0.0推薦 18.1.6.0.0 以上12.212.1.2.2.112.2.1.1.0 以上12.1.0.211.2.3.3.112.1.1.1.0 以上11.2.0.411.2.3.2.1需包含 Bug 13245134 修復(fù)另一個容易踩的點是 11.2.0.4 數(shù)據(jù)庫。它雖然被支持但數(shù)據(jù)庫 home 里必須安裝修復(fù) Bug 13245134 的補丁否則在 Exadata 上可能出現(xiàn)異常行為。很多團隊把 X8M 的數(shù)據(jù)庫版本直接帶著升級到 X9M結(jié)果 Exadata 軟件升到 21.2 后11.2.0.4 的數(shù)據(jù)庫和存儲節(jié)點通信異常最后查半天發(fā)現(xiàn)是舊補丁沒打全。我的習(xí)慣是任何版本變更前先把數(shù)據(jù)庫補丁刷到對應(yīng)季度最新再動 Exadata 軟件。4.3 從 X8M 升級到 X9M 的檢查動作升級路徑上我一般會按這個順序走確認目標機型的 Exadata 軟件版本滿足硬件要求X9M 必須 21.2 起步。核對數(shù)據(jù)庫版本在官方支持矩陣里并檢查是否包含已知必要補丁。用dcli批量導(dǎo)出所有存儲節(jié)點的當(dāng)前配置包括 ASM 磁盤組信息、存儲節(jié)點告警和 PMEM 狀態(tài)。遷移前在 X9M 上搭一套同版本軟件環(huán)境做一次 Smart Scan 和 redo 寫入的基準測試留底用于上線后對比。停機窗口內(nèi)先升級 Exadata 軟件再遷移數(shù)據(jù)庫不要反過來。這套動作里最容易省掉的是第 3 步但存儲節(jié)點告警和 PMEM 狀態(tài)在升級前后不一致時事后排查會非常被動。導(dǎo)出一份配置清單等于給升級留了后悔藥。5. 性能翻車排查X9M 投產(chǎn)前最容易踩的 5 類坑5.1 持久內(nèi)存容量算錯1/8 機架的 PMEM 只有一半現(xiàn)象按 1/8 機架采購的 X9M 到貨后發(fā)現(xiàn)持久內(nèi)存容量是 768GB而不是按“滿配 27TB / 8”推算出來的 3.4TB 左右其實滿配 14 個 HC 存儲節(jié)點 × 1.5TB PMEM 約 21TB但 1/8 機架存儲節(jié)點也少不是簡單除法。原因1/8 機架的 HC 存儲節(jié)點只配 6 條 128GB PMEM而不是標準 HC 的 12 條起步配置的閃存卡也只有 2 塊。這是產(chǎn)品線的固定規(guī)格不是安裝事故。解決采購階段直接按“1/8 機架 HC 存儲節(jié)點 6×128GB PMEM 2×6.4TB NVMe 6×18TB HDD”來核對容量。如果業(yè)務(wù)依賴 PMEM 加速 redo 寫入1/8 機架起步時就要評估是否直接上 1/4 機架否則后期補存儲節(jié)點會牽動磁盤組平衡。5.2 RoCE 網(wǎng)絡(luò)丟包RDMA 快的前提是無損以太網(wǎng)現(xiàn)象集群跑著跑著AWR 里出現(xiàn)大量gc buffer lost或log file sync等待IO 延遲從 20 微秒級跳到幾毫秒級單條 SQL 測試正常并發(fā)一上來就崩。原因X9M 用 RoCE 替代 InfiniBandRoCE 依賴以太網(wǎng)無損特性需要在交換機上正確配置 PFC優(yōu)先級流控和 ECN顯式擁塞通知。很多數(shù)據(jù)中心的現(xiàn)網(wǎng)交換機沒有開這些參數(shù)或者連接端口接了不支持 PFC 的上聯(lián)口導(dǎo)致 RoCE 流量在擁塞時直接丟包。解決安裝階段要求網(wǎng)絡(luò)團隊按 Exadata RoCE 網(wǎng)絡(luò)白皮書逐項核對交換機配置重點看 PFC 優(yōu)先級映射、ECN 水線和 DCBX 協(xié)商狀態(tài)。排查時先看交換機端口的pause frame計數(shù)如果持續(xù)增長基本可以斷定無損網(wǎng)絡(luò)配置失效先修網(wǎng)絡(luò)再調(diào)數(shù)據(jù)庫。5.3 NVMe 閃存壽命測試期就把盤寫花了現(xiàn)象跑了一兩個月壓力測試存儲節(jié)點告警cellcli查到某塊 NVMe 盤的剩余壽命百分比明顯下降甚至觸發(fā)介質(zhì)預(yù)警。原因Exadata 的 NVMe 閃存要同時承擔(dān) flash cache 寫和用戶數(shù)據(jù)寫測試階段如果并發(fā)跑大量隨機寫負載寫放大系數(shù)會被放大。更常見的是有人用dd或文件系統(tǒng)級工具直接對裸設(shè)備做全盤寫測試完全繞過了 Exadata 的 IO 管理閃存壽命消耗極快。解決壓測前用cellcli記錄每塊盤的壽命基線壓測期間打開 IORM 限制最大寫吞吐避免測試負載打滿整機架。日常巡檢里把閃存剩余壽命納入監(jiān)控低于 30% 時提前備件別等告警了才處理。5.4 HCC 壓縮率不達標壓縮級別選錯現(xiàn)象表建好并做了混合列壓縮查實際占用發(fā)現(xiàn)只壓縮了 2~3 倍遠低于宣傳的 10 倍以上。原因HCC混合列壓縮的壓縮級別分QUERY LOW、QUERY HIGH、ARCHIVE LOW、ARCHIVE HIGH級別越高壓縮比越大但寫入開銷也越高。OLTP 表如果選ARCHIVE HIGH每次插入和更新都付出巨大 CPU 代價反過來分析場景如果只選了QUERY LOW壓縮率自然上不去。解決按數(shù)據(jù)溫度選壓縮策略——頻繁更新的表用QUERY LOW只讀歷史分區(qū)用ARCHIVE HIGH并且用DBMS_COMPRESSION包先估算再決定。HCC 對更新和刪除特別敏感行一旦發(fā)生遷移壓縮比會明顯下降所以大表一定要配合分區(qū)設(shè)計和批量加載。5.5 版本矩陣沒查對固件、軟件和數(shù)據(jù)庫版本沖突現(xiàn)象X9M 上裝 19c 數(shù)據(jù)庫連接存儲節(jié)點時報版本不兼容錯誤或者 Smart Scan 不觸發(fā)。原因最常見的是數(shù)據(jù)庫 home 打了太舊的 RU和 Exadata 21.2 系統(tǒng)軟件沒有匹配到官方矩陣其次是 Grid Infrastructure 版本低于 18c導(dǎo)致集群件無法正確調(diào)度 storage server IO。還有人在 X8M 的存儲節(jié)點固件上直接跑 X9M 的 21.2 軟件固件和驅(qū)動不匹配各種詭異告警。解決上線前把數(shù)據(jù)庫版本、Grid Infrastructure、Exadata 系統(tǒng)軟件、存儲節(jié)點固件四條線的版本號列成表逐項核對官方2724126.1文檔。版本矩陣是 Exadata 運維里最不能靠經(jīng)驗的環(huán)節(jié)查文檔不丟人拍腦袋才容易出事。6. 用 CellCLI 做一輪投產(chǎn)前體檢三個必看指標6.1 看閃存和持久內(nèi)存的健康狀態(tài)投產(chǎn)前我習(xí)慣先在任意一臺計算節(jié)點上用dcli批量跑 CellCLI把整個存儲網(wǎng)格的健康狀態(tài)一次性拉出來。閃存壽命和介質(zhì)狀態(tài)是第一個必看項dcli -g cell_group -l root cellcli -e list physicaldisk where diskTypeFlashDisk attributes name, percentFreeSpace, mediaStatus邏輯說明dcli會按cell_group文件里的存儲節(jié)點列表并發(fā)執(zhí)行cellcli -e表示非交互執(zhí)行單條命令。percentFreeSpace表示閃存剩余壽命百分比mediaStatus則直接給出介質(zhì)是否正常。輸出里如果出現(xiàn)critical狀態(tài)說明盤已經(jīng)進入預(yù)警同一批盤壽命差超過 10 個百分點說明負載不均衡要查一下 ASM 磁盤分布。持久內(nèi)存的狀態(tài)單獨查dcli -g cell_group -l root cellcli -e list pmemdisk attributes name, size, statusstatus字段為normal才表示 PMEM 在線工作。如果一整套設(shè)備所有 PMEM 都顯示normal但 redo 寫入延遲仍然高下一步就要看網(wǎng)絡(luò)而不是看盤。6.2 看存儲節(jié)點 CPU 和 I/O 響應(yīng)時間第二個必看是存儲節(jié)點的 CPU 利用率因為 Smart Scan 是在存儲側(cè)消耗 CPU 的如果存儲節(jié)點常年 80% 以上應(yīng)用側(cè)再優(yōu)化都沒有用。用 CellCLI 的metriccurrent能直接看到實時指標cellcli -e list metriccurrent cellsrv where name like CD_CPU\_UTIL* attributes name, metricValueCD_CPU_UTIL是 cellsrv 進程的 CPU 利用率正常情況下應(yīng)在 40% 以下超過 60% 要開始關(guān)注持續(xù)超過 80% 就要考慮把部分掃描型負載分流到其他機架。配套還要看兩個值CD_IO_UTILIO 利用率和CD_LATENCY響應(yīng)延遲。這三項一起看能快速區(qū)分瓶頸在 CPU 還是在存儲介質(zhì)。6.3 驗證 offload 到底有沒有生效第三個必看是驗證 Smart Scan 是否真的在工作而不是“看著像”。跑一條目標 SQL 后在數(shù)據(jù)庫里查這條 SQL 的監(jiān)控視圖select sql_id, io_cell_offload_eligible_bytes, io_cell_offload_returned_bytes from v$sql where sql_id 目標SQL的SQL_ID;邏輯說明io_cell_offload_eligible_bytes是存儲節(jié)點上符合 offload 條件的數(shù)據(jù)量io_cell_offload_returned_bytes是實際返回給計算節(jié)點的數(shù)據(jù)量。如果 eligible 很大而 returned 很小說明 Smart Scan 把大量數(shù)據(jù)過濾在了存儲側(cè)這是最理想的狀態(tài)如果兩個數(shù)差不多說明 offload 幾乎沒有過濾效果要回頭查執(zhí)行計劃里是否出現(xiàn)了STORAGE FULL字樣以及查詢條件有沒有被寫成無法下推的形式。另一個更簡單的體檢項是看全局統(tǒng)計select name, value from v$sysstat where name like cell physical IO bytes saved by storage index%;這個值統(tǒng)計的是存儲索引跳過 IO 節(jié)省的字節(jié)數(shù)。如果它長時間不增長說明存儲索引沒有發(fā)揮作用通常是掃描集中在剛寫入的新數(shù)據(jù)區(qū)還沒來得及生成索引信息——不是故障但值得留意。說起來有點慚愧早年間我接手一套性能詭異的 Exadata 環(huán)境排查了兩天最后發(fā)現(xiàn)是網(wǎng)絡(luò)交換機 PFC 配置被運維重置過。從那以后我每次項目驗收前都強制走一遍這套體檢流程先看盤和 PMEM 健康再看存儲節(jié)點 CPU最后跑一條真實 SQL 確認 offload 數(shù)字。流程不長但足夠把 80% 的隱性坑擋在上線之前。希望幫到你。整套 Exadata X9M 產(chǎn)品介紹資料整理了各機架配置的詳細參數(shù)拿去做選型和版本核對都合適。本文還有配套的精品資源點擊獲取