【oracle】摸擬故障 - 數據文件丟失恢復,SCN的做用。

模擬數據文件丟失恢復,redolog、archivelog、controlfile文件未丟失的狀況恢復。html


一、  建立一個表空間、用戶、分配權限、建表。數據庫

a)   createtablespace HXW_WEN oracle

datafile'D:\ORACLE\ORADATA\HXW168\HXW_WEN_D01.DBF'ide

size5M autoextendonnext1M maxsize20M;spa

b)createuser wen identifiedby zerostudy defaulttablespace hxw_wen;.net

c)grantdbato wen;3d

d)grantexecuteon dbms_flashback to wen; --dba不用日誌

e)createtable t1(idnumber,scnnumber,insertdate date);htm

f)createsequence seq_wen_autoid incrementby1startwith1maxvalue99999999cyclenocache;--序列blog

g)insertinto t1

values(seq_wen_autoid.nextval,dbms_flashback.get_system_change_number,sysdate); --先不插入數據


二、scn與歸檔日誌關係


事務對應的scn若是落在了哪一個archivelog裏,那麼這個archivelog在恢復時就被用到。


使用下面語句插入數據:

insertinto t1

values(seq_wen_autoid.nextval,dbms_flashback.get_system_change_number,sysdate);

查看日誌信息:

select a.GROUP#,a.SEQUENCE#,a.STATUS,a.FIRST_CHANGE#,a.NEXT_CHANGE#,b.MEMBER from v$log a,v$logfile b where a.GROUP#=b.GROUP#;

wKioL1QrhPPAhYrCAAFc0S7UXB4030.jpg

wKioL1QrhPeyoVvLAASIxmn-CxE194.jpg


重複插入並switch logfile:

select SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE#,NAMEfrom v$archived_log


wKiom1QrhMzCkgTJAAN3OMX2Rcw795.jpg


如果要恢復ID6的數據,那麼須要75號歸檔日誌文件。

  

Oracle經過scn把多個歸檔日誌文件組成一個大的邏輯文件,全部連續的歸檔日誌能夠看做是某段時間對oracle數據庫操做的日誌信息的一個獨立大文件。即物理上獨立,邏輯上統一。




三、模擬數據庫在有數據的狀況下丟失數據文件


a)關閉數據,複製一份hxw_wen_d01.dbf文件(丟失多個數據文件一個數據文件恢復步驟同樣)。

脫機備份,須要備份:

控制文件(重要)、數據文件(臨時文件不用備份)、redolog文件(重要)、歸檔日誌文件(重要)、參數文件、口令文件。

select*from  v$parameter wherenamelike'%control_files%'

select*from dba_data_files

select*from v$logfile

show parameter log_archive_dest

b)啓動數據庫,進行增刪改操做:

當前數據:

wKioL1QrhbChiJaIAAD_Dp4F-X0362.jpg


添加數據:重複下面的動做。

SQL> insert into t1values(seq_wen_autoid.nextval,dbms_flashback.get_system_chan

ge_number,sysdate);

SQL> commit;

SQL> alter system switch logfile;


wKiom1QrhYTS8-GdAAGMBYikE_k009.jpg


再添加二條數據,但不提交事務。

     20     970159 2014/10/01 12:03:47

     21     970160 2014/10/01 12:03:48


摸擬數據庫異常,而且致使hxw_wen_d01.dbf文件丟失。要求恢復的記錄有id19的數據。

注:未提交的事務,oracle會自動rollback

Shutting down instance (abort)

License high water mark = 8

USER (ospid: 4232): terminating theinstance

Instance terminated by USER, pid = 4232

Wed Oct 01 12:05:09 2014

Instance shutdown complete

 

關閉數據庫,而後把hxw_wen_d01.dbf文件更名,啓動數據庫報錯提示以下:


wKioL1QrhhjyviFEAAEps3lANok259.jpg

wKiom1QrheyRzZBOAAHIdJlRZNM628.jpg

如今啓動到mount狀態:

wKioL1QrhhrQzKweAABQLVoHkGA072.jpg


查看scn值:

wKiom1QrhlCibOqTAADoul50wBE431.jpg

 

因爲6號文件丟失,因此v$datafile_header查的scn值爲0


wKioL1Qrhn7Q3cfJAADSiyL6hiE127.jpg


把備份的(舊的)dbf文件複製回來。


wKioL1QrhuDzQGLxAAME5lN8kbQ701.jpg





四、  數據文件恢復


舊的備份文件已複製回來,此時Alter database open;提示須要介質恢復。

wKiom1Qrhzry-1D-AACreAu40Ag644.jpg

恢復數據文件6號或者恢復數據庫均可以,命令以下:

Recover datafile 6;

Recover database; --多個數據文件丟失時能夠直接用這個。

恢復過程以下:


wKioL1Qrh2qRXPqwAAQwed-m4F8516.jpg



因爲歸檔日誌都在原位置,因此不用指定文件,能夠直接輸入auto也能夠直接回車。

 

恢復時只用到歸檔日誌80號,8182沒有用到。

wKiom1Qrh5yDYjVGAAJaxQ4IhIE750.jpg

wKioL1Qrh8rABoteAAMwMjU7J5A597.jpg

wKioL1Qrh8yTOu8cAAOvaHi0jNc063.jpg

wKiom1Qrh6KDy2gXAAQ2jD5VycQ903.jpg




上面操做小總結:恢復數據文件,就是經過歸檔日誌來提高舊數據文件的scn 號,提高過程當中,須要從歸檔日誌或者redolog中找到對數據庫的操做記錄,從新在數據文件、buffer操做一次。達到恢復到所須要的時間點的數據。


參考:

  1. 百度

  2. http://www.itpub.net/thread-1065138-1-3.html

相關文章
相關標籤/搜索