2004年10月，因為某海運公司買了當時全世界算起來算是數一數二的超級計算機，要將原來的 Oracle Single Instance 變為 RAC，所以去了一次美國紐約。
英文很爛，技術也算是還好的我，當時能夠被挑中飛去裝機，完全也是意外，連回來後英文老師期末考考英文自我介紹(那時還在唸二技的進修班)，在我背了一大堆我準備好的文稿之後，老師只用英文問我說，你去美國是幹麼，因為我英文真的很爛，所以答不出來，老師又問，你去美國只需要打電腦就好了嗎? 都不用說話嗎? 只好硬擠了幾個字出來，還好老師最後還是讓我過了。
當時這次的經驗也是挺特別的，當時 911 剛發生滿一年多，所以那時的海關仍然很嚴格，光在台灣辦簽證我就覺得超級麻煩，雖然我是去工作，但是客戶那邊不肯發給我們工作證明，所以我們不能辦工作簽證，只能用觀光簽證進去，去辦簽證時，美國在台協會問我要去哪裏，我只說了一句拉斯維加斯他就蓋章了，旁邊比我早面談看起來要去遊學的，因為英文很好就被問了一大堆，看來辦美國簽證時，就算你英文再好，也是裝死比較容易拿到。
又扯遠了，這次去美國安裝的主機，其實是備援台灣這邊的同樣架構的備援系統，這家海運公司租了兩條 T1 的海纜，透過 Oracle 的 Dataguard 技術，達成了資料庫遠端備援，但其實在系統仍在 Single Instance 測試時，以這家公司的規模和交易量，兩條 T1 的頻寬仍是不足以傳輸實際的交易量的，所以我們在 DataGuard 的傳輸處理上，有特別的動了一些手腳，將之改為手動的批次壓縮傳輸，以節省頻寬，將這隻手動程式排入 crontab 後，就可以定時自動化傳輸了，而且我們也將兩邊資料庫的交易配置成相差六個小時，以防止有人為錯誤誤刪資料時，還可以去備援端將資料趕緊的匯出再匯回，就算 Primary 端發生災難，備援端追回六小時的交易大約要 1 小時的時間，這樣子 RPO 跟 RTO 是客戶可認可的。所以後來就這樣子設計了。
裝機的過程所幸還挺順利的，只是因為時差跟台灣相差了快 16 小時，通常我們在工作時，台灣這邊的同事在睡覺，他們睡覺時就輪到我們工作，每天有重疊到的時間了不起也二、三個小時，把前一天的工作交接後，他們就去休息了。只是光 Dataguard 要使用的 source ，就是 Primary 端的 RMAN 備份檔，我記得好像快 500GB 以上吧，當時光傳檔就需要八個小時，因為一次建立失敗，只好又重傳一次，還好最後有建起來就是了。不過這家海運公司真的很精實啊。
我還在台灣寫工作計劃時，原本只寫週一到週五，結果客戶問，那你們六、日要做什麼，我差一點就說六、日休息啊，還好沒說出口，後來就更改計劃內容，把一整個星期填的滿滿的。所以我們是真的星期六、日都還在機房工作，就連最後一天要上飛機的當天，早上從旅館退房出來後，還是去機房做最後的工作，一直到上飛機的前幾個小時才離開機房去機場報到，後來這幾年看到鴻海經常被報導說他們出差都是下飛機就去工作了，一直工作到要上飛機前都還在做，說到底我們也是這樣子的啊。其實中間有個假日客戶還是有帶我們有抽空跑去紐約州的隔壁，維吉尼亞州去逛了一下，後來又往南開去了大西洋城的賭場參觀。體驗了一下美國真的是地大到可怕，高速公路也是又大又直，只是過路費我們四個人 Share 下來，真的是不便宜，所以要在大蘋果生活還真的是不容易呢...。
沒有留言:
張貼留言