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

在前面的议题中实际上已经对rman的备份恢复做了个比较完整的介绍，谈到了数据库，表空间，参数文件，控制文件的备份，同时也谈到

在前面的议题中实际上已经对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）恢复

基于时间的恢复将数据库恢复到备份点与失败点之间的某个时间点。基于时间的恢复不仅在介质失败的时候使用，也可以在数据库正常运行的时候使用。例如：某个用户误删除了某个表的数据，这个时候我们可以通过基于时间的恢复来将删除的数据恢复出来，示例如下：

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>

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:{=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