Data Guard出现gap sequence修复

一、出现gap sequence现象

备库

Fetching gap sequence in  thread 1, gap sequence 710-716 Tue May 31 15:02:38 2011 FAL[client]: Failed to request gap sequence GAP - thread 1 sequence 710-716 DBID 3240478808 branch 746916894 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. -------------------------------------------------------------

主库

Tue May 31 13:50:47 2011 FAL[server]: Fail to queue the whole FAL gap GAP - thread 1 sequence 710-716 DBID 3240478808 branch 746916894

二、修复操作
1、查询备库的scn

SQL> SELECT  CURRENT_SCN FROM  V$DATABASE; CURRENT_SCN ----------- 1154337 --在出现意外datafile header scn不一致的时候,需要根据提示归档日志,找出最小scn

2、确定主库是否添加数据文件

SQL> select  FILE#,name  from  v$datafile where  CREATION_CHANGE#> =1154337; no  rows  selected

确定主库在这个scn之后是否有添加数据文件，如果添加文件，需要手工在备库添加

3、备库停止日志应用

SQL> ALTER  DATABASE  RECOVER MANAGED STANDBY DATABASE  CANCEL;

4、主库增量备份并传输到备库上
主库进行增量备份

RMAN> BACKUP INCREMENTAL FROM  SCN 1154337 DATABASE FORMAT '/home/oracle/xff_%U'  tag 'XIFENFEI'; [oracle@localhost ~]$ scp xff* 192.168.1.30:/home/oracle/rman

说明：主库之前必须要做过rman的全备（没有全备的库，基于scn的增量备份也能够成功）

5、备库上进行恢复

RMAN> CATALOG START WITH  '/home/oracle/rman'; RMAN> RECOVER DATABASE  NOREDO;

说明：CATALOG START WITH是10g及其以后版本中才存在功能，没有该功能可以采用catalog或者复制主库的控制文件，rman备份放置和主库备份时相同目录实现。

6、主库上创建standby controlfile文件并传输到备库

RMAN> BACKUP CURRENT  CONTROLFILE FOR  STANDBY FORMAT '/home/oracle/xff_ctl.bck'; [oracle@localhost ~]$ scp xff_ctl.bck 192.168.1.30:/home/oracle/rman

创建standby controlfile两步可以需要根据实际情况考虑,大多数情况下不需要

7、备库恢复控制文件

RMAN> shutdown; RMAN> STARTUP NOMOUNT; RMAN> RESTORE STANDBY CONTROLFILE FROM  '/home/oracle/rman/xff_ctl.bck'; RMAN> alter  database  mount;

8、清空备库日志组

SQL> ALTER  DATABASE  CLEAR LOGFILE GROUP  1; 注：如果采用了standby log模式，不需要清空，如果清空会出现 SQL> ALTER  DATABASE  CLEAR LOGFILE GROUP  1; ALTER  DATABASE  CLEAR LOGFILE GROUP  1 * ERROR at  line 1: ORA-19527: physical standby redo log must be renamed ORA-00312: online log 1 thread 1: '/u01/oradata/xienfei/redo01.log'

说明：如果没有采用standby log模式，有几组需要清空几组

9、备库重设flashback

SQL> ALTER  DATABASE  FLASHBACK OFF; SQL> ALTER  DATABASE  FLASHBACK ON;

10、备库重新接收并应用日志

SQL> ALTER  DATABASE  RECOVER MANAGED STANDBY DATABASE  DISCONNECT FROM  SESSION;

三、修复成功标志
1、sql中操作
在主库中执行alter system switch logfile;
分别主备库中执行select max(sequence#) from v$archived_log;如果一致标示修复成功

2、通过alert文件
主库

PING[ARC0]: Error 3113 when pinging standby xff. Tue May 31 14:11:51 2011 Thread 1 advanced to log sequence 719 Current log# 3 seq# 719 mem# 0: /u01/oradata/xienfei/redo03.log Tue May 31 14:20:05 2011 Thread 1 advanced to log sequence 720 Current log# 1 seq# 720 mem# 0: /u01/oradata/xienfei/redo01.log Tue May 31 14:20:16 2011 ARC0: Standby redo logfile selected for  thread 1 sequence 719 for  destination LOG_ARCHIVE_DEST_2

备库

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION Tue May 31 15:30:37 2011 Attempt to start background Managed Standby Recovery process (xff) MRP0 started with pid=18, OS id=14704 Tue May 31 15:30:37 2011 MRP0: Background Managed Standby Recovery process started (xff) Managed Standby Recovery not using Real Time Apply parallel recovery started with 2 processes Media Recovery Log /u01/archive/1_718_746916894.arc Tue May 31 15:30:43 2011 Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION Tue May 31 15:30:52 2011 RFS[1]: Successfully opened standby log 4: '/u01/oradata/xienfei/s_redo1.log' Media Recovery Log /u01/archive/1_719_746916894.arc Media Recovery Waiting for  thread 1 sequence 720

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

转载于:http://blog.itpub.net/23490154/viewspace-1061858/