基於CordysC3版平台應用系統維護經驗一則——Oracle資料庫資料表空間滿了

某日中午，有使用者陸續反映系統問題，說流程送出異常、待辦不消失、待辦打不開等等。維護工程師開始分析問題，後台較為清晰的現象是流轉日誌記錄插入資料失敗，人工測試表插入成功，其它現象五花八門，沒有規律，經過多位維護工程師的努力，終於由Oracle資料庫管理工程師在16：01排除故障，系統基本恢複“正常”。

故障原因是“應用系統Oracle資料庫中Cordys使用者所對應的資料表空間”滿了，導致應用無法正常向資料庫寫入資料，造成業務資料不完整。

第二日，維護人員根據使用者反饋，逐個流程處理，並公告所有使用者，在故障時間段內容發起、處理的業務如有異常，請盡量重新發起流程辦理，儘管這樣，維護人員的電話也打爆了。

不幸的、擔心的事情還是發生了，有使用者反饋，新啟動的流程有的也有異常！

瞭解這些情況後，我建議維護負責人，把Cordys服務停了，重啟Oracle資料庫。當晚下班，維護人員就按此方案操作。第三日系統復原正常，維護人員繼續處理故障資料，維護工程師研究故障資料範圍。

經過上述過程，在規範IT營運管理環境下（分工明確：分一線、二線、三線人員及專業線分工），維護系統總結如下：

1、在一個上線多年，而且沒有改動的情況下，出現了無規律異常現象，基本上可以定位是應用軟體以外的問題，例如資料庫系統、作業系統等，做為直接面對使用者的軟體維護人員在上報的同時，及時建議聯絡應用軟體以往的維護人員；

2、對於此應用系統，如果出現資料表空間滿了，出現資料寫入故障時，特別是定位到是Cordys使用者所對應的資料表空間滿了的情況下，為了避免事態擴大，減少故障資料，需要立即做的工作如下：

1）、停止應用服務；

2）、處理資料庫故障，例如擴資料表空間；

3）、重啟資料庫；

4）、啟動應用服務（按重啟處理）；

5）、測試、驗證系統是否正常。

附：故障嚴重性說明

如附圖所示，這是相關性3天的資料，統計工作時間內，按每整點、半點鐘統計匯總，此前間隔30分鐘時段內的待辦任務處理量，非人工節點、特殊情況未統計在內。統計最近1周的11點到16點間的流程業務操作頻次為3000-3500筆之間（還好，避開了高峰點），因此可估算出大致的故障資料範圍。