探索Oracle之RMAN_07非一致性恢複（集合）

在前面的議題中實際上已經對rman的備份恢複做了個比較完整的介紹，談到了資料庫，資料表空間，參數檔案，控制檔案的備份，同時也談到了它們的恢複，當然還包括了災難性的恢複。對於那些恢複實際上已經用到了我們今天所要說的非一致性恢複，只不過沒有說明罷了。什麼叫非一致性恢複，非一致性恢複就是在恢複的過程中會有部分資料丟失。

那麼非一致性恢複主要應用於在控制檔案，重做記錄檔，或者歸檔記錄檔失敗，資料庫的完全介質恢複將無法進行的時候，為使損失達到最小，這個時候才可執行資料庫的不一致性恢複。

相關閱讀：

探索Oracle之RMAN_01概念

探索Oracle之RMAN_02基本使用

探索Oracle之RMAN_03非一致性備份

探索Oracle之RMAN_04非一致性備份

探索Oracle之RMAN_05增量備份

探索Oracle之RMAN_06備份策略

探索Oracle之RMAN_07單個資料檔案丟失恢複

探索Oracle之RMAN_07整個業務資料表空間丟失恢複

探索Oracle之RMAN_07 磁碟損壞資料丟失恢複

探索Oracle之RMAN_07 資料庫所有檔案全部丟失恢複

探索Oracle之RMAN_07 重做日誌redu檔案丟失恢複

探索Oracle之RMAN_07 參數檔案丟失恢複

探索Oracle之RMAN_07控制檔案丟失恢複

探索Oracle之RMAN_07 system資料表空間丟失恢複

我們可以通過如來理解什麼是非一致性恢複：

     

 

        上中，資料庫在100的時候已經做了全備，重做日誌已經捕獲了100-500之間的SCN，並同歸redo應用歸檔，當在500的時候，資料庫發生了介質失敗；那麼這個時候要做資料庫的恢複就要用到在scn 100時做的備份以及100-500這期間所產生的歸檔和重做日誌資訊。如果說歸檔在scn 300的時候損壞了，那麼這個時候就只能恢複到scn為200的這個點，這也就是我們說的資料庫的不完全恢複.

 

非一致性恢複的類型主要分為以下四種：

  基於時間（time）恢複

  基於取消（cancel）恢複

  基於SCN（change）恢複

  基於備份控制檔案（unsing backup controlfile）的恢複

 

基於時間（time）恢複

基於時間的恢複將資料庫恢複到備份點與失敗點之間的某個時間點。基於時間的恢複不僅在介質失敗的時候使用，也可以在資料庫正常啟動並執行時候使用。例如：某個使用者誤刪除了某個表的資料，這個時候我們可以通過基於時間的恢複來將刪除的資料恢複出來，樣本如下：

 

1、查看目前使用者下的表，只有一張WWL001

21:07:31 SQL> select * fromtab;

 

TNAME                          TABTYPE  CLUSTERID

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

WWL001                         TABLE

Elapsed: 00:00:00.06

 

我們通過WWL001來建立WWL002-WWL005 共四張表用來測試不完全恢複

21:08:28 SQL> create tablewwl002 as select * from wwl001;

Table created.

Elapsed: 00:00:00.17

 

21:08:55 SQL> create tablewwl003 as select * from wwl001;

Table created.

Elapsed: 00:00:00.04

 

21:09:00 SQL> create tablewwl004 as select * from wwl001;

Table created.

Elapsed: 00:00:00.03

 

21:09:06 SQL> create tablewwl005 as select * from wwl001;

Table created.

Elapsed: 00:00:00.05

如上表已經建立完成

 

2、我們在21:13:13開始刪除表（請注意時間）

21:13:13 SQL> drop tablewwl002 purge;

Table dropped.

Elapsed: 00:00:00.16

 

21:13:28 SQL> drop tablewwl003 purge;

Table dropped.

Elapsed: 00:00:00.11

 

21:13:34 SQL> truncate tablewwl004;

Table truncated.

Elapsed: 00:00:00.32

 

21:13:44 SQL> truncate tablewwl005;

Table truncated.

Elapsed: 00:00:00.07

21:13:47 SQL>

 

因為我們是要做基於時間的恢複，那麼我們只有將資料庫恢複到21:13:13之前的這個時間段，才能把我們剛才建立的表找回來。

 

3、開始執行恢複，先將資料庫啟動到mount狀態

21:14:40 SQL> conn / assysdba

Connected.

21:14:44 SQL> shutdownimmediate

Database closed.

Database dismounted.

ORACLE instance shut down.

21:15:20 SQL> startup  mount;

ORACLE instance started.

 

Total System Global Area  100663296 bytes

Fixed Size                  1217884 bytes

Variable Size              88083108 bytes

Database Buffers            8388608 bytes

Redo Buffers                2973696 bytes

Database mounted.

21:15:46 SQL> e

 

4、開始執行restore到備份資料庫的目前狀態：

RMAN> restore database;

 

Starting restore at 12-JUL-12

using target database controlfile instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=47devtype=DISK

 

channel ORA_DISK_1: startingdatafile backupset restore

channel ORA_DISK_1: specifyingdatafile(s) to restore from backup set

restoring datafile 00001 to/DBBak2/oradata/WWL/system01.dbf

restoring datafile 00002 to/DBBak2/oradata/WWL/undotbs01.dbf

restoring datafile 00003 to/DBBak2/oradata/WWL/sysaux01.dbf

restoring datafile 00004 to/DBBak2/oradata/WWL/users01.dbf

restoring datafile 00005 to/DBBak2/oradata/WWL/wwl01.dbf

restoring datafile 00006 to/DBBak2/oradata/WWL/wwl02.dbf

restoring datafile 00007 to/DBBak2/oradata/WWL/wwl03.dbf

channel ORA_DISK_1: readingfrom backup piece /DBSoft/product/10.2.0/db_1/dbs/01nft4mu_1_1

channel ORA_DISK_1: restoredbackup piece 1

piecehandle=/DBSoft/product/10.2.0/db_1/dbs/01nft4mu_1_1 tag=TAG20120712T095437

channel ORA_DISK_1: restorecomplete, elapsed time: 00:01:35

Finished restore at 12-JUL-12

 

RMAN> exit

 

5、執行基於時間點的恢複：

21:27:54 SQL> recover database until time ‘YYYY-mm-ddhh24:mi:ss’

21:27:54 SQL> recoverdatabase until time '2012-07-12 21:10:00';

ORA-00279: change 1436429generated at 07/12/2012 09:54:38 needed for thread 1

ORA-00289: suggestion :/DBSoft/product/10.2.0/db_1/dbs/arch1_3_788372282.dbf

ORA-00280: change 1436429 forthread 1 is in sequence #3

 

 

21:30:09 Specify log:{<RET>=suggested | filename | AUTO | CANCEL}

auto

ORA-00279: change 1440657generated at 07/12/2012 14:00:52 needed for thread 1

ORA-00289: suggestion :/DBSoft/product/10.2.0/db_1/dbs/arch1_1_788450452.dbf

ORA-00280: change 1440657 forthread 1 is in sequence #1

 

 

ORA-00279: change 1440855generated at 07/12/2012 15:08:58 needed for thread 1

ORA-00289: suggestion :/DBSoft/product/10.2.0/db_1/dbs/arch1_1_788454538.dbf

ORA-00280: change 1440855 forthread 1 is in sequence #1

 

 

ORA-00279: change 1441316generated at 07/12/2012 15:19:50 needed for thread 1

ORA-00289: suggestion :/DBSoft/product/10.2.0/db_1/dbs/arch1_1_788455190.dbf

ORA-00280: change 1441316 forthread 1 is in sequence #1

 

 

ORA-00279: change 1442275generated at 07/12/2012 15:52:01 needed for thread 1

ORA-00289: suggestion :/DBSoft/product/10.2.0/db_1/dbs/arch1_1_788457121.dbf

ORA-00280: change 1442275 forthread 1 is in sequence #1

 

 

ORA-00279: change 1442953generated at 07/12/2012 16:25:06 needed for thread 1

ORA-00289: suggestion :/DBSoft/product/10.2.0/db_1/dbs/arch1_1_788459106.dbf

ORA-00280: change 1442953 forthread 1 is in sequence #1

 

 

ORA-00279: change 1462958generated at 07/12/2012 16:28:16 needed for thread 1

ORA-00289: suggestion :/DBSoft/product/10.2.0/db_1/dbs/arch1_2_788459106.dbf

ORA-00280: change 1462958 forthread 1 is in sequence #2

ORA-00278: log file'/DBSoft/product/10.2.0/db_1/dbs/arch1_1_788459106.dbf' no longer needed forthis recovery

 

 

ORA-00279: change 1462963generated at 07/12/2012 17:17:59 needed for thread 1

ORA-00289: suggestion :/DBSoft/product/10.2.0/db_1/dbs/arch1_1_788462279.dbf

ORA-00280: change 1462963 forthread 1 is in sequence #1

 

 

ORA-00279: change 1483784generated at 07/12/2012 17:54:25 needed for thread 1

ORA-00289: suggestion :/DBSoft/product/10.2.0/db_1/dbs/arch1_2_788462279.dbf

ORA-00280: change 1483784 forthread 1 is in sequence #2

ORA-00278: log file'/DBSoft/product/10.2.0/db_1/dbs/arch1_1_788462279.dbf' no longer needed forthis recovery

 

 

Log applied.

Media recovery complete.

21:30:29 SQL>

至此已經恢複完成。

 

6、因為做了不完全恢複，必須要做restlogs開啟資料庫。

21:30:29 SQL> alter databaseopen restlogs;

alter database open restlogs

1 2 3 4 5 6 下一頁