Oracle 診斷實戰：Redo Log 全組 ACTIVE 導致系統停擺，根因定位至 RAID 5 磁碟損壞

記錄一起 SunOS 5.8 + Oracle 8.1.5 生產事故：應用回應極慢、請求無返回，發現除 Current 外所有 Redo Log Group 均為 ACTIVE，經系統層級分析定位至 DBWR 寫入緩慢，最終確認為 RAID 5 陣列單顆磁碟損壞導致 I/O 效能崩潰。

現象與初步診斷

SQL> SELECT * FROM v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
------ ------- --------- ----- ------- --- ------ ------------- ---------
1      1       520403    30M   1       NO  ACTIVE 1.3861E+10    23-JUN-05
2      1       520404    30M   1       NO  ACTIVE 1.3861E+10    23-JUN-05
3      1       520405    30M   1       NO  ACTIVE 1.3861E+10    23-JUN-05
4      1       520406    30M   1       NO  CURRENT 1.3861E+10    23-JUN-05
5-9    ...                       ...   ...   ...  ACTIVE ...           ...
9 rows selected.

判斷： 所有非 Current 群組均為 ACTIVE，表示 DBWR 寫入速度跟不上 Log Switch 觸發的 Checkpoint，導致無可用 Redo Log 供 LGWR 循環寫入，系統實際掛起。

排查 DBWR 是否忙碌

$ ps -ef | grep ora_
oracle 2266 1 0 Mar 31 ? 811:42 ora_dbw0_hysms02  -- DBWR PID 2266

$ top
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
2266 oracle 1 60 0 1357M 1317M sleep 811:42 0.18% Oracle  -- CPU 僅 0.18%，非 CPU 瓶頸

DBWR CPU 佔用極低，瓶頸極大機率在 I/O 子系統。

iostat 定位磁碟熱點

extended device statistics
r/s  w/s  kr/s  kw/s  wait actv wsvc_t asvc_t %w %b device
...  ...  ...   ...   ...  ...  ...    ...   .. .. ......
11.0 65.7 978.7 525.3 0.0  1.4  0.0    17.7  0  99 c1t1d0  -- 主資料卷 %b=99%, kw/s 僅 525 KB/s

• %b (裝置忙碌比例) 持續 99~100%。
• kw/s (寫入吞吐) 僅 ~500 KB/s，遠低於 T3 陣列正常 10 MB/s 或資料庫隨機寫 1~2 MB/s。

結論： 磁碟 c1t1d0 異常緩慢，經硬體檢查確認為 RAID 5 Group 內單顆磁碟損壞，導致陣列進入降級模式、寫入效能崩潰。

解決與驗證

1. 更換故障磁碟，RAID 重建完成。
2. 系統 I/O 逐漸恢復正常，Redo Log 狀態回歸正常循環，應用回應恢復。

診斷方法論總結

1. 資料庫層： v$log 觀察 Redo Log 狀態 → 推斷 DBWR/Checkpoint 壓力。
2. OS 程序層： ps/top 確認 DBWR CPU 使用率 → 排除 CPU 瓶頸。
3. 儲存層： iostat -xn 觀察 %b、kw/s、asvc_t → 定位具體磁碟/邏輯卷異常。
4. 硬體層： 對應 RAID 控制器日誌/指示燈確認實體磁碟故障。

跨層級由上而下、由軟體至硬體的系統化排查，是資料庫效能事故快速定位的關鍵。