目錄
- 案件背景與現場架構判斷
- RDM / Raw Device Mapping：虛擬磁碟對應實體硬碟
- ESXi APD 日誌與儲存路徑異常
- 處理方式：逐層重建與 Oracle ASM 驗證
- 現場紀錄與鏡像過程
- 本案救援重點
案件背景與現場架構判斷
本案上門檢測後，初步判斷不是單純主機故障或單顆硬碟問題，而是 Oracle Cluster / ASM 與 ESXi 虛擬化環境交疊的複合式架構。
現場需要處理約 500GB × 10 的資料鏡像，且至少一個 node 的磁碟狀態必須維持可分析，才能繼續往下重建資料關係。
架構判斷與救援難點：本案的救援難點，不是單純的單顆硬碟故障或一般 RAID 重建，而是多層架構交疊。現場判斷系統使用 Oracle Cluster / ASM 架構，底層透過 SAS expander 將共享硬碟提供給節點使用，同時又混合 ESXi 虛擬化環境中的 virtual disk / LUN 架構。Oracle ASM 會在資料庫層再次管理與分配資料區塊，因此救援時不能只用一般 RAID 或單一 VMDK 的方式處理。必須先釐清實體硬碟、SAS expander、ESXi storage path、virtual disk / LUN，以及 Oracle ASM disk group 之間的對應關係，逐層重建資料映射後，才有機會正確解析資料庫內容。
架構關係可理解為：實體共享硬碟 → SAS expander → ESXi / virtual disk → Oracle ASM disk group → database datafile。
RDM / Raw Device Mapping：虛擬磁碟對應實體硬碟
在 VMware vSphere 裡，這類「讓 VM 透過一個虛擬磁碟指標，直接對應到底層實體儲存裝置或 LUN」的專有名詞通常稱為 Raw Device Mapping（RDM）。Broadcom / VMware 文件對 RDM 的定義，是讓虛擬機能直接存取 physical storage subsystem 上的 LUN。
因此本案例要特別區分：這不是一般把一顆實體 HDD 直接掛進虛擬機使用，也不是單純放在 VMFS 裡的一個 VMDK 檔案；比較接近的是虛擬磁碟 / RDM 指標對應到實體硬碟或共享 LUN。VM 端看起來仍像一顆硬碟，但後端資料實際牽涉 ESXi device path、RDM pointer、SAS expander、共享磁碟與 Oracle ASM disk group 的多層映射。
救援影響：如果底層實體硬碟或 LUN 損壞後又重新上線，除了處理資料區塊本身，還要重新確認 ESXi 裝置識別、RDM / virtual disk 對應、storage path 與 Oracle ASM disk group 的一致性。這會比單純 VMDK 或一般虛擬硬碟救援多一層麻煩。
ESXi APD 日誌與儲存路徑異常
從現場 ESXi 日誌可看到，多個 storage device 曾出現連線異常與 APD（All Paths Down）狀態。APD 代表 ESXi 主機在當下失去通往該儲存裝置的所有可用路徑，相關 I/O 會快速失敗或中斷。
- All Paths Down：多個儲存設備進入 APD，代表 ESXi 對該儲存設備的存取路徑中斷。
- Connectivity restored：部分裝置後續又出現連線恢復，表示故障可能與儲存路徑、控制器、SAS expander 或前端映射狀態有關。
- I/O 快速失敗：APD 期間的 I/O 失敗會影響虛擬機與 Oracle ASM 看到的磁碟狀態，後續救援必須回到映像與底層資料做判斷。
這類紀錄不是用來套一般「檢查硬體、網路、相容性」建議，而是作為後續判斷 storage path、LUN mapping、virtual disk 與 ASM disk group 對應關係的依據。
VMware APD / PDL 相關說明可參考：vSphere Storage APD / PDL 文件
處理方式：逐層重建與 Oracle ASM 驗證
本案真正的處理方式，是先保全與鏡像，再逐層拆解資料映射；不是直接在原機上嘗試修復或重建。
- 先針對可讀取硬碟與相關儲存裝置建立安全鏡像，避免原始媒體被二次破壞。
- 確認實體共享硬碟、SAS expander、ESXi storage path、RDM pointer 與 LUN / virtual disk 之間的對應關係。
- 分析 ESXi 端看到的 RDM / virtual disk / LUN 結構，判斷哪些區塊屬於 Oracle ASM 可用資料範圍。
- 重建 Oracle ASM disk group 與 database datafile 的映射關係，避免只用單一 VMDK 或單一 LUN 方式誤判。
- 最後以 Oracle DB 檔案與資料庫層驗證方式，確認救援出的資料是否具備可用性。
處理方式紀錄截圖
現場紀錄與鏡像過程
以下保留現場分析、鏡像與錯誤紀錄，作為救援過程佐證。
鏡像到 fpmk 600GB。
鏡像過程中，1 開頭設備皆回報錯誤。
Dat / SQL 相關資料確認。
本案救援重點
- 這不是單純 RAID 重建案件，而是 Oracle ASM、ESXi RDM / virtual disk / LUN 與共享硬碟架構交疊。
- SAS expander 連接共享硬碟後，必須先確認每層映射關係，不能只看單一磁碟或單一虛擬磁碟。
- Oracle ASM 會再次管理資料分配，因此救援結果必須回到 ASM disk group 與 database datafile 層級驗證。
- APD 與 storage path 中斷紀錄，會影響虛擬機與資料庫看到的磁碟狀態，必須以映像與底層分析為準。
這類企業架構救援的核心，是逐層拆解、重建映射與驗證資料，而不是只做一般硬碟掃描或單層檔案救援。
