在生產當中，需要做恢復資料的場景還算是相當少的，特別大的恢復場景，比如整個資料庫的恢復，或者是這個表空間的恢復，
這些少之又少。不過，表級資料的恢復還是時不時會遇到的，比如有些業務人員或者維護人員修改錯誤的資料做了提交，或者
不小心把某條資料刪除了。遇到這種情況，首先不要急，得要把問題搞清楚，不要急著去做恢復資料，一不小心，可能連dba
都採取了錯誤的恢復方法，那就麻煩了，反而越幫越忙了。
最近幾天，我自己也遇到幾次這種情況：業務人員反映，誤刪除了一條資料，現在又想要回來那一條資料，還有就是update一條資料記錄
的時候忘記帶上where條件，導致了表中所有的記錄的同個欄位的值相同，commit了才發現更新時忘記帶上條件了。錯誤刪除整張表的資料或者
truncate整張表的情況倒是還沒有遇到。
生成當中，一般都會開啟閃回恢復功能，在這個的基礎上，我們根據刪除資料的多少情況去選擇哪一種方法來恢復。當然，如果是使用閃回方法
做恢復，還有一個就是undo表空間有足夠的回滾資料塊。一下各種情況，個人的建議方法：

1、刪除一條或者多條記錄，或者錯誤多條資料，應該採用閃回查詢技術的方法來恢復：
insert into suxing.ins_771
select t.* from suxing.ins_771 as of timestamp(sysdate-1/24) t where user_id='4877';
或者：
update suxing.ins_771 set ID=
（select ID from suxing.ins_771 as of timestamp(sysdate-1/24) where user_id='4877'）;
如果是整個表的同個欄位都修改錯了，需要透過閃回查詢建立一箇中間表，準備在更新回更新前的資料使用。

2、刪除整個表的時候：

flashback table "BIN$PafEvIK1PW/gUwEAAH/iiQ==$0"
2 to before drop rename to test11;
#該處的新表表名test11可以與原表名相同，只要恢復時候原來表名不被佔用。

3、注意，在第1種的情況下，直接把表閃回到某個時間戳是存在風險的。要知道，在生產當中，可能存在多個人在你操作失誤
之後多次使用同樣的表，不同的記錄，這種情況，直接做表閃回，邏輯是不夠嚴密的。除非，在你出錯之後的一段的時間，沒有其他人
再修改過這個表，可以直接使用以下語句做恢復：
flashback table test1 to timestamp
2 to_timestamp('2016-09-29 22:20:37','yyyy-mm-dd hh24:mi:ss');

閃回恢復一個表中的資料

相關文章