1. 首页
  2. IT资讯

RAC下归档不放到共享盘的测试

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是更好的。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/7728585/viewspace-761206/,如需转载,请注明出处,否则将追究法律责任。

主题测试文章,只做测试使用。发布者:深沉的少年,转转请注明出处:http://www.cxybcw.com/183748.html

联系我们

13687733322

在线咨询:点击这里给我发消息

邮件:1877088071@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息

QR code