共计 4959 个字符，预计需要花费 13 分钟才能阅读完成。
某数据库配置了 Physical DataGuard(以下简称 dg), 由于没有检查，所以在主库上把归档日 删除了，而备库又没有完全应用，所以导致备库一直停留在之前的归档日志中。
主库检查，发现 dest_id 为的 25 号日志就丢失了.
PRIMARY> select dest_id,sequence#,applied,status,first_change#,next_change# from v$archived_log
where sequence#>20 order by dest_id,sequence#;
DEST_ID SEQUENCE# APPLIED S FIRST_CHANGE# NEXT_CHANGE#
———- ———- ——— – ————- ————
1 21 NO D 1765541 1765764
1 22 NO D 1765764 1768228
1 23 NO D 1768228 1768269
1 24 NO D 1768269 1768400
1 25 NO X 1768400 1768516
1 26 NO X 1768516 1768531
1 27 NO X 1768531 1768611
2 21 YES A 1765541 1765764
2 22 YES A 1765764 1768228
2 23 YES A 1768228 1768269
2 24 NO A 1768269 1768400
DEST_ID SEQUENCE# APPLIED S FIRST_CHANGE# NEXT_CHANGE#
———- ———- ——— – ————- ————
2 26 NO A 1768516 1768531
2 27 NO A 1768531 1768611
所以备库一直无法使用．这种情况下要么就重做整个备库，或是从备库断点的日志那个时候起恢复数据库.
由于数据库比较大，决定采用第二种方案;
在备库上，我们查看当前的数据文件最大的 SCN
STANDBY> select name,file#,checkpoint_change# from v$datafile order by checkpoint_change#;
NAME FILE# CHECKPOINT_CHANGE#
——————————————————- ———- ——————
/u01/app/Oracle/oradata/dc1stby/undotbs01.dbf 4 1768269
/u01/app/oracle/oradata/dc1stby/sysaux01.dbf 3 1768269
/u01/app/oracle/oradata/dc1stby/system01.dbf 1 1768269
/u01/app/oracle/oradata/dc1stby/users01.dbf 6 1768269
在主库上做一个增量 SCN 备份，起始的位置就是备库数据文件的最小 SCN 号.
[oracle@newplat ~]$ rman target / nocatalog
[oracle@newplat ~]$ $ORACLE_HOME/bin/rman target / nocatalog
RMAN> run
2> {
3> allocate channel c3 device type disk;
4> backup as compressed backupset incremental from scn 1768269 database format ‘/home/oracle/bak/%U’;
5> release channel c3;
6> }
released channel: ORA_DISK_1
allocated channel: c3
channel c3: SID=42 device type=DISK
……………………………………………..
including current control file in backup set
channel c3: starting piece 1 at 03-APR-16
channel c3: finished piece 1 at 03-APR-16
piece handle=/home/oracle/bak/0rr22q7u_1_1 tag=TAG20160403T022709 comment=NONE
channel c3: backup set complete, elapsed time: 00:00:01
Finished backup at 03-APR-16
备份完成后，我们通过 SCP 很快把备份文件传到备库的机器上来
[oracle@newplat bak]$ scp *1_1 192.168.56.22:/home/oracle/bak
这时候我们需要关闭备库, 然把把实例启动到 nomount 关态
STANDBY> shutdown immediate;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
STANDBY> startup nomount;
ORACLE instance started.
Total System Global Area 1224736768 bytes
Fixed Size 2923824 bytes
Variable Size 939524816 bytes
Database Buffers 268435456 bytes
Redo Buffers 13852672 bytes
实例启动到 mount 状态后，我们进入备库的 rman, 这时候需要恢复控制文件, 原备库的控制文件因为
包含了 redo apply 老的应用信息所以不能用了.
[oracle@dg2 bak]$ rman target / nocatalog
RMAN> restore standby controlfile from ‘/home/oracle/bak/0rr22q7u_1_1’;
Starting restore at 03-APR-16
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=23 device type=DISK
……………………………………..
很快控制文件就了恢复完成了，我们打开另一个窗口，通过 sqlplus 把备库以 standby 的方式 mount 起来
STANDBY> alter database mount standby database;
Database altered.
数据库 mount 起来后，我们返回到 rman 提示符，这个时候我们可以对传过来的备份文件并进行编目了. 这样我们在下一步操作中，就可以使用这些文件来行恢复
RMAN> catalog start with ‘/home/oracle/bak’;
searching for all files that match the pattern /home/oracle/bak
List of Files Unknown to the Database
=====================================
File Name: /home/oracle/bak/08r1ekse_1_1
File Name: /home/oracle/bak/0or22q7t_1_1
File Name: /home/oracle/bak/0kr22phj_1_1
File Name: /home/oracle/bak/0nr22pic_1_1
File Name: /home/oracle/bak/09r1eku6_1_1
File Name: /home/oracle/bak/0rr22q7u_1_1
Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files…
cataloging done
文件编目后，我们就可以开始正式恢复数据库了.
RMAN> recover database;
Starting recover at 03-APR-16
using channel ORA_DISK_1
starting media recovery
……………………………….
media recovery complete, elapsed time: 00:03:01
Finished recover at 03-APR-16
备库完成恢复完成后，我们就可以启动 redo apply 了.
STANDBY> alter database recover managed standby database disconnect from session using current logfile;
Database altered.
STANDBY> select process,client_process,sequence#,status from v$managed_standby;
PROCESS CLIENT_P SEQUENCE# STATUS
——— ——– ———- ————
ARCH ARCH 0 CONNECTED
ARCH ARCH 0 CONNECTED
ARCH ARCH 0 CONNECTED
ARCH ARCH 0 CONNECTED
ARCH ARCH 0 CONNECTED
RFS ARCH 0 IDLE
RFS LGWR 33 IDLE
MRP0 N/A 33 WAIT_FOR_LOG
现在我们查看备库状态，MRP 进程已经开始最新的日志应用了. 到此我们通过增量 SCN 备份和恢复来修复备库归档日志丢失的过程已经全部完成了。
Oracle 11gR2 在 VMWare 虚拟机中安装步骤 http://www.linuxidc.com/Linux/2013-09/89579p2.htm
Debian 下 安装 Oracle 11g XE R2 http://www.linuxidc.com/Linux/2014-03/98881.htm
Oracle Data Guard 重要配置参数 http://www.linuxidc.com/Linux/2013-08/88784.htm
基于同一主机配置 Oracle 11g Data Guard http://www.linuxidc.com/Linux/2013-08/88848.htm
探索 Oracle 之 11g DataGuard http://www.linuxidc.com/Linux/2013-08/88692.htm
Oracle Data Guard（RAC+DG) 归档删除策略及脚本 http://www.linuxidc.com/Linux/2013-07/87782.htm
Oracle Data Guard 的角色转换 http://www.linuxidc.com/Linux/2013-06/86190.htm
Oracle Data Guard 的日志 FAL gap 问题 http://www.linuxidc.com/Linux/2013-04/82561.htm
Oracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby 处理方法 http://www.linuxidc.com/Linux/2013-03/82009.htm
更多 Oracle 相关信息见 Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2016-05/130995.htm
