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

最新推荐文章于 2021-12-15 15:04:00 发布

cri5768

最新推荐文章于 2021-12-15 15:04:00 发布

阅读量151

点赞数

文章标签：数据库网络

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 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://blog.itpub.net/7728585/viewspace-761206/

cri5768

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫