在 2008 年接了一個財團法人重要系統的轉換案，目的是將現有設備轉換至新年度採購設備上，同時做 Oracle 9i 昇級至 10gR2，但在初步評估時，客戶的 Application 開發人員太過樂觀，實際測試時，遇到很多問題，其中包含 Database 昇級的問題及系統面臨昇級時所要處理的一些小問題，在初步測試時，我發現客戶在 Oracle 9i 時代完全不敢去動這個資料庫，因此 Patch Level 還是在 9201 ，但是要昇至 10gR2 至少需要 9204 以上的 Patch 才能做，表示了正式轉換當天我需要做二次昇級的動作。而正式轉換僅有8小時的時間，我面臨的是兩個資料庫，一個 800GB 左右，一個 1.2TB，我預估我的工作時間是4個小時，其他是給 AP 測試的時間，至於你問我將近 2 TB 的資料我如何在 4 小時內轉換完成，那我就不多談了。(事實上我上線當天我的工作只有2個小時，用什麼方法，可能內行人都知道)
因己經演練過許多次上線步驟，所以實際上線當天算是順利的，只不過新系統很不給面子，在上線二週後面臨了第一次的當機，當天原廠的工程師前往檢查，收了 Log ，最後將系統重新啟動帶起服務後，就開始開會檢討當機原因，發生的問題在原本連接在 SAN 上的 Storage 忽然之間全部斷線，造成 Oracle 無法運作，至於 HA 為何沒啟動，因為 SAN Storage 的離線本來就不在 HA 的偵測範圍，因為 LOG 要遠渡重洋到XXX實驗室去，所以問題的原因需要等檢查報告。
所以就這樣又過了不知道幾天，又發生第二當，這時原廠的專家說初步原因是因為 SAN Storage 的資料流跟備份資料庫的資料流都集中在同樣一個 Loop 的卡片上，可能 Load 太重，我們心裏都很 OOXX ，那以後是不是叫全世界的人要做 SAN Backup 的話，要多買卡片，但是這種專家就是自視甚高，我們也不能去當面吐他槽，而且他說的事情實際上還是有這個可能性的，只要問題能解決，用什麼方法不重要，因此我們就依說明去調整了。
調整完畢後，差不多同樣在第一當和第二當的週期的同樣時間，第三當又發生了，這次原廠頭可大了，來了好幾個專家和工程師，聽說把作業系統的 Trace Mode 都啟動了，還安裝了不知什麼監控用程式在上面。然後呢...就等第四次當機的發生，新系統也是很給面子的，只是這次不在週期內發生，我也忘了實際的時間，第四當發生了，將所有的 Log 送回原廠分析後，原廠的報告是不知作業系統內哪個程式被觸發，把 Fiber Channel 上面的 Connect 全部 Disable 掉，所以 SAN Storage 才會忽然被離線，他們緊急開發了一個 Patch 去阻擋這個行為。
終於在這個 Patch 安裝了以後，就不再發生當機的事情。但是是為什麼發生的，最後的報告還是不知道。真要慶幸這個案子原廠的服務我們並沒有接回來，雖然在途中還是幫原廠做了不少事，但是至少這次出事，原廠是義無反顧的在處理這件事。
