一個mount -a引發的ora-600案例分析

一、故障描述

某次，使用者某套資料庫在 2023 年 2 月 15 早上 9 點 46 分後應用報無法連線資料庫，資料庫 Alert 日誌明顯出現 ORA-00600 和 ORA- 27300 、 ORA- 27301 、 ORA-27302 等報錯資訊，詳細日誌如下：

同時，我們同步檢查了該節點叢集 ASM 例項和 CSS 服務，均出現異常，導致業務不可用，日誌如下：

二、根因分析

經過緊急分析，透過告警日誌錯誤關鍵字，我們在 MOS 匹配到類似場景： ORA-00600 [ksm_mga_pseg_cbk_attach:map_null] reported by database when issuing NFS mount causing /dev/shm/ to become unavailable on Redhat 7 servers (Doc ID 2703432.1) ，同樣是在 19.6 資料庫版本上命中該報錯，如下：

而在該場景中，這個問題是由 mount -a 操作導致 fstab 重新整理，引起作業系統重新裝載記憶體段 /dev/shm 。新的裝載會刪除 Oracle 正在使用的記憶體段，並將其替換為新的空記憶體段，從而會對正在執行業務的 Oracle 造成災難性的影響。如下：

為了證實是否因為 mount -a 導致，我們與使用者進行了深入交流，並在相關資料庫伺服器上排查故障時間段執行過的操作的審計記錄。如下：

shell> pvcreate /dev/mapper/mpathq

shell> vgcreate vgarch /dev/mapper/mpathq

shell> lvcreate -l 76794 -n lvarch vgarch

shell> mkfs.xfs /dev/vgarch/lvarch

shell> mkdir /int_arch

shell> vim /etc/fstab

/dev/vgarch/lvarch    /int_arch    xfs     defaults    0 0

shell> mount – a

至此，我們獲取到了關鍵的 “證據”，故障時間段之前，確實有人建立了邏輯卷並計劃用於日誌歸檔，由於執行了 mount -a ，也就引發了此次故障。其實回過頭來講，將掛載資訊寫入 fstab 檔案並沒有問題，關鍵在於使用者可以選擇手動掛載歸檔檔案系統，這樣可以降低出故障的風險，當然這是後話了。

三、解決方案

當然，如果還是想正常執行 mount -a ，以下也提供幾種方法進行規避。

1 、進行 mount -a 操作前關閉資料庫例項

2 、登出 fstab 中 /dev/shm 的掛載操作

3 、將 fstab 中的 /deb/shm 移出。