在oracle下咱們如何正確的執行數據庫恢復

標籤： oracle 數據庫 恢復

原創做品，容許轉載，轉載時請務必以超連接形式標明文章 原始出處 、做者信息和本聲明。不然將追究法律責任。 http://jiujian.blog.51cto.com/444665/1361353

 

 

 

當數據庫須要進行介質恢復時，爲了確保數據庫可以順利的執行恢復過程，恢復數據庫到當前狀態。咱們要作的就是驗證！驗證什麼呢？固然是驗證備份集和歸檔是否可以進行有效的恢復。防止咱們restore後，執行recover時卻發現歸檔缺乏了一堆，頓時傻眼。

 

 

比方說，在數據庫當前日誌序列號爲3時咱們徹底備份了數據庫。在數據庫當前聯機日誌序列號爲13時數據庫損壞須要恢復。假設數據庫聯機日誌組爲3組，則能夠推斷數據庫聯機日誌序列號分別爲11、12、13。所以當數據庫執行restore database後，再執行recover時不難推斷數據庫須要應用歸檔3、4、5、6、7、8、9、10以及聯機日誌11、12、13來進行徹底恢復。

 

 

爲了可以順利的執行徹底恢復，咱們在執行恢復前，須要對restore調用的備份集進行恢復驗證（語句爲：restorevalidate database）以及驗證recover過程所需的歸檔3-10（語句爲：restore validate archivelog sequence between 3 and10）。

 

 

以徹底恢復爲例，舉例以下：

 

 

1數據庫當前日誌seq號爲59，咱們備份數據庫

 

SQL> selectgroup#,archived,sequence#,status from v$log;

 

  GROUP# ARC  SEQUENCE# STATUS

---------- --- ---------- ----------------

       1 YES         58 INACTIVE

       2 NO         59 CURRENT

       3 YES         57 INACTIVE

 

RMAN> backup database format'/backup/fullbk-%T-%U.bak';      

 

Starting backup at 2014-02-17 12:03:28

using channel ORA_DISK_1

channel ORA_DISK_1: starting full datafilebackup set

channel ORA_DISK_1: specifying datafile(s)in backup set

input datafile file number=00004name=/oracle/CRM/CRM/users01.dbf

input datafile file number=00001name=/oracle/CRM/CRM/system01.dbf

input datafile file number=00002name=/oracle/CRM/CRM/sysaux01.dbf

input datafile file number=00003name=/oracle/CRM/CRM/undotbs01.dbf

input datafile file number=00005name=/oracle/CRM/CRM/crm.dbf

input datafile file number=00006name=/oracle/CRM/test.dbf

input datafile file number=00008name=/oracle/CRM/jxc.dbf

input datafile file number=00007name=/oracle/CRM/user01.dbf

channel ORA_DISK_1: starting piece 1 at2014-02-17 12:03:29

channel ORA_DISK_1: finished piece 1 at2014-02-17 12:05:57

piecehandle=/backup/fullbk-20140217-3ep0rj0h_1_1.bak tag=TAG20140217T120328 comment=NONE

channel ORA_DISK_1: backup set complete,elapsed time: 00:02:28

channel ORA_DISK_1: starting full datafilebackup set

channel ORA_DISK_1: specifying datafile(s)in backup set

including current control file in backupset

including current SPFILE in backup set

channel ORA_DISK_1: starting piece 1 at2014-02-17 12:06:01

channel ORA_DISK_1: finished piece 1 at2014-02-17 12:06:02

piecehandle=/backup/fullbk-20140217-3fp0rj56_1_1.bak tag=TAG20140217T120328comment=NONE

channel ORA_DISK_1: backup set complete,elapsed time: 00:00:01

Finished backup at 2014-02-17 12:06:02

 

2 當數據庫聯機日誌爲69時數據庫崩潰須要進行介質恢復

 

SQL> selectgroup#,archived,sequence#,status from v$Log;

 

  GROUP# ARC  SEQUENCE# STATUS

---------- --- ---------- ----------------

       1 YES         67 INACTIVE

       2 YES         68 INACTIVE

       3 NO          69 CURRENT

 

注意：這裏其實咱們能夠推斷，若是數據庫須要恢復到當前狀態，那麼歸檔59到歸檔66的全部歸檔，必須可以進行有效的恢復。咱們只須要發起restore database preview命令，Oracle即可以給出咱們歸檔列表，繼續往下看。

 

 

3 斷定當前數據庫恢復所須要備份集和歸檔條目

 

注意對於restore database preview列出的歸檔條目，recover執行徹底恢復時並不會徹底應用，由於徹底恢復recover過程是：應用相關歸檔+ 全部聯機日誌，seq號從小到大依次應用。後面會抓取recover過程，這裏先暫且提一下。

 

RMAN> restore database preview;

 

Starting restore at 2014-02-17 16:14:21

using target database control file insteadof recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=63 device type=DISK

 

 

List of Backup Sets

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

 

 

BS Key Type LV Size       Device TypeElapsed Time Completion Time    

------- ---- -- ---------- ----------------------- -------------------

108    Full    2.03G      DISK        00:02:26     2014-02-17 12:05:38

      BP Key: 108   Status:AVAILABLE  Compressed: NO  Tag: TAG20140217T120328

Piece Name:/backup/fullbk-20140217-3ep0rj0h_1_1.bak  

注意：這裏顯示備份片老是rman資料庫中記錄的數據文件最新的備份

List of Datafiles in backup set 108

File LV Type Ckp SCN    CkpTime            Name

---- -- ---- ---------- ------------------- ----

1       Full 4028039    2014-02-17 12:03:29/oracle/CRM/CRM/system01.dbf

2       Full 4028039    2014-02-17 12:03:29/oracle/CRM/CRM/sysaux01.dbf

3       Full 4028039    2014-02-17 12:03:29/oracle/CRM/CRM/undotbs01.dbf

4       Full 4028039    2014-02-17 12:03:29/oracle/CRM/CRM/users01.dbf

5       Full 4028039    2014-02-17 12:03:29 /oracle/CRM/CRM/crm.dbf

6       Full 4028039    2014-02-17 12:03:29 /oracle/CRM/test.dbf

7       Full 4028039    2014-02-17 12:03:29 /oracle/CRM/user01.dbf

8       Full 4028039    2014-02-17 12:03:29 /oracle/CRM/jxc.dbf

using channel ORA_DISK_1

 

List of Archived Log Copies for databasewith db_unique_name CRM

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

 

Key    Thrd Seq    S Low Time          

------- ---- ------- - -------------------

131    1    59      A 2014-02-17 11:55:37

Name:/oracle/archivelog/arch_1_59_839098938.arch

 

132    1    60      A 2014-02-17 12:10:20

Name:/oracle/archivelog/arch_1_60_839098938.arch

 

133    1    61      A 2014-02-17 12:10:21

Name:/oracle/archivelog/arch_1_61_839098938.arch

 

134    1    62      A 2014-02-17 12:10:26

Name:/oracle/archivelog/arch_1_62_839098938.arch

 

135    1    63      A 2014-02-17 12:10:30

Name:/oracle/archivelog/arch_1_63_839098938.arch

 

136    1    64      A 2014-02-17 12:10:31

Name:/oracle/archivelog/arch_1_64_839098938.arch

 

137    1    65      A 2014-02-17 12:10:32

Name:/oracle/archivelog/arch_1_65_839098938.arch

 

138    1    66      A 2014-02-17 12:10:33

Name:/oracle/archivelog/arch_1_66_839098938.arch

 

139    1    67      A 2014-02-17 12:10:34

 Name:/oracle/archivelog/arch_1_67_839098938.arch

 

140    1    68      A 2014-02-17 12:10:36

Name:/oracle/archivelog/arch_1_68_839098938.arch

 

Media recovery start SCN is 4028039

Recovery must be done beyond SCN 4028039 toclear datafile fuzziness

Finished restore at 2014-02-17 16:14:24

 

注意：

1 上面seq號這一列顯示的最後一個歸檔seq爲68（從前面可知數據庫當前聯機日誌文件seq號爲69）也就是說restore database preview顯示的歸檔列表結果中最後一個歸檔seq號老是比當前聯機日誌（當前聯機日誌也就是查看v$log狀態爲currnt的日誌組）文件seq號小於1.

 

2  結合當前數據庫的聯機日誌組seq號分別爲67 68 69，能夠判斷：在recover應用最後一個歸檔seq號爲66後，oracle會讀取seq號爲67、68、69聯機日誌文件繼續推動該數據庫來實現整個數據庫徹底恢復過程。

下面將演示整個驗證和恢復過程:

 

4 驗證恢復時須要用到的備份集是否可以正常恢復。

 

RMAN> restore validate database;

 

注意：這條命令直接會去rman資料庫中找最新的備份集進行驗證，也就是restore database preview命令顯示的備份集。

 

Starting restore at 2014-02-17 16:14:59

using channel ORA_DISK_1

 

channel ORA_DISK_1: starting validation ofdatafile backup set

channel ORA_DISK_1: reading from backuppiece /backup/fullbk-20140217-3ep0rj0h_1_1.bak

channel ORA_DISK_1: piecehandle=/backup/fullbk-20140217-3ep0rj0h_1_1.bak tag=TAG20140217T120328

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: validation complete,elapsed time: 00:00:36

Finished restore at 2014-02-17 16:15:35

 

 

5 驗證恢復時應用的歸檔

 

 

RMAN> restore validate archivelogsequence between 59 and 66;

 

Starting restore at 2014-02-17 16:16:34

using channel ORA_DISK_1

 

channel ORA_DISK_1: scanning archived log /oracle/archivelog/arch_1_59_839098938.arch

channel ORA_DISK_1: scanning archived log/oracle/archivelog/arch_1_60_839098938.arch

channel ORA_DISK_1: scanning archived log/oracle/archivelog/arch_1_61_839098938.arch

channel ORA_DISK_1: scanning archived log/oracle/archivelog/arch_1_62_839098938.arch

channel ORA_DISK_1: scanning archived log/oracle/archivelog/arch_1_63_839098938.arch

channel ORA_DISK_1: scanning archived log/oracle/archivelog/arch_1_64_839098938.arch

channel ORA_DISK_1: scanning archived log/oracle/archivelog/arch_1_65_839098938.arch

channel ORA_DISK_1: scanning archived log/oracle/archivelog/arch_1_66_839098938.arch

Finished restore at 2014-02-17 16:16:37

 

 

 

6 執行restore和recover過程以下

 

 

RMAN> restore database;

 

Starting restore at 2014-02-17 16:36:23

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=63 device type=DISK

 

channel ORA_DISK_1: starting datafilebackup set restore

channel ORA_DISK_1: specifying datafile(s)to restore from backup set

channel ORA_DISK_1: restoring datafile 00001to /oracle/CRM/CRM/system01.dbf

channel ORA_DISK_1: restoring datafile00002 to /oracle/CRM/CRM/sysaux01.dbf

channel ORA_DISK_1: restoring datafile00003 to /oracle/CRM/CRM/undotbs01.dbf

channel ORA_DISK_1: restoring datafile00004 to /oracle/CRM/CRM/users01.dbf

channel ORA_DISK_1: restoring datafile00005 to /oracle/CRM/CRM/crm.dbf

channel ORA_DISK_1: restoring datafile00006 to /oracle/CRM/test.dbf

channel ORA_DISK_1: restoring datafile00007 to /oracle/CRM/user01.dbf

channel ORA_DISK_1: restoring datafile00008 to /oracle/CRM/jxc.dbf

channel ORA_DISK_1: reading from backuppiece /backup/fullbk-20140217-3ep0rj0h_1_1.bak

channel ORA_DISK_1: piecehandle=/backup/fullbk-20140217-3ep0rj0h_1_1.bak tag=TAG20140217T120328

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete,elapsed time: 00:02:08

Finished restore at 2014-02-17 16:38:35

 

注意：restore後咱們經過查詢x$kcvfh的redo字節地址(RBA)的seq號(也就是是FHRBA_SEQ字段)能夠獲得restore database 後數據文件頭部記錄的rba.seq號, 該值近一步代表recover過程須要從seq號爲59歸檔開始應用。

 

或者也能夠從restore database後數據文件頭部的scn值，對比歸檔的first_change# 和 next_change# 推斷出recover 須要應用歸檔開始。

 

SQL> select hxfil,fhscn,fhrba_seq fromx$kcvfh;

 

   HXFIL FHSCN             FHRBA_SEQ

---------- ---------------- ----------

       1 4028039                  59

       2 4028039                 59

       3 4028039                  59

       4 4028039                  59

       5 4028039                  59

       6 4028039                  59

       7 4028039                  59

       8 4028039                  59

 

8 rows selected.

 

固然restore database 後，咱們也能夠直接查詢v$recvoery_log來獲得recover過程須要應用的歸檔條目，以下所示：

select * from v$recovery_log;

 

 THREAD#  SEQUENCE# TIME      ARCHIVE_NAME

---------- ---------- --------- ------------------------------------------------------------

       1         59 17-FEB-14/oracle/archivelog/arch_1_59_839098938.arch

       1         60 17-FEB-14/oracle/archivelog/arch_1_60_839098938.arch

       1         61 17-FEB-14 /oracle/archivelog/arch_1_61_839098938.arch

       1         62 17-FEB-14/oracle/archivelog/arch_1_62_839098938.arch

       1         63 17-FEB-14/oracle/archivelog/arch_1_63_839098938.arch

       1         64 17-FEB-14/oracle/archivelog/arch_1_64_839098938.arch

       1         65 17-FEB-14/oracle/archivelog/arch_1_65_839098938.arch

       1         66 17-FEB-14/oracle/archivelog/arch_1_66_839098938.arch

 

 

RMAN> recover database;

 

Starting recover at 2014-02-17 16:45:01

using channel ORA_DISK_1

 

starting media recovery

 

archived log for thread 1 with sequence 59is already on disk as file /oracle/archivelog/arch_1_59_839098938.arch

archived log for thread 1 with sequence 60is already on disk as file /oracle/archivelog/arch_1_60_839098938.arch

archived log for thread 1 with sequence 61is already on disk as file /oracle/archivelog/arch_1_61_839098938.arch

archived log for thread 1 with sequence 62is already on disk as file /oracle/archivelog/arch_1_62_839098938.arch

archived log for thread 1 with sequence 63is already on disk as file /oracle/archivelog/arch_1_63_839098938.arch

archived log for thread 1 with sequence 64is already on disk as file /oracle/archivelog/arch_1_64_839098938.arch

archived log for thread 1 with sequence 65is already on disk as file /oracle/archivelog/arch_1_65_839098938.arch

archived log for thread 1 with sequence 66is already on disk as file /oracle/archivelog/arch_1_66_839098938.arch

archived log for thread 1 with sequence 67is already on disk as file /oracle/archivelog/arch_1_67_839098938.arch

archived log for thread 1 with sequence 68is already on disk as file /oracle/archivelog/arch_1_68_839098938.arch

archived log filename=/oracle/archivelog/arch_1_59_839098938.arch thread=1 sequence=59

archived log file name=/oracle/archivelog/arch_1_60_839098938.archthread=1 sequence=60

archived log filename=/oracle/archivelog/arch_1_61_839098938.arch thread=1 sequence=61

archived log filename=/oracle/archivelog/arch_1_62_839098938.arch thread=1 sequence=62

archived log filename=/oracle/archivelog/arch_1_63_839098938.arch thread=1 sequence=63

archived log filename=/oracle/archivelog/arch_1_64_839098938.arch thread=1 sequence=64

archived log filename=/oracle/archivelog/arch_1_65_839098938.arch thread=1 sequence=65

archived log filename=/oracle/archivelog/arch_1_66_839098938.arch thread=1 sequence=66

media recovery complete, elapsed time:00:00:08

Finished recover at 2014-02-17 16:45:16

注意：這裏能夠清楚的看到應用的歸檔條目（紅色標記處）

 

7 跟蹤recover過程內容以下：

 

alter database recoverlogfile '/oracle/archivelog/arch_1_59_839098938.arch'

Media Recovery Log/oracle/archivelog/arch_1_59_839098938.arch

Mon Feb 17 16:45:12 2014

ORA-279 signalled during: alter databaserecover logfile '/oracle/archivelog/arch_1_59_839098938.arch'...

alter database recoverlogfile '/oracle/archivelog/arch_1_60_839098938.arch'

Media Recovery Log/oracle/archivelog/arch_1_60_839098938.arch

ORA-279 signalled during: alter databaserecover logfile '/oracle/archivelog/arch_1_60_839098938.arch'...

alter database recoverlogfile '/oracle/archivelog/arch_1_61_839098938.arch'

Media Recovery Log/oracle/archivelog/arch_1_61_839098938.arch

 

ORA-279 signalled during: alter databaserecover logfile '/oracle/archivelog/arch_1_61_839098938.arch'...

alter database recoverlogfile '/oracle/archivelog/arch_1_62_839098938.arch'

Media Recovery Log/oracle/archivelog/arch_1_62_839098938.arch

ORA-279 signalled during: alter databaserecover logfile '/oracle/archivelog/arch_1_62_839098938.arch'...

alter database recoverlogfile '/oracle/archivelog/arch_1_63_839098938.arch'

Media Recovery Log/oracle/archivelog/arch_1_63_839098938.arch

ORA-279 signalled during: alter databaserecover logfile '/oracle/archivelog/arch_1_63_839098938.arch'...

alter database recoverlogfile '/oracle/archivelog/arch_1_64_839098938.arch'

Media Recovery Log/oracle/archivelog/arch_1_64_839098938.arch

ORA-279 signalled during: alter databaserecover logfile '/oracle/archivelog/arch_1_64_839098938.arch'...

alter database recoverlogfile '/oracle/archivelog/arch_1_65_839098938.arch'

Media Recovery Log/oracle/archivelog/arch_1_65_839098938.arch

ORA-279 signalled during: alter databaserecover logfile '/oracle/archivelog/arch_1_65_839098938.arch'...

alter database recoverlogfile '/oracle/archivelog/arch_1_66_839098938.arch'

Media Recovery Log/oracle/archivelog/arch_1_66_839098938.arch

Mon Feb 17 16:45:14 2014

Recovery of Online RedoLog: Thread 1 Group 1 Seq 67 Reading mem 0

Mem# 0: /oracle/CRM/CRM/redo01.log

Recovery of Online RedoLog: Thread 1 Group 2 Seq 68 Reading mem 0

Mem# 0: /oracle/CRM/CRM/redo02.log

Recovery of Online RedoLog: Thread 1 Group 3 Seq 69 Reading mem 0

Mem# 0: /oracle/CRM/CRM/redo03.log

Media Recovery Complete(CRM)

 

注意：經過跟蹤整個恢復過程，能夠清楚的觀察到在用recover進行徹底恢復時，先應用歸檔，後再經過全部聯機日誌文件推動整個數據庫來實現徹底恢復的過程。

 

 

8 若是數據庫進行不徹底恢復如何獲取恢復所須要的歸檔

 

以基於時間點恢復爲例，咱們能夠這麼使用得出恢復到這個時間點數據庫須要的歸檔列表。

 

run{

sql 'alter session setnls_date_format="yyyy-mm-dd hh24:mi:ss"';

set until time='2013-12-09:05:50:12';

restore database preview;

}

 

總結：

1 在對數據庫進行恢復的時，第一步先看看數據庫是否歸檔，第二步看看數據庫是否有備份，第三步驗證備份和歸檔的有效性。最後執行整個恢復過程。

 

2 徹底恢復時，經過對比restore database preview 顯示的歸檔列表seq號和聯機日誌組的seq號，咱們即可以清楚的推出數據庫徹底恢復時，recover須要應用的歸檔。

 

本文出自 「myblog」 博客，請務必保留此出處http://jiujian.blog.51cto.com/444665/1361353