記錄我一次最嚴重的勿操作，杯具啊！！！

到今天已經是2個通宵了，就在昨晚9點半左右一次勿操作，導致6個同事弄了個通宵才基本恢復了資料。教訓深刻啊！
3天前接到公司通知，說公司的一個系統出現當機，前方人員發現是資料庫存在一些問題，要我馬上去現場，由於沒有機票，過了2天，在週日到的現場。透過觀察並不是由於我們的資料庫的原因導致的問題，是別人的資料庫引起的，但資料庫的安裝還是存在很的問題，跟客戶協商決定重新做了一套Oracle系統。生產環境是10.2.0.1.0版本的，Linux x86_32bit，而且資料字典被破壞，無法匯入匯出，就連有時候訪問某些資料字典都會報遞迴錯誤，重建資料字典也失敗。當晚新的系統、DBMS都安裝完畢，例項也建立成功。就只等資料的遷移了。但是透過exp expdp都無法正常匯出。想透過第三方工具抽取，但資料較慢，當晚並沒有完成資料的遷移。
第二天晚上繼續通宵，當所有的表結構都過去了，用第三方工具抽取了部分資料，發現太慢，於是考慮使用dblink來完成抽取資料。就在這時生成了批次的truncate語句，複製到pl/sql的命令視窗執行的時候，發現報約束錯誤，但我之前是禁用了全部約束的啊。我當時還在想難道我重新導了次表結構？查了下資料字典確實約束都是啟用的。我查了下資料字典還發現有大量的recyclebin物件，我還跑去清空這些recyclebin。過了大概1分鐘，我才反應過來我連錯庫了，連的是生產環境，當時我的心啊 我知道這次完蛋了。給專案經理一說，訪問網頁就開始報錯。真的完蛋了。資料字典被破壞無法備份，最新的備份都是上個月20多號的。而且沒歸檔，執行的是truncate。oh我的天，我犯了個多麼大的錯誤啊！客戶馬上就知道，也通知了公司領導。現在最重要的就是想辦法恢復資料。好在由於約束部分表沒有被truncate掉。我簡直絕望了，以前從沒有研究過truncate的恢復，我認為是不能很好的恢復，即使能恢復也是很複雜的。後來同事幫我找了下，odu能夠恢復truncate，於是開始研究它，果然能全部恢復資料，但是中文都變成了亂碼。另一路同事正在將上個月20多號的備份資料恢復到另一個環境。到了第二天早上快上班的時候，資料還是丟了一大截，似乎是沒辦法了，就在這個時候同事的一句話，讓我想起了我頭天做操作的時候將資料庫做了一次冷備份。枉然大悟，於是將冷備份恢復，居然沒有問題，同事馬上將資料系統切換至該庫，就只丟了一天的資料，我們根據文件進行了手工的補錄。在下午3點的時候終於將資料基本恢復。
透過這次教訓，認識深刻啊，勿操作要弄死人啊 啊 啊 啊
以後做啥都得仔細，特別在操作生產環境時，做啥都要先備份，有人監督，不要那麼輕易執行delete truncate drop語句。
切忌切忌，自己一定要養成好的習慣啊！！！！