第四回 某外商銀行安裝磁帶機問題

因為承接了某家銀行集中備份的服務，需要將現有環境中的磁帶機更換為光纖通道介面的，前提就是主機上也需要新增一片光纖通道卡，選了一個平日晚上，我們將備份伺服器停機，準備進行這個工作，在整個工作完成後，有趣的事情發生了，主機的網路無法通連，連網卡都看不到，我們做了許多測試，還原硬體環境，重開機，修改檢查登錄機碼，都無法再看到系統內的任何一張網卡。

為了加這張卡片。測試了兩天，最後和客戶討論後決定，還原回系統中原有7個月前的作業系統備份，因為備份伺服器的主要檔案都存放在非系統碟，因此還原後，備份伺服器順利的啟動了。

最後我判斷，因為銀行的 Policy 特別嚴格，在Windows 環境中做了許多安全性強化原則，設的太過頭了，己經影響到 Windows 作業系統的運作。才導致這次事件發生。但是無法指出是哪條安全性原則造成，因為整本手冊洋洋灑灑幾百條，慶幸的是我們將備份系統還原，但是客戶己不讓我們安裝這張卡片了。只好另外安排時間。

第二次安裝排在四週後，而且在安裝前還特別找了台機器向客戶證明卡片是可用的，但是安裝當天仍然不順利，卡片安裝上去後，一直無法抓到磁帶機，於是這次又測了一整天，最後客戶說，再不行又得還原為安裝前的狀態，我們想了許久，告知客戶，希望能將環境還原至 Windows 強化之前的環境來測試，勸說了許久，客戶終於同意，花了30分鐘還原至比上次更久之前的備份後，重新接上磁帶機，安裝驅動程式，直接的磁帶機就順利安裝成功。

你問我怎麼回事，我的解釋原因一樣，就是安全性設定設的太過了，讓系統連新增移除硬體都有問題，白白的浪費了兩次加班時間快20個小時，只為了做這次 2個小時就能完成的事情。

第三回 回顧 200X 年某書局的 Oracle Database 問題

這是回顧某一年凌晨，我接到老闆電話，某書局 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 己經是資訊部的經理了，我呢....還是工程師.....。

第二回 某財團法人之系統當機

在 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 安裝了以後，就不再發生當機的事情。但是是為什麼發生的，最後的報告還是不知道。真要慶幸這個案子原廠的服務我們並沒有接回來，雖然在途中還是幫原廠做了不少事，但是至少這次出事，原廠是義無反顧的在處理這件事。

第一回 外商 Exchange Server 當機

本來想弄個圖文並茂的，無奈blogger 的工具對於上傳圖片設定一直有問題，所以只能文字敘述了。

這家外商的這台 Exchange 是 VIP 專用的，上面使用兩張光纖通道卡連接 EMC Storage ，一張光纖通道卡連接 IBM TS3310 Tape Library 。

之前就不知為什麼，這台主機設定 Zoning 之後，Tape Driver 認到的結果都很怪，最後是不知為什麼接 Tape 的那張卡可以透過別台主機的 Zoning 認到不屬於他的 Tape Driver 。

後來解決方式是將該主機的 Zoning 拿掉後就正常了，但是陸陸續續的又發生了一些問題，像有一次磁帶機忽然又消失無蹤，結果只好排一次停機日，去將所有 Tape 的驅動程式移除，再重新加回去，然後重開機。

好不容易磁帶機回來的，可是 NBU 仍然不能使用，後來又發現是有名的防毒軟體(賣咖啡)的企業版裏定義的某個 Policy 去阻擋 NBU 的程式存取磁帶機設備，將該 Policy 拿掉就好了。

而這一次呢，又莫明奇妙的當機，而且設備重開機後一直開不起來，一直到使用者將連接磁帶機的那張光纖通道卡的線拔掉後，設備就開的起來，重開後的 Windows Event Log 沒有任何線索可查，後來我推測是光纖通道卡認磁帶機那張不知為什麼又認不到設備了，而我觀察的結果，San Switch 的 Zoning 裏有一筆其他的共用的磁帶機，目前己經沒有在使用。

尤於之前接續時，這個磁帶機就存在了，而且之前就一直有問題，問過使用者後，確認該設備沒在使用，就先將該 Zoning 設定移除。

移除之後再重新接續設備時，IBM 的 TS3310 就很正常順利的認到，而且沒有重新開機(理論上動態將光纖通道的設備加入，本來就不需要重開)，NBU 運作設備掃瞄的狀況看起來也正常。

接下來就看 User 端何時備份，當機的狀況會不會再發生。