Oracle DataGuard归档日志丢失处理方法

                               Oracle DataGuard归档日志丢失处理方法


　　　某数据库配置了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备份和恢复来修复
备库归档日志丢失的过程已经全部完成了.