【kamus】Oracle ERP產品環境克隆的詭異遭遇

將Oracle ERP產品環境克隆到一個新的測試環境，是Oracle ERP DBA的日常工作。但是這次一個環境克隆到今天也沒成功，遭遇了一波又一波的問題，只能用詭異來形容。

　　我們的產品環境伺服器在各個省會城市，而測試環境伺服器則全部在北京，所以平時的操作是晚上業務可以停頓的時候，關閉資料庫，然後將所有資料檔案和客戶化程式tar到磁帶上，第二天省裡面將磁帶用快遞送到北京，然後我們開始克隆測試環境。

　　關閉資料庫，往磁帶中tar檔案，完畢以後再重新啟動環境，這些都是通過指令碼和crontab自動完成的。同樣的操作已經成功執行了無數次。

　　但是這次：

　　1。第一天拿到磁帶，作資料庫clone的時候，報錯說undo01.dbf找不到，然後發現磁帶中根本沒有沒有這個檔案，也就是備份的時候就出了問題，這個檔案沒有tar成功。最後發現原因是，HP的tar最多隻能支援單個檔案8G，而那個undo01.dbf在這次備份前因為需要匯入大量資料而擴大到了10G，所以tar失敗。

　　2。此時是第二天白天，無法down庫，只能等到晚上12點以後，開始用FTP直接從產品環境傳輸資料檔案到測試環境。臨晨4點登入系統發現FTP異常中止了，然後檢視測試環境的檔案系統，發現幾乎100%空間佔用，但是用du -sk卻顯示只使用了50G而已。

　　bdf的結果

　　/dev/hbvg01/lvhbdevdata 102432768 100529536 1888536 98% /heuat/data

　　du -sk 的結果

　　56461752 /heuat/data

　　反覆檢查，結果發現是刪除原來測試環境中的資料檔案時沒有關閉Oracle的instance，導致磁碟空間沒有釋放。此時，不禁想，如果是Windows系統，那麼instance開啟的時候根本就不會允許刪除資料檔案，也就沒這個問題了，所以，事務總有好和壞的兩面。

　　3。kill掉後臺oracle程式，重新FTP剩餘的資料檔案，到早上8點，成功傳輸完畢，開始clone，將近10點的時候，clone結束，正在作最後的打掃工作，忽然登入資料庫報錯，檢視資料檔案，竟然發現有一堆資料檔案的屬主發生了變化，當時腦袋已經比較混沌了，蒙了幾分鐘，然後ps後臺的程式，結果發現有一個mv的程式，正在把其它位置的資料檔案轉移到我正在clone的這個環境中，立刻打電話給同事。。。他的誤操作覆蓋掉了我剛剛做完的新資料庫，徹底崩潰，我一個晚上的工作啊，又白費了，這個環境仍舊宣告clone失敗。兩個字評語，詭異!我不由又有些懷念Windows了。

　　然後就是一通瘋狂的電話聯絡，跟這個人說明情況，跟那個人商量解決方法，一直搞到中午11點多，洗澡，睡覺。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/1384/viewspace-332604/，如需轉載，請註明出處，否則將追究法律責任。