今天在生產環境中,開發人員提交了一個指令碼，是做update操作的，但是update操作的時候過濾條件有些大，本來預計修改的資料只有5000條，結果這個語句執行下來更改了500萬條資料。對生產系統來說算是一個資料災難，趕緊和開發確認了問題發生的時間，結果說是在半夜11點多，剛好在後半夜才開始做資料備份，這樣這個變更也同時影響了備份，就算做緊急的資料恢復也是沒有任何效果的。目前採用的備份都是全量的按天備份，備份收到影響，恢復還是比較困難的。
這個問題就在緊急的討論中分為了兩個步驟，我來嘗試恢復昨天備份前的資料，提供的時間戳是23:48:48 ，而且經過確認這個表中的資料變化很小。如果能夠恢復出表中的資料在那個時間點之前，就能把問題降低到最低。
開發從業務的角度看能不能同時提供一些修復。
我檢視了undo的空間使用，還是比較充足的，早上已經是10點左右了，所以就是儘快的做資料的恢復，使用閃回查詢來做。這個操作也不是百分百好使，畢竟還是依賴一些快取空間和系統的負載，在反覆確認時間後，寫了如下的語句。把時間戳提前了3秒。
create table tmp_xxxxx as select * from owner_account.xxxxx as of timestamp to_timestamp('20140723234845','yyyymmddHH24miss');

為了保證不會有其他潛在的因素影響，所以保守起見，沒啟並行，沒加hint
然後就是透過指令碼來監控表空間的使用率。看著空間消耗開始一點點增加，最終恢復了昨晚的資料。有了這些資料，就算暫時不會用到，心裡也踏實了。
後來開發確認，有一個欄位a，這個欄位在表裡存放的資料就是null，結果開發的update語句相當於又修改了一次，經過反覆確認，算是虛驚一場，不過也需要總結不少的經驗。
1.在指令碼提交之前，如果是dml語句，最好能夠評估修改的影響範圍，
2.如果指令碼比較大，有效能方面的潛在因素，需要讓dba來把把關，看看能不能做點什麼。
3.充分的測試也很重要，保證資料的安全和高可用是很重要的。

使用閃回查詢備份資料

相關文章