這是回顧某一年凌晨，我接到老闆電話，某書局 ERP 資料庫檔案放置的 Filesystem Crash ，目前己經是一個空目錄，我詢問了狀況後，出門去協助解救，過去了以後，還是先看看那個己經全空的 Filesystem ，原廠的 Support 工程師己經線上電話諮詢過，客戶也重建了該 Filesystem ，所以我也沒什麼好看的了，理所當然的空空如也.
只好.....開始看客戶的備份環境，首先客戶依當初導入 ERP Consultant 的手冊實施每日的備份，然後上帶，所以只能反客操作回來，所幸磁碟系統中所存的那份備份內容仍在，只要使用 RMAN 就能 Restore 回來，只是要找出是哪份資料，因為客戶使用了 RMAN Catalog DB ，但在我去之前的兩個小時，客戶就己經依 Oracle Support 的步驟執行了 List Backup ，結果系統沒有任何回應就卡在那，個人感覺不對勁及沒道理，詢問了客戶後，找出該 Catalog DB Server ，居然是台 Pentium Pro 的機器，那時主流應該是 Pentium 4 ，結果客戶那居然還有這種古董。(依照記錄Pentium Pro 是 1995 年的時候出來的，那年至少是 2004 ~ 2005 年的時候吧)
我判斷因為客戶從未整理 Catalog DB ，裏面有太多的垃圾，造成這台古董機根本跑不出要回傳的資料，就先請客戶找一台比較快的機器來，把Catalog DB 在那台機器上建立起來，重新下 List Backup 後，終於在半小時後有資訊出現了。但是下 Restore Backup 後還是沒有反應，後來我只好試著 Restore Datafiel ID ，忽然就有資料被倒出來了，終於是出現了一道曙光，但是客戶存放 Backup File 的 Medida 實在是慢到嚇人，結果這近 200G 的資料預估需花費48小時才 Restore 完成，
在 Restore 完成後，我又前往去協助 Recovery Database ，到最後都 Recovery 完成後，我嘗試著要 Open Database ，又發現有一個 Datafile 需要 Apply 一個三年前的 Archive Log ，我問客戶說這怎麼可能，前天的備份，現在還要跟你要三年前的 Archive Log ，後來我看了一下那個檔名的命名方式跟現存的不同，因此猜測當初有人建錯檔案，就直接把該檔案設為 Offline 後就沒去理他了，所以我也把該檔案直接 Drop 掉，再重新開一次資料庫就啟動了。
這家書局的 ERP 系統也48 小時無法登錄使用，慶幸的是這兩天是盤點的時間，因此損失也不大。
不過我最近又去訪問過客戶，當年的 DBA 己經是資訊部的經理了，我呢....還是工程師.....。
