【說明】無意中看到一個同僚的QQ留言上面寫着“真累“,還沒有過30分鐘就接到這個同僚的電話,如下:剛在做删除資料的時候,發現由于條件沒有寫好,導緻删錯了,有沒有辦法恢複;接到這個任務 ,首先是深深的感慨了一下:人在狀态不好的情況下盡量多休息少做事,特别是涉及到很重要的事情。
跟着同僚确定了出現問題的時間點後,先是安慰一下,讓他從那惶恐不安的心裡恢複過來,然後開始了找尋資料的工作。
【環境說明】
資料庫版本:11.2.0.3 資料庫閃回:未開啟
【恢複步驟】
【1】确定使用者删除資料的時間點和腳本,對于資料的恢複有很大的幫助,最好再對比下使用者電腦上面的時間和伺服器上面的時間差,查詢的時候需要補上時間差(經檢查伺服器的時間和使用者電腦的時間相差5分鐘)
使用者回報用戶端上面操作的時間時17:35分,但是伺服器的時間落後使用者的時間5分鐘,是以查詢腳本如下:
select * from t_original_archives as of timestamp to_timestamp('2015-11-17 17:30:00','YYYY-MM-DD HH24:MI:SS') where id=1974244
【2】把資料導出讓使用者進行檢查
create table t_original_archives_bak as select * from t_original_archives as of timestamp to_timestamp('2015-11-17 17:30:00','YYYY-MM-DD HH24:MI:SS') where id=1974244;
【3】确認沒有問題後變可以把誤删除的資料插入到原來的表中。
insert into t_original_archives select * from t_original_archives_bak
經過以上步驟,又一次拯救了一次資料災難;
整個恢複的過程中對于誤删除時間的控制最為重要,一般15分鐘之内的資料庫可以找到,超過15分鐘的話要看天吃飯了。
以下是閃回查詢的原理。
Oracle資料庫的undo表空間用于存放資料删除前的前鏡像,保證了資料的讀一緻性。是以資料被更新或删除的時候,資料并沒有馬上消失,而是會放在undo表空間裡面的。
SQL> show parameter undo;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_in_memory_undo boolean FALSE
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS1
參數說明:
undo_management = auto,設定自動undo自動管理方式,預設設定為:auto;
undo_retention = n(秒),設定決定undo最多的儲存時間,預設是900秒,建議條件允許的情況下可以設定多一些。
注意:并不是說系統一定會保留900秒的前鏡像,也不是900秒後保留的前鏡像就會消失,跟undo表空間的大小和系統的繁忙程度有關系。(一般情況15分鐘之内的資料可以被查詢得到的)
該參數的修改方式:SQL> alter system set undo_retention = 1800;
2、怎麼保證undo存放的資料的存放時間?
方法:通過使用RETENTION GRARANTEE子句,保證資料庫按照undo_retention的時間保留;
2.1 啟動保證保留
ALTER DATABASE UNDOTBS01 RETENTION GUARANTEE
2.2 關閉撤銷資訊的保證保留
ALTER DATABASE UNDOTBS01 RETENTION NOGUARANTEE
3、啟用RETENTION GRARANTEE的弊端
當啟用了該參數後,業務繁忙的情況下,當undo表空間的使用率100%的情況下,資料庫就會宕住,因為要保證undo的鏡像不被覆寫,是以就不允許其他DDL語句的繼續執行;
4、UNDO表空間大小的設定
方法1:可以根據AWR報告給出的建議來設定UNDO表空間的大小。
方法2:在業務系統高峰期的情況下,随時觀察UNDO表空間的使用情況,進行調整。
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
本文作者:JOHN,某上市公司DBA,業餘時間專注于資料庫的技術管理,從管理的角度去運用技術。
技術部落格:獵人筆記 資料庫技術群:367875324 (請備注資料庫類型)