RAC下归档不放到共享盘的测试。
11.2.0.3 测试，因为11.2.0.3加入了SCAN_IP我们使用VIP连接默认情况下是连接到特定的实例所以
设置
RAC1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.143)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = racdb)
)
)
RAC2 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.144)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
备份使用语句
run {
allocate channel c1 device type disk connect sys/gelc123@RAC1;
allocate channel c2 device type disk connect sys/gelc123@RAC2;
backup format='/home/oracle/bak_%t_%s_%p.bak' database plus archivelog delete all input format '/home/oracle/arch_%t_%s_%p.bak';
release channel c1;
release channel c2;
}
当然最后自己显示备份一下控制文件比较好
测试1 能否进行完全恢复
猜测:虽然在节点2通过设置通道完成了备份，但是当节点1如果进行了日志切换也就是说生成了新的归档日志，这部分日志是不能进行恢复的，只能进行不完全恢复
1、在节点1进行几次日志切换，然后查看日志生成
QL> alter system switch logfile;
System altered.
SQL> r
1* alter system switch logfile
System altered.
[oracle@rac1 admin]$ cd /home/oracle/archive/
[oracle@rac1 archive]$ ls
1_49_811227726.dbf 1_50_811227726.dbf
2、关闭数据库
srvctl stop database -d racdb
3、拷贝节点的备份到节点2，也包括控制文件
[oracle@rac1 dbs]$ scp c-808844491-20130329-03 192.168.1.142:/oracle/app/oracle/product/11.2.0/dbs/
c-808844491-20130329-03 100% 18MB 17.7MB/s 00:00
[oracle@rac1 ~]$ scp *.bak 192.168.1.142:/home/oracle/
arch_814692392_20_1.bak 100% 397MB 36.1MB/s 00:11
arch_814692412_22_1.bak 100% 146KB 145.5KB/s 00:00
arch_814692413_24_1.bak 100% 6144 6.0KB/s 00:00
arch_814692413_26_1.bak 100% 3584 3.5KB/s 00:00
arch_814692414_28_1.bak 100% 1380KB 1.4MB/s 00:00
arch_814692446_31_1.bak 100% 7168 7.0KB/s 00:00
bak_814692419_29_1.bak 100% 538MB 38.4MB/s 00:14
注意如果是备份到磁带这一步是不需要的。
4、启动节点的实例到MOUNT节点进行恢复控制文件，然后启动MOUNT阶段
RMAN> restore controlfile from '/oracle/app/oracle/product/11.2.0/dbs/c-808844491-20130329-03';
Starting restore at 06-MAY-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=139 instance=racdb2 device type=DISK
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:12
output file name=+DATA/racdb/controlfile/current.260.811227723
Finished restore at 06-MAY-13
RMAN> sql 'alter database mount';
5、进行完全恢复
RMAN> restore database;
Starting restore at 06-MAY-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=125 instance=racdb2 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00002 to +DATA/racdb/datafile/sysaux.257.811227637
channel ORA_DISK_1: restoring datafile 00005 to +DATA/racdb/datafile/example.264.811227735
channel ORA_DISK_1: restoring datafile 00006 to +DATA/racdb/datafile/undotbs2.265.811227979
channel ORA_DISK_1: reading from backup piece /home/oracle/bak_814692419_29_1.bak
channel ORA_DISK_1: piece handle=/home/oracle/bak_814692419_29_1.bak tag=TAG20130506T072658
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to +DATA/racdb/datafile/system.256.811227637
channel ORA_DISK_1: restoring datafile 00003 to +DATA/racdb/datafile/undotbs1.258.811227637
channel ORA_DISK_1: restoring datafile 00004 to +DATA/racdb/datafile/users.259.811227637
channel ORA_DISK_1: reading from backup piece /home/oracle/bak_814692419_30_1.bak
channel ORA_DISK_1: piece handle=/home/oracle/bak_814692419_30_1.bak tag=TAG20130506T072658
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:15
Finished restore at 06-MAY-13
RMAN> recover database;
Starting recover at 06-MAY-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=125 instance=racdb2 device type=DISK
starting media recovery
archived log for thread 1 with sequence 50 is already on disk as file +DATA/racdb/onlinelog/group_2.262.811227727
archived log for thread 1 with sequence 51 is already on disk as file +DATA/racdb/onlinelog/group_1.261.811227727
archived log for thread 2 with sequence 65 is already on disk as file +DATA/racdb/onlinelog/group_3.266.811228159
archived log for thread 2 with sequence 66 is already on disk as file +DATA/racdb/onlinelog/group_4.267.811228161
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=48
channel ORA_DISK_1: reading from backup piece /home/oracle/arch_814692446_31_1.bak
channel ORA_DISK_1: piece handle=/home/oracle/arch_814692446_31_1.bak tag=TAG20130506T072726
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/home/oracle/archive/1_48_811227726.dbf thread=1 sequence=48
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=2 sequence=64
channel ORA_DISK_1: reading from backup piece /home/oracle/arch_814692447_32_1.bak
channel ORA_DISK_1: piece handle=/home/oracle/arch_814692447_32_1.bak tag=TAG20130506T072726
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/home/oracle/archive/2_64_811227726.dbf thread=2 sequence=64
archived log file name=+DATA/racdb/onlinelog/group_3.266.811228159 thread=2 sequence=65
unable to find archived log
archived log thread=1 sequence=49
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 05/06/2013 09:25:58
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 49 and starting SCN of 4095531
可以看到确实和我们猜测一样的找不到1_49_811227726.dbf。
测试2 通过拷贝的方式把归档拷贝过来
猜测：这样应该没问题了
[oracle@rac1 archive]$ scp * 192.168.1.142:/home/oracle/archive
1_49_811227726.dbf 100% 1024 1.0KB/s 00:00
1_50_811227726.dbf 100% 1024 1.0KB/s 00:00
继续恢复
RMAN> recover database;
Starting recover at 06-MAY-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=144 instance=racdb2 device type=DISK
starting media recovery
archived log for thread 1 with sequence 50 is already on disk as file +DATA/racdb/onlinelog/group_2.262.811227727
archived log for thread 1 with sequence 51 is already on disk as file +DATA/racdb/onlinelog/group_1.261.811227727
archived log for thread 2 with sequence 65 is already on disk as file +DATA/racdb/onlinelog/group_3.266.811228159
archived log for thread 2 with sequence 66 is already on disk as file +DATA/racdb/onlinelog/group_4.267.811228161
archived log file name=/home/oracle/archive/1_49_811227726.dbf thread=1 sequence=49
archived log file name=+DATA/racdb/onlinelog/group_3.266.811228159 thread=2 sequence=65
archived log file name=+DATA/racdb/onlinelog/group_2.262.811227727 thread=1 sequence=50
archived log file name=+DATA/racdb/onlinelog/group_1.261.811227727 thread=1 sequence=51
archived log file name=+DATA/racdb/onlinelog/group_4.267.811228161 thread=2 sequence=66
Finished recover at 06-MAY-13
RMAN> sql 'alter database open';
可以看到恢复已经完成并且数据库已经已经打开，并且是应用我们的当前日志文件的。所以是可以完全恢复的。
测试3 RAC中的不完全恢复应该以低SCN为准，比如实例1的NEXT SCN为222 实例2的NEXT SCN为221 ，那么恢复的recover database until scn 221,很好理解虽然RAC中的LOGFILE的seq是不相同的但是SCN一定的一致的，同样的1-221的记录都分别在两个实例的
归档日志中，但是221-222的只有实例1有实例2根本没有，当然就不能恢复。
如下：
SEQUENCE# TIME_D CHANGE#
---------------------------------------- --------------------------------------- -----------------
---- 2013-05-06 07:26:59 4095499
---- 2013-05-06 07:26:59 4095499
---- 2013-05-06 07:26:59 4095499
---- 2013-05-06 07:26:59 4095497
---- 2013-05-06 07:26:59 4095497
---- 2013-05-06 07:26:59 4095497
64 2013-05-06 07:26:11=2013-05-06 07:27:15 4095359=4095528
48 2013-05-06 07:26:10=2013-05-06 07:27:16 4095356=4095531
47 2013-05-06 07:08:29=2013-05-06 07:26:10 4091232=4095356
63 2013-05-06 07:08:28=2013-05-06 07:26:11 4091229=4095359
62 2013-05-06 07:06:16=2013-05-06 07:08:28 4091028=4091229
46 2013-05-06 07:06:15=2013-05-06 07:08:29 4091024=4091232
45 2013-05-06 07:06:14=2013-05-06 07:06:15 4091021=4091024
44 2013-05-06 07:06:13=2013-05-06 07:06:14 4091018=4091021
61 2013-05-06 07:06:11=2013-05-06 07:06:16 4091014=4091028
60 2013-05-06 07:06:07=2013-05-06 07:06:11 4091010=4091014
可以看到这个恢复如果在只有备份集的情况下只能恢复到4095528而非4095531，也能看到RAC中SEQ的不同。
如果恢复到4095531报错
RMAN> recover database until scn 4095531;
Starting recover at 06-MAY-13
using channel ORA_DISK_1
starting media recovery
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=48
channel ORA_DISK_1: reading from backup piece /home/oracle/arch_814692446_31_1.bak
channel ORA_DISK_1: piece handle=/home/oracle/arch_814692446_31_1.bak tag=TAG20130506T072726
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/home/oracle/archive/1_48_811227726.dbf thread=1 sequence=48
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=2 sequence=64
channel ORA_DISK_1: reading from backup piece /home/oracle/arch_814692447_32_1.bak
channel ORA_DISK_1: piece handle=/home/oracle/arch_814692447_32_1.bak tag=TAG20130506T072726
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/home/oracle/archive/2_64_811227726.dbf thread=2 sequence=64
unable to find archived log
archived log thread=2 sequence=65
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 05/06/2013 10:01:25
RMAN-06054: media recovery requesting unknown archived log for thread 2 with sequence 65 and starting SCN of 4095528
但是我们再次RESTORE recover到4095528如下：
RMAN> recover database until scn 4095528;
Starting recover at 06-MAY-13
using channel ORA_DISK_1
starting media recovery
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=48
channel ORA_DISK_1: reading from backup piece /home/oracle/arch_814692446_31_1.bak
channel ORA_DISK_1: piece handle=/home/oracle/arch_814692446_31_1.bak tag=TAG20130506T072726
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/home/oracle/archive/1_48_811227726.dbf thread=1 sequence=48
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=2 sequence=64
channel ORA_DISK_1: reading from backup piece /home/oracle/arch_814692447_32_1.bak
channel ORA_DISK_1: piece handle=/home/oracle/arch_814692447_32_1.bak tag=TAG20130506T072726
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/home/oracle/archive/2_64_811227726.dbf thread=2 sequence=64
media recovery complete, elapsed time: 00:00:00
Finished recover at 06-MAY-13
可以看到恢复完成。接下来只有resetlogs丢数据时不能避免的。
所以虽然归档不共享的情况下备份没有问题，但是恢复只能在一个实例完成。如果放到磁带上也不需要拷贝备份集，但是如果是在各自的存储中是需要拷贝备份集到恢复节点上，因为每个节点都只有备份的一部分而已。
不管是磁带还是各自存储，新生成的归档时需要拷贝的到恢复端的。所以还是比较麻烦，还不如使用共享NFS当然ASM是更好的。
