CUUG筆記--oracle備份和恢復

免費網路課程《Oracle備份與恢復》，旨在深入的探討Oracle備份與恢復的真諦，剖析備份與恢復的原理，透過各種真實的案例，全面的詮釋Oracle資料庫完全恢復、不完全恢復、無備份恢復，部分恢復等技巧。
 
本次網路演示案例：
1、表空間備份方式備份資料庫
2、普通資料檔案損壞完全恢復方式原理剖析


完全恢復：不丟資料


完全恢復方式之一：資料庫在mount狀態下恢復
搭建測試環境
1.建立表，切換日誌，至少每個日誌組切換一次
SQL> select count(*) from test;


  COUNT(*)
----------
        48
        
2.再次插入資料，但是不提交


3.主機斷電導致資料崩潰,導致了資料檔案損壞


shutdown abort


二、恢復資料庫
1.主機加電，資料檔案損害


2.從最近的備份恢復相關資料檔案到目的路徑


3.嘗試開啟資料庫
alter database open;


為什麼該檔案需要介質恢復？ORACLE根據控制記錄了每個資料庫檔案該有檢查點SCN號和資料檔案頭的檢查點檔案頭進行比較


v$datafile v$datafile_header




在啟動時候可以根據不同SCN確定需要那個歸檔檔案，v$archived_LOG;中的ScN範圍（ first next）


透過觀察alert日誌檔案，我們發現oracle在recover的時候是使用archivelog+online redo的機制來recover的




當recover介質恢復完成，可以再次檢查控制檔案和資料檔案頭的SCN進行檢查是否一致


5.嘗試開啟資料並嘗試驗證資料




總結《在mount狀態適合所有的資料檔案恢復








完全恢復方式二。資料庫在open狀態恢復
另外一種恢復方式，


1.為了儘快開啟資料庫和可靠行、可以把損壞的資料檔案首先offline




alter database datafile 888 offline




2.然後在轉儲備份




3.然後直接recover tablespace 選擇auto方式




4.然後把user表空間online；


5，驗證資料是否正確




總結：該恢復方式合適於普通的資料檔案損壞，不合適system undo sysaux等TS；優點：可以提高資料庫的可靠性，




=========================================================================================================


恢復控制檔案丟失的時候需要利用recover using backup controlfile
auto
然後oracle無法識別當前最新的日誌組系列號，需要重建控制檔案
alter database backup controlfile to trace
注意選擇noretlogs的選型，要不就不能完全恢復了
重建結束後檢視v$log,檢視當前日誌組


總結:關鍵是重建控制檔案，重新獲得準確當前的日誌組


==========================================


完全恢復方式之4




未備份的資料檔案丟失


這種方式這種恢復方式只適合於自從新建的資料檔案開始，所有的歸檔日誌和redolog都必須存在，還沒有備份的


alter database create datafile 
recover database




============================================================================================================






不完全恢復


基於時間點的不完全恢復
適合於某張關鍵的表被刪除，需要恢復回來


1.環境準備
   1.
   
SQL> create table test1 as select * FROM EMP;


表已建立。




會話已更改。


SQL>  select sysdate from dual;


SYSDATE
-------------------
2013-12-28 21:57:15




  2.DROP TABLE TEST1 PURGE




  3.關閉資料庫
  
  4.從最近的備份的轉儲所有的資料檔案
  
  
RMAN> startup mount;


Oracle 例項已啟動
資料庫已裝載


系統全域性區域總計    1071333376 位元組


Fixed Size                     1375792 位元組
Variable Size                729809360 位元組
Database Buffers             335544320 位元組
Redo Buffers                   4603904 位元組


RMAN>restore database


5.對資料庫做基於時間的恢復
recover database until time  to_date('2013-12-28 21:57:01','yyyy-mm-dd:hh24:mi:ss');


6.驗證資料




==========================================
基於cancel的恢復方式
適合與recovery過程中需要的歸檔或者online redolog損壞，oracle recovery恢復到不能恢復為止


經常能夠發生在斷電，導致正在使用的線上日誌檔案損壞


1、環境準備
1.在某張表插入資料，提交，同時切換日誌，歸檔
2.再次插入資料，提交，歸檔
3.最後記錄錶行數為153行，同時弄清楚最後的insert操作記錄到那個當前序號日誌組




2.主機斷電，導致當前的redo損壞


3.嘗試開啟資料庫
資料庫裝載完畢。
ORA-00313: 無法開啟日誌組 1 (用於執行緒 1) 的成員
ORA-00312: 聯機日誌 1 執行緒 1: 'C:\APP\YANWEI\ORADATA\ORCL\REDO01.LOG'
ORA-27041: 無法開啟檔案
OSD-04002: 無法開啟檔案
O/S-Error: (OS 2) 系統找不到指定的檔案。


oracle需要例項恢復，需要的日誌檔案損壞，無法進行


4.嘗試做不完全恢復


'C:\APP\YANWEI\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2013_12_28\O1_MF_1_7_%U_.ARC'


ORA-27041: unable to open file
OSD-04002: 無法開啟檔案
O/S-Error: (OS 2) 系統找不到指定的檔案。




ORA-00308: cannot open archived log
'C:\APP\YANWEI\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2013_12_28\O1_MF_1_7_%U_.ARC'


ORA-27041: unable to open file
OSD-04002: 無法開啟檔案
O/S-Error: (OS 2) 系統找不到指定的檔案。




ORA-10879: error signaled in parallel recovery slave
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'C:\APP\YANWEI\ORADATA\ORCL\SYSTEM01.DBF'




最後的提示表明。當前的資料檔案無法同步。


5.嘗試開啟資料庫
SQL> alter database open resetlogs;
alter database open resetlogs
*
第 1 行出現錯誤:
ORA-01194: 檔案 1 需要更多的恢復來保持一致性
ORA-01110: 資料檔案 1: 'C:\APP\YANWEI\ORADATA\ORCL\SYSTEM01.DBF'




SQL>


還是提示要進一步恢復


6.從最近轉儲所有的資料檔案
 6.1 shutdown abort
 6.2 startup mount
 6.3 restose database
 
 
7.對資料庫進行cancel的不完全恢復


這時候沒有提示某個檔案需要進一步恢復


8、alter database open resetlogs;


9、檢查資料的完整性


最後的一次redo上的事物記錄丟失了