RMAN中三个不完全恢复场景
RMAN中三个不完全恢复场景
RMAN在数据的备份恢复中还是发挥了重大的作用，把冷备，热备这种手工备份方式做了集成化的管理，可以基于这个工具集完成相对复杂额备份恢复工作。
当然了RMAN相对于传统的手工备份，提供了更多的改进， 比如压缩备份，我们手工测试的场景中，一个1.5G的小库，如果数据文件的使用率不到300M，那么生成的dump就在近300M，如果开启压缩备份的方式，生成的备份集差不多会在80M左右，改进的幅度还是很大的。比如并行备份，开启多个通道对于数据库中的多个数据文件备份进行分工，还可以在这个基础上进行备份切分，把一个很大的备份集切分成多个指定单位大小的备份分片。
比如备份的加密方式，从安全性上也可以保证。
比如增量备份，这种方式通过手工方式是完成不了的。增量备份把数据的备份工作可以当做一个很有规划性的工作来做。
当然备份是基础，数据的恢复在这个基础上就更为重要了。如果数据恢复不了，备份的意义就会大打折扣。
自己做了下面三个简单的测试，属于三个不完全恢复额场景，我们来看看在手工备份恢复的繁琐之外，RMAN下是怎么做的，有哪些改进，有些时候还可能需要动用一些非常规手段。
第一个例子是一个删除用户的例子，我们已经存在一个备份，归档都保留着，然后我们在制定的时间删除了数据库中某个用户，然后尝试基于时间点的不完全恢复
目前我们存在下面的数据库用户，我们就拿newtest这个用户开刀。
SQL> select *from all_users;
USERNAME USER_ID CREATED
------------------------------ ---------- ---------
TEST_UPDATE 33 29-JUL-15
NEWTEST 32 19-JUL-15
MGMT_VIEW 30 05-JUL-15
DBSNMP 24 04-JUL-15
TSMSYS 21 04-JUL-15
SYSMAN 28 05-JUL-15
DIP 19 04-JUL-15
OUTLN 11 04-JUL-15
SYSTEM 5 04-JUL-15
SYS 0 04-JUL-15
10 rows selected.
为了进行回复后的验证，我们随便拿出一个有数据的表来做一个基本的验证。
SQL> conn newtest/newtest
Connected.
SQL> select count(*)from t;
COUNT(*)
----------
6338
然后开始我们的不完全恢复。从下面可以看到目前的日志已经做了resetlogs启动，序列是从1开始，但是在10g之后，resetlogs 启动数据库，原来的备份依然可用。
SQL> select sequence#,status from v$log;
SEQUENCE# STATUS
---------- ----------------
1 CURRENT
0 UNUSED
0 UNUSED
我们标记一下时间戳，然后删除这个用户
SQL> select systimestamp from dual;
SYSTIMESTAMP
---------------------------------------------------------------------------
02-AUG-15 09.19.56.666830 PM +08:00
SQL> drop user newtest cascade;
User dropped.
破坏之后，我们停库启动到mount阶段，开始做不完全恢复
SQL> shutdown immediate
Database closed.
Database dismounted.
Oracle instance shut down.
通过rman来恢复，步骤就相对简单多了。
RMAN> startup mount
Oracle instance started
database mounted
Total System Global Area 314572800 bytes
Fixed Size 1261564 bytes
Variable Size 163577860 bytes
Database Buffers 142606336 bytes
Redo Buffers 7127040 bytes
RMAN> run
2> {
3> set until time "to_date('2015-08-02:21:19:56','YYYY-MM-DD HH24:MI:SS')";
4> restore database;
5> recover database;
6> }
这样后台就会自动去完成还原和恢复的工作，恢复的部分日志如下：
starting media recovery
archive log thread 1 sequence 9 is already on disk as file /u02/oracle/flash_recovery_area/TEST10G/archivelog/2015_08_02/o1_mf_1_9_bvw5nrd2_.arc
archive log thread 1 sequence 10 is already on disk as file /u02/oracle/flash_recovery_area/TEST10G/archivelog/2015_08_02/o1_mf_1_10_bvw60std_.arc
archive log filename=/u02/oracle/flash_recovery_area/TEST10G/archivelog/2015_08_02/o1_mf_1_9_bvw5nrd2_.arc thread=1 sequence=9
archive log filename=/u02/oracle/flash_recovery_area/TEST10G/archivelog/2015_08_02/o1_mf_1_10_bvw60std_.arc thread=1 sequence=10
media recovery complete, elapsed time: 00:00:09
Finished recover at 02-AUG-15
就这样就轻松完成了时间点的恢复，使用resetlogs的方式打开数据库。
RMAN> alter database open resetlogs;
database opened
我们简单验证一下用户是否已经恢复回来。可以看到一切都在预料之中。
SQL> conn newtest/newtest
Connected.
SQL> select count(*)from t;
COUNT(*)
----------
6338
:
第二个例子是一个相对来说暴力的破坏，我们删除了所有的数据文件，日志文件，控制文件。然后尝试恢复。
先是破坏，我们到数据文件的目录下，删除全部文件
$ rm *
然后使用rman把数据库启动到nomount阶段，开始尝试恢复控制文件。
[oracle@oel1 TEST10G]$ rman target /
Recovery Manager: Release 10.2.0.3.0 - Production on Sun Aug 2 21:33:24 2015
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database (not started)
RMAN> startup nomount
Oracle instance started
Total System Global Area 314572800 bytes
Fixed Size 1261564 bytes
Variable Size 163577860 bytes
Database Buffers 142606336 bytes
Redo Buffers 7127040 bytes
这个时候查看rman的配置会发现，原有的配置都会丢失，因为我们删除了所有的数据。
RMAN> show all;
这个时候如果还原控制文件，指定autobackup就会报错，因为配置丢失，压根找不到备份的配置。
RMAN> restore controlfile from autobackup;
Starting restore at 02-AUG-15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=34 devtype=DISK
recovery area destination: /u02/oracle/flash_recovery_area
database name (or database unique name) used for search: TEST10G
channel ORA_DISK_1: no autobackups found in the recovery area
autobackup search outside recovery area not attempted because DBID was not set
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 08/02/2015 21:33:49
RMAN-06172: no autobackup found or specified handle is not a valid copy or piece
这个时候，我们可以手工指定需要还原参照的控制文件备份即可。
比如我们在备份目录下看到最新的控制文件备份，直接应用还原。
RMAN> restore controlfile from '/u02/oracle/flash_recovery_area/TEST10G/ctl_c-1135735312-20150802-0b';
Starting restore at 02-AUG-15
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=38 devtype=DISK
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
output filename=/u02/oracle/oradata/TEST10G/control01.ctl
output filename=/u02/oracle/oradata/TEST10G/control02.ctl
Finished restore at 02-AUG-15
然后数据库启动到Mount阶段，开始还原和恢复数据库，
RMAN> run{
2> restore database;
3> recover database;
4> }
还原还是很平滑的过程，关键就在于恢复的过程，最后肯定会抛出一些问题来，类似下面的形式。
unable to find archive log
archive log thread=1 sequence=1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/02/2015 21:37:15
RMAN-06054: media recovery requesting unknown log: thread 1 seq 1 lowscn 1151365
这个时候我们就需要做不完全恢复，我们来采用基于sequence的恢复。
RMAN> run{
2> set until sequence 1;
3> recover database;
4> }
然后使用resetlogs的方式就可以打开数据库了。
RMAN> alter database open resetlogs;
database opened
这种方式也还是相对比较简单的过程。
第三种场景略微复杂。
如果存在备份，但是备份集出现了一些问题，或者出现���一些归档文件的缺失，restore可以顺利完成，但是在recover的时候会报出下面的错误来。
RMAN> recover database;
Starting recover at 02-AUG-15
using channel ORA_DISK_1
using channel ORA_DISK_2
starting media recovery
unable to find archived log
archived log thread=1 sequence=1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/02/2015 12:26:43
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 1 and starting SCN of 1094536
这种情况下采用基于sequence的不完全恢复也没有基础。
如果这个时候我们无招可用，看看resetlogs的方式能不能启动数据库，会有下面的错误。
RMAN> alter database open resetlogs;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 08/02/2015 12:28:06
ORA-01152: file 3 was not restored from a sufficiently old backup
ORA-01110: data file 3: '/u02/ora11g/oradata/TEST/undotbs01.dbf'
可见还是备份集出现一些问题，主要原因还是控制文件中记录的scn号和备份集中的scn出现了gap,尝试恢复的时候又没有相应的归档。
我们可以采用隐含参数来做，
在pfile中加入下面的三个隐含参数
_allow_resetlogs_corruption=true
_corrupted_rollback_segments=true
_offline_rollback_segments=true
然后，重新启动数据库到mount阶段之后，使用resetlogs的方式即可强制打开数据库。
这种方式存在着一定的风险，但是也是无奈的场景下的一种方式。毕竟数据库能够open是一个很重要的检查点，数据库都启动不了的话，整个恢复的意义就会大打折扣了。
所以通过上面的三个简单的例子，可以看到在数据的不完全恢复中，还是有很多的选择，不完全恢复相对于完全恢复来说，场景真是数不胜数，各种破坏各种坑。合理利用手中的备份是我们数据恢复的一个基础。
--------------------------------------推荐阅读 --------------------------------------
RMAN备份时遭遇ORA-19571
RMAN 配置归档日志删除策略
Oracle基础教程之通过RMAN复制数据库
RMAN备份策略制定参考内容
RMAN备份学习笔记
Oracle数据库备份加密 RMAN加密
RMAN备份时遇到ORA-19588
--------------------------------------分割线 --------------------------------------
评论暂时关闭