一次 archivelog GAP 问题解决引发的错误

环境：oracle 11.2.0.1  + linux5.5

检查standby database：

select count(*) from V$archived_log where applied='NO'发现500多个日志没被应用，

standby database 的alert 日志中的错误信息：

Tue May 28 11:33:19 2013
Completed: alter database recover managed standby database disconnect from session
Tue May 28 11:33:21 2013
Media Recovery Waiting for thread 1 sequence 4304
Fetching gap sequence in thread 1, gap sequence 4304-4403
Tue May 28 11:33:32 2013
FAL[client]: Failed to request gap sequence
 GAP - thread 1 sequence 4304-4403
 DBID 2881124576 branch 746661408
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.

GAP原理：http://blog.csdn.net/wyzxg/article/details/6749565

从以上alert日志中了解到sequence 为4304-4403没有被standby database 应用且日志已经找不到了，从主备库都GAP不到就报出的错，备库没法应用日志。

造成日志丢失的原因：是本人工作中的失误，把那部分日志在没应用之前就rm -rf了

解决办法：

1、恢复归档日志：思路----因为主库做了rman全备份，在主库恢复需要的归档日志然后备库会自动获取

具体操作：RMAN>list backup of archivelog from sequence 4304 查看到备份都是有效的，运行脚本:

run{
 allocate channel c1 type 'sbt_tape';
 send 'NSR_ENV=(NSR_SERVER=EMC-manager,NSR_CLIENT=racnode1)';
 restore archivelog sequence between 4304 and 4403;
 release channel c1;
  }

结果报错：hannel c1: restoring archived log
archived log thread=1 sequence=4402
channel c1: restoring archived log
archived log thread=1 sequence=4403
channel c1: reading from backup piece ORC2_RA_10_ARC1_20130510_3725_1.bak
channel c1: ORA-19870: error while restoring backup piece ORC2_RA_10_ARC1_20130510_3725_1.bak
ORA-19507: failed to retrieve sequential file, handle="ORC2_RA_10_ARC1_20130510_3725_1.bak", parms=""
ORA-27029: skgfrtrv: sbtrestore returned error
ORA-19511: Error received from media manager layer, error text:
   Could not locate the LNM save file 'ORC2_RA_10_ARC1_20130510_3725_1.bak' on server 'EMC-manager'. (2:9:2)

failover to previous backup

released channel: c1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 05/29/2013 11:34:15
RMAN-06026: some targets not found - aborting restore
RMAN-06025: no backup of archived log for thread 1 with sequence 4403 and starting SCN of 352014815 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 4402 and starting SCN of 351707984 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 4401 and starting SCN of 351411621 found to restore

这个报错的原因是：no backup of archived log for t............... 事实这个环境中：通过ＥＭＣ　network对数据库做了备份，为啥找不到还待研究，这个方法失败尝试第二种

２.利用sys.dbms_backup_restore.restoreSetArchivedLog（）包恢复，最终还是失败了，报错：ERROR at line 1:
ORA-19568: a device is already allocated to this session
ORA-06512: at "SYS.DBMS_BACKUP_RESTORE", line 232
ORA-06512: at "SYS.DBMS_BACKUP_RESTORE", line 207
ORA-06512: at line 5

这种发放放弃，我觉得是备份的问题，本人对EMC network备份不熟悉，

至此为止利用历史备份恢复的想法放弃

3，用主库的增量备份修复备库，具体操作网上链接： http://blog.163.com/yanenshun@126/blog/static/128388169201304105015343/按照链接修复后，在alert 日志里边还是存在原来的GAP错误，

在开启alter database open时报错：SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-10458: standby database requires recovery
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: '+ASM_DATA/rastb/datafile/system.279.74666141

我觉得这个问题是不同步造成的，至此为止我已经很郁闷了，有个想法是重建备库

4，在主库做了个全备和一份standby controlfile  ,scp到备库，直接做恢复，恢复完之后，发现备库可以开启到open，应用也可以开启，但是还是不应用，报了很多错误：

alert日志中的错误信息：RFS[1140]: Assigned to RFS process 25497
RFS[1140]: Identified database type as 'physical standby': Client is LGWR SYNC pid 10214
Primary database is in MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
Standby controlfile consistent with primary
RFS[1140]: No standby redo logfiles selected (reason:7)
Errors in file /u01/app/oracle/diag/rdbms/rastb/rastb1/trace/rastb1_rfs_25497.trc:
ORA-16086: Redo data cannot be written to the standby redo log

对应trace的文件的错误信息：

The primary database is operating in MAXIMUM PROTECTION
or MAXIMUM AVAILABILITY mode, and the standby database does
not contain any viable standby redo logfiles.
ORA-16086: Redo data cannot be written to the standby redo log

错误信息：redo log 日志不可用。但是从V$log,V$logfile中看到日志组是正常的，我自己有 add 机组日志，还是不行，在没辙的情况下：我将主库的 log_archive_dest_2 参数中的lgwr sync 拿掉，结果发现备库开始应用，具体原因还么弄清楚，还待考虑，整体来说我把小事大作了，欢迎好的建议留言

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28380626/viewspace-762539/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/28380626/viewspace-762539/