菜鸟运维的悲剧
菜鳥運維的悲劇-一次數據庫恢復與遷移
我們公司與另一家大公司合作為客戶開發了一個服務端平臺，其中服務端的開發完全由這家大公司完成，客戶端是在他們原有的產品的基礎了，我們做了一些符合客戶要求的調整。項目完成了，我們負責運維，但是我們對服務端的業務層面了解，技術和實現知之甚少。作為一個小公司，是不可能各個方面的人員都有的，比如開發、測試、DBA。我是開發人員，我也負責運維這個項目，平時有什么問題我負責處理或者反饋給合作公司。
最近呢平臺投入使用，數據庫服務器卻掛了，事情是這樣的：
系統破解過期，重新破解系統掛掉
當然了，再次作為一個小公司，我們的服務器操作系統也是盜版的。偶然有一天我發現有個oracle數據庫服務器操作系統的破解失效了，整個桌面背景都是黑的。其實這樣也并沒有影響服務端平臺 功能，但是有點強迫癥的我，還是又重新用注冊機注冊了一下。
重啟，睡覺。然而這個服務器再也啟動不起來啦，為什么，我也不知道。
從遠古備份恢復數據庫
掛掉就掛掉唄，系統很重裝好了，但是心里不踏實的是這是個數據庫服務器，需要恢復數據庫。然而，我們貌似平常沒有做過數據庫的備份，因為平臺剛投入使用，功能問題就一大堆。當然了，幸運的是有一個很早的備份，八個小時完成恢復。這個時候第一次瀏覽了一下這個oracle數據庫，我也是傻眼了：
這能忍，忍不了。
遷移有效數據庫架構到新數據庫
跟合作公司一溝通，堅定了我遷移數據庫的想法。在茫茫4萬個表中，有效的表結構不到50個。于是重建表空間，遷移有效表結構。
各位注意，沒有文檔，其實這里遷移的表結構有漏掉的，關鍵還漏掉一些包、觸發器、序列。
刪除恢復數據庫，重命名遷移數據庫，避免程序又不必要調整
遷移完了，跟合作公司提供了遷移數據庫的表空間用戶名和密碼。合作公司說，你們可不可以使用原來的表空間名稱、用戶名、密碼，這樣程序就不用做任何調整。想想說得挺有道理，這很簡單嘛，刪掉原來的數據，重命名遷移的數據庫就OK了。
各位可能猜到了，8G的4萬張表的亂碼的數據庫刪除也不是一件容易的事，費了九牛二虎之力，把恢復的數據庫搞得訪問不了了，也沒能刪除。
放棄刪除，使用遷移數據庫
恢復的數據庫刪除不了，只能使用遷移數據庫了，合作公司調整了程序的相關配置。
前面埋下的問題冒泡了，遷移數據庫沒有文檔，遷移不完整，程序跑不起來
恢復數據庫狀態錯誤，遷移數據庫缺少部分數據庫結構
這下完了，恢復的數據庫被我搞得刪除不了，訪問不了；遷移數據庫缺少部分表和包。怎么辦？
一個是耗費時間，一個耗費時間不一定能完成，選擇自然是前者
再次恢復數據庫，遷移出必須對象
是的，我借著晚上的時間，電腦工作了一夜的時間，刪除了狀態錯誤的恢復數據庫。再花半天時間，再次恢復那個遠古備份。
再次恢復那個數據庫，這是個痛苦的經歷。
恢復相關程序功能，保留恢復數據庫，測試并不斷遷移必須對象
接下來的工作就是平臺跑起來，報什么錯，治什么病，螞蟻搬家一點一點的把有效的數據庫結構，搬到遷移數據庫。
我再也不會刪掉那個笨重討厭的恢復的數據庫了，里面垃圾與寶藏并存。
目前我已經走到這里了，遷移數據庫基本完善，下面是我期待的結果。
程序功能OK，保留恢復數據庫，備份遷移數據庫
計劃：定期備份遷移數據庫
痛苦經歷寫出來，滿眼都是淚。
這是一個糟糕的過程，我甚至覺得你看到都不會覺得有任何價值，我也覺得這樣的項目簡直就是在折磨人。但是痛苦中還是吸取了一些教訓的：
當然，這些就是教訓，還希望各位博客園的運維大神們指導一些運維經驗。真的是心累呀，這次數據庫恢復和遷移。
轉載于:https://www.cnblogs.com/zhangdk/p/5405847.html
總結
- 上一篇： go中有缓存通道和无缓存通道区别
- 下一篇： 辗转相除求最大公约数