DataGuard丢失归档，使用增量备份恢复备库一例

发生了这种错误，主库丢失了归档，而备库无法同步日志

Media Recovery Waiting for thread 1 sequence 70

Fetching gap sequence in thread 1, gap sequence 70-72

Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION

Wed Mar 07 18:26:31 2012

FAL[client]: Failed to request gap sequence

 GAP - thread 1 sequence 70-72

 DBID 3857759336 branch 768793323

FAL[client]: All defined FAL servers have been attempted.

-------------------------------------------------------------

Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization

parameter is defined to a value that is sufficiently large

enough to maintain adequate log switch information to resolve

archivelog gaps.

-------------------------------------------------------------

 

 

 

1.备库上面查看丢失的归档

idle> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

 

   THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#

---------- ------------- --------------

         1            70             72

 

 

2.主库查看归档是否存在

先查看文件在系统中的位置

sys@DEX> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND SEQUENCE# BETWEEN 70 AND 72;

 

NAME

------------------------------

/u01/arch1/1_70_768793323.arc

/u01/arch1/1_71_768793323.arc

/u01/arch1/1_72_768793323.arc

使用系统命令查看，如果看到没有找到文件，那么进入下面的阶段。

file /u01/arch1/1_70_768793323.arc

/u01/arch1/1_70_768793323.arc: cannot open `/u01/arch1/1_70_768793323.arc' (No such file or directory)

 

3.备库查看丢失的归档时的scn号

idle> select current_scn from v$database;

 

CURRENT_SCN

-----------

    1102063

 

 

4.主库创建基于丢失归档scn号为起始的增量备份（要确定主库和备库的目标目录有足够的空间，这里使用/tmp文件夹）

RMAN> run{

BACKUP DEVICE TYPE DISK INCREMENTAL FROM SCN 1102063 DATABASE

FORMAT '/tmp/stb_bk/%U_for_stb.bk'

include current controlfile for standby ;

}

 

 

5.备份好之后，从主库传到备份库的目录中，可以与上文的目录不同，然后进入备库的rman执行下面的命令。

 

RMAN> CATALOG START WITH '/tmp/stb_bk/';

 

 

6.备库中查看一下controlfile的位置，因为接下来要使用备份的控制文件。

idle> show parameter control

再查看一下standby_log文件的位置，因为接下来可能需要重建。

idle> select * from v$logfile ;

 

 

7.备库使用如下命令在rman中恢复

RMAN> run{

restore standby controlfile to '/tmp/stb_controlfile01.ctl' ;

recover database noredo;

}

如果报如下错误，可能是recover managed standby 命令正在执行：

ORA-19870: error while restoring backup piece /tmp/stb_bk/05n5a31s_1_1_for_stb.bk

ORA-19573: cannot obtain exclusive enqueue for datafile 1

执行如下命令或者重启数据库到mount状态：

idle>alter database recover managed standby database cancel ;

然后在rman中再次执行：

RMAN>

run{

restore standby controlfile to '/tmp/stb_controlfile01.ctl' ;

recover database noredo;

}

 

 

8.关闭数据库，将恢复出来的备份控制文件覆盖掉原有的控制文件。

shutdown immediate

[oracle@rhel6_3 stb_bk]$ cp /tmp/stb_controlfile01.ctl /u01/hell/controlfile/hell01.ctl

[oracle@rhel6_3 stb_bk]$ cp /tmp/stb_controlfile01.ctl /u01/hell/controlfile/hell02.ctl

 

 

9.启动到mount

idle>startup mount ;

这里有一点要注意，因为使用的是standby controlfile ，所以所有log文件（包括standby_log）的位置，是由主库的参数LOG_FILE_NAME_CONVERT来决定的。例如主库的参数

LOG_FILE_NAME_CONVERT=/u01/hell/datas/, /u01/apps/oracle/oradata/dex/

那么位于/u01/apps/oracle/oradata/dex/standby1.log这个文件在使用standby_controlfile恢复中会被转换为/u01/hell/datas/standby1.log，如果主库的standby_log文件没有在/u01/apps/oracle/oradata/dex/这个路径下，就会按照原路径在备库中恢复。所以如果想要定制standby_log的位置，需要重新建立standby_log文件。

 

接下来

idle>alter database recover managed standby database disconnect ;

 

 

10.千万不要以为结束了，既然丢失了归档，数据库还是进行一次全备吧。

转载于:https://www.cnblogs.com/spotlight/archive/2012/03/07/2384284.html