Step5:通过rman增量备份修复standby
很多时候oracle dataguard环境的primary database的归档日志会被误删.就是还没有来得及同步到备库的情况下.可能是网络原因也可能是其它的原因,正常这种情况下我们都开始尝试重新搭建dg,但是有的库非常大,重新搭建一次是件太痛苦的事情.下面我们就用rman增量备份来做恢复.
首先看到备库的alert log出现
Fetching gap sequence in thread 1, gap sequence 99-100
Tue Jul 30 07:03:21 2013
Fetching gap sequence in thread 1, gap sequence 99-100
Tue Jul 30 07:03:32 2013
Fetching gap sequence in thread 1, gap sequence 99-100
Tue Jul 30 07:03:42 2013
Fetching gap sequence in thread 1, gap sequence 99-100
Tue Jul 30 07:03:52 2013
Fetching gap sequence in thread 1, gap sequence 99-100
说明备库上面有几个归档日志没有同步过来,然后主库看99-100这两个已经删除.
1.首先确认standby的scn
SQL> select current_scn from v$database;
CURRENT_SCN
―――�C
281454SQL> select process,status from v$managed_standby;
PROCESS STATUS
――― ――――
ARCH CONNECTED
ARCH CONNECTED
ARCH CONNECTED
ARCH CONNECTED
RFS IDLE
RFS IDLE
RFS IDLE
MRP0 WAIT_FOR_GAP
RFS IDLE9 rows selected.
SQL> alter database recover managed standby database cancel;
Database altered.
SQL>
从上面可以看出来mrp正在等待99-100这两个gap,我们就先将应用进程停掉.接着也停掉standby database.
2.primary scn
SQL> select current_scn from v$database;
CURRENT_SCN
―――�C
281694SQL>
3.执行rman增量备份(primary)
[oracle@dg1 arch]$ rman target /
Recovery Manager: Release 11.2.0.2.0 �C Production on Tue Jul 30 04:15:23 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: DG (DBID=1735397445)
RMAN> backup incremental from scn 281454 database format ‘/u01/backupbk/forstandby_%U’ tag ‘standby’;
Starting backup at 30-JUL-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=88 device type=DISK
backup will be obsolete on date 06-AUG-13
archived logs will not be kept or backed up
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oradata/system.dbf
input datafile file number=00003 name=/u01/app/oradata/undotbs1.dbf
input datafile file number=00002 name=/u01/app/oradata/sysaux.dbf
channel ORA_DISK_1: starting piece 1 at 30-JUL-13
channel ORA_DISK_1: finished piece 1 at 30-JUL-13
piece handle=/u01/backupbk/forstandby_20og0r4q_1_1 tag=STANDBY comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:37using channel ORA_DISK_1
backup will be obsolete on date 06-AUG-13
archived logs will not be kept or backed up
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at 30-JUL-13
channel ORA_DISK_1: finished piece 1 at 30-JUL-13
piece handle=/u01/backupbk/forstandby_21og0r60_1_1 tag=STANDBY comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 30-JUL-13RMAN>
上面的scn就是备库的scn,需要注意下.
4.scp backupset to standby
5.startup mount(standby)
6.恢复增量数据(standby)
[oracle@dg2 dbs]$ rman target /
Recovery Manager: Release 11.2.0.2.0 �C Production on Tue Jul 30 07:11:49 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: DG (DBID=1735397445, not open)
RMAN> catalog start with ‘/u01/backupbk’;
using target database control file instead of recovery catalog
searching for all files that match the pattern /u01/backupbkList of Files Unknown to the Database
=====================================
File Name: /u01/backupbk/forstandby_20og0r4q_1_1
File Name: /u01/backupbk/forstandby_21og0r60_1_1Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files…
cataloging doneList of Cataloged Files
=======================
File Name: /u01/backupbk/forstandby_20og0r4q_1_1
File Name: /u01/backupbk/forstandby_21og0r60_1_1RMAN> recover database;
Starting recover at 30-JUL-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=28 device type=DISK
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00001: /u01/app/oradata/system.dbf
destination for restore of datafile 00002: /u01/app/oradata/sysaux.dbf
destination for restore of datafile 00003: /u01/app/oradata/undotbs1.dbf
channel ORA_DISK_1: reading from backup piece /u01/backupbk/forstandby_20og0r4q_1_1
channel ORA_DISK_1: piece handle=/u01/backupbk/forstandby_20og0r4q_1_1 tag=STANDBY
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:00starting media recovery
archived log for thread 1 with sequence 101 is already on disk as file /u01/app/oracle/arch/1_101_822066437.arc
archived log for thread 1 with sequence 102 is already on disk as file /u01/app/oracle/arch/1_102_822066437.arc
archived log for thread 1 with sequence 103 is already on disk as file /u01/app/oracle/arch/1_103_822066437.arc
archived log for thread 1 with sequence 104 is already on disk as file /u01/app/oracle/arch/1_104_822066437.arc
archived log for thread 1 with sequence 105 is already on disk as file /u01/app/oracle/arch/1_105_822066437.arc
unable to find archived log
archived log thread=1 sequence=99
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 07/30/2013 07:12:16
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 99 and starting SCN of 281455
正常如果数据已经应用上去啦,就不应该在找99这个被删除的log了啊 .不解,不过看到备份集被应用啦我们就先不管啦.
7.创建一个新的standby controlfile(primary),并copy到standby database.
8.startup standby database
9.check dg,数据已经过来.