本文為墨天輪數據庫管理服務團隊第108期技術分享，內容原創，作者為技術顧問肖傑，如需轉載請聯繫小墨（VX：modb666）並註明來源。如需查看更多文章可關注【墨天輪】公眾號。

一、問題概述

在線日誌無法歸檔，全為active狀態。客户跑批任務受到嚴重影響，客户臨時增加多組在線日誌，用於臨時支撐業務繼續運行。

同時發現節點1大量等待日誌切換，同時也在等待節點2的日誌切換，6：00左右嘗試用正常方式關閉節點2數據庫，但未成功，7：30左右對節點2強行關閉(shutdown abort), 關閉後，節點1的日誌可以正常切換，數據庫恢復正常。

二、問題原因

1、alert日誌分析

節點1的alert日誌在故障前後顯示如下：

2：46左右開始出現cannot allocate new log，checkpoint not complete信息，

2：52左右開始出現MMON進程超時錯誤：useg scan erroring out with error:12751

經過檢查，節點二日誌輸出基本相同。

2、ASH分析

通過ASH數據，可以看到故障期間內有非常多的log file switch(checkpoint incomplete)和enq:KI-contention等待事件。

3、存儲檢查

經過檢查，確認存儲並沒有性能問題。

4、OS日誌檢查

通過檢查message log，可以看到磁盤dm-4全是directory index full，説明此磁盤裏面有海量的小文件，導致OS層的inode已經達到峯值。

通過磁盤映射，確認dm-4正是oracle安裝目錄，經過檢查，發現存在海量的trace文件，節點1達到了七百多萬個，節點2達到了八百多萬個。

三、問題總結

抽查數個trc文件，經過檢查，內容幾乎都是一樣，懷疑是觸發了BUG，通過MOS搜索到BUG 29039510（Doc ID 29039510.8）的版本信息，track信息等都完全匹配。

1、因BUG 29039510（Doc ID 29039510.8），產生了巨量的trace文件，導致dm-4即oracle安裝目錄的inode耗盡，directory index full，系統運行緩慢。

2、由於當時在執行跑批任務，產生大量redo，由於inode耗盡，系統運行緩慢，dbwr進程寫的速度遠跟不上redo產生的速度，從而導致checkpoint無法完成，redo log除了current全是active狀態，無法切換。同時根據alert日誌輸出minact-scn:useg scan erroring out with error e:12751，suspending mmon action undo usage for 104400 seconds，MMON進程在進行undo scan的時候超時。(參考文檔DOS ID: 1478691.1)

3、後台囤積大量的log file switch（checkpoint incomplete）相關事件，及enq：KI-contention（一個節點等待另一個節點checkpoint完成）等待，節點間在互相等待checkpoint完成，shutdown abort 節點2，節點1恢復正常。

四、解決方案

1、根據跑批時日誌切換頻率（幾秒切換一次），建議增加redo log組及單個redo log文件的大小（已經處理）。

2、設置event臨時解決BUG（已經處理，確認trace文件無異常增長情況）：

alter system set event ‘trace [rac_enq] disk disable’ scope=spfile;

注意：應將已經設置過的event加進來，否則會覆蓋已經設置的event，語法示例如下：

alter system set event=“10949 trace name context forever: 28401 trace name context forever, level 1: 44951 trace name context forever, level 32: trace [rac_enq] disk disable” scope=spfile;

3、做好trace，adump，incident等目錄及alert日誌的監控或自動清理腳本。

墨天輪從樂知樂享的數據庫技術社區蓄勢出發，全面升級，提供多類型數據庫管理服務。墨天輪數據庫管理服務旨在為用户構建信賴可託付的數據庫環境，併為數據庫廠商提供中立的生態支持。
墨天輪數據庫服務官網：https://www.modb.pro/service