首页 > 其他 > 详细

DataGuard Gap sequence的处理方法

时间:2015-09-11 17:37:37      阅读:251      评论:0      收藏:0      [点我收藏+]

检查数据库服务器,发现磁盘已满,因为前期规划问题,磁盘空间不足,还好该库不影响。

删除归档时,发现删除过多,导致备库归档没有成功应用,就被删除了。

这个操作确实粗心大意,检查备库归档时,发现无法应用,查看日志有如下报错:

Fetching gap sequence in thread 1, gap sequence 42102-42102
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‘s sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
------------------------------------------------------------

处理方法,在主库查看该归档的SCN发生的序列:

SQL> col first_change# for 999999999999999
SQL> select first_change# from v$archived_log where sequence#=‘42102‘
  2  ;
   FIRST_CHANGE#
----------------
  11769444390910
主库
SQL> alter system set log_archive_dest_state_2=defer;
备库
SQL> alter database managed standby database recovery cancel;

对主库进行增量和控制文件备份:

RMAN> backup incremental from scn 11769444390910 database format ‘/u01/temp/archivedlog_%U‘;
RMAN> backup current controlfile for standby format ‘/u01/temp/controlfile.bak‘;

将文件拷贝到备库后,进行还原

SQL> shutdown immediate
SQL> startup nomount
RMAN> recover database noredo;
RMAN> restore standby controlfile from ‘/u01/temp/controlfile.bak‘;

查看主备库日志序列是否一致!

主库:
SQL> select max(sequence#) from v$log_history;
MAX(SEQUENCE#)
--------------
         42141
备库:
SQL> select max(sequence#) from v$log_history;
MAX(SEQUENCE#)
--------------
         42141

恢复归档应用

主库
SQL> alter system set log_archive_dest_state_2=enable;
备库
SQL> alter database managed standby database recovery disconnect from session;

本文出自 “LinuxOracle” 博客,请务必保留此出处http://onlinekof2001.blog.51cto.com/3106724/1693815

DataGuard Gap sequence的处理方法

原文:http://onlinekof2001.blog.51cto.com/3106724/1693815

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!