手工解决DG备库日志GAP

郑全

背景：
     手工通过DUPLICATE 方式从主库复制了数据库到新的一个测试库，在复制完后，直接激活新的数据库，发现SYSTEM不一致，于是通过手工从主库拷贝日志文件过来的办法进行补齐差的日志，
但拷贝了其中一个日志，备库不认识，怎么处理，下面是具体步骤：
1.激活备库
SQL> alter database activate  physical  standby database;
alter database activate  physical  standby database
*
ERROR at line 1:
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/u01/hisdb/data/system.305.951233557'

备库日志：
Standby crash recovery need archive log for thread 1 sequence 70528 to continue.
Please verify that primary database is transporting redo logs to the standby database.
Wait timeout: thread 1 sequence 70528
Standby Crash Recovery aborted due to error 16016.
Errors in file /u01/app/oracle/diag/rdbms/orclcs/orcl/trace/orcl_ora_19327.trc:
ORA-16016: archived log for thread 1 sequence# 70528 unavailable
Recovery interrupted!
Completed Standby Crash Recovery.
Signalling error 1152 for datafile 1!
ORA-1152 signalled during: alter database activate  physical  standby database...
2025-05-30 07:51:51.129000 +08:00

可以看出 70528 日志找不到，看了一下归档目录，一个归档都没有。

2.从主库拷贝

  [grid@hisdb02 ~]$ asmcmd cp "+ARCHIVE/orcl/archivelog/2025_05_30/thread_1_seq_70528.4189.1202431025" /tmp/1_seq_70528
copying +ARCHIVE/orcl/archivelog/2025_05_30/thread_1_seq_70528.4189.1202431025 -> /tmp/1_seq_70528
  [grid@hisdb02 ~]$ asmcmd cp "+ARCHIVE/orcl/archivelog/2025_05_30/thread_1_seq_70529.7725.1202434259" /tmp/1_seq_70529
copying +ARCHIVE/orcl/archivelog/2025_05_30/thread_1_seq_70529.7725.1202434259 -> /tmp/1_seq_70529
  。。。

3.把日志加到catalog中去  
  RMAN> catalog start with '/u01/hisdb/data/archive';

using target database control file instead of recovery catalog
searching for all files that match the pattern /u01/hisdb/data/archive

List of Files Unknown to the Database
=====================================
File Name: /u01/hisdb/data/archive/1_seq_70528
File Name: /u01/hisdb/data/archive/1_seq_70529

Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /u01/hisdb/data/archive/1_seq_70528
File Name: /u01/hisdb/data/archive/1_seq_70529

4.备库应用日志
  SQL> recover managed standby database disconnect from session;
Media recovery complete.
  发现日志：
   Media Recovery Log /u01/hisdb/data/archive/1_seq_70529
Media Recovery Waiting for thread 2 sequence 65217
FAL[client]: Error fetching gap sequence, no FAL server specified
Completed: ALTER DATABASE RECOVER  managed standby database disconnect from session  
2025-05-30 07:58:29.115000 +08:00
。。。
Media Recovery Log /u01/hisdb/data/archive/2_seq_65218
Media Recovery Waiting for thread 1 sequence 70529
2025-05-30 08:02:34.120000 +08:00

2025-05-30 08:08:24.330000 +08:00
Fetching gap sequence in thread 1, gap sequence 70529-70529
FAL[client]: Error fetching gap sequence, no FAL server specified
2025-05-30 08:08:34.332000 +08:00
FAL[client]: Error fetching gap sequence, no FAL server specified

一直等 70529，其实这个日志文件已经了。

5.手工在备库上注册一下这个日志
  SQL> ALTER DATABASE REGISTER LOGFILE '/u01/hisdb/data/archive/1_seq_70529';

Database altered.

后端日志：

------------------------------------------------------------
2025-05-30 08:12:36.824000 +08:00
ALTER DATABASE REGISTER LOGFILE '/u01/hisdb/data/archive/1_seq_70529'
There are 1 logfiles specified.
ALTER DATABASE REGISTER [PHYSICAL] LOGFILE
Resynchronizing thread 1 from sequence 70528 to 70529
Completed: ALTER DATABASE REGISTER LOGFILE '/u01/hisdb/data/archive/1_seq_70529'
2025-05-30 08:12:46.753000 +08:00
Media Recovery Log /u01/hisdb/data/archive/1_seq_70529
Media Recovery Log /u01/hisdb/data/archive/2_seq_65218


看来日志已经认到了。并开始日志应用

6.再次激活数据库
  SQL> alter database activate  physical  standby database;
alter database activate  physical  standby database
*
ERROR at line 1:
ORA-01154: database busy. Open, close, mount, and dismount not allowed now


SQL> recover managed standby database cancel;
Media recovery complete.
SQL> alter database activate  physical  standby database;

Database altered.

SQL> alter database open;

Database altered.


SQL>  select open_mode from v$database;

OPEN_MODE
--------------------
READ WRITE



后端日志，不再报错。

最后：
    看来数据库激活失败后，也能继续接受主库的日志。