自学内容网 自学内容网

Oracle 12C DataGuard GAP 修复过程(RECOVER … FROM SERVICE)

1. 介绍

DG GAP 顾名思义就是:DG不同步,当备库不能接受到一个或多个主库的归档日志文件时候,就发生了 GAP。

那么,如果遇到GAP如何修复呢?

DG GAP 主要分为以下两类情况:

  • 主库归档日志存在,可以通过配置 Fetch Archive Log(FAL) 参数,自动解决归档 GAP;
  • 主库归档日志丢失,需要 人工干预 来修复;

不同 Oracle 版本的 GAP 修复方式也不尽相同,下面分别介绍不同版本的方式!

11G 的处理步骤:

  • 在主库上创建一个备库的控制文件
  • 以备库的当前SCN号为起点,在主库上做一个增量备份
  • 将增量备份拷贝到备库上
  • 使用新的控制文件将备库启动到mount状态
  • 将增量备份注册到RMAN的catalog,取消备库的恢复应用,恢复增量备份
  • 开启备库的恢复进程

12C 的新特性(RECOVER … FROM SERVICE)

  • 备库启动到nomount状态
  • 从主库恢复控制文件到备库(/RMAN> restore standby controlfile from service hfdb)
  • 备库启动到mount状态
  • 恢复GAP(RMAN> recover database from service hfdb noredo using compressed backupset;)
  • 启动备库
  • 开启备库的恢复进程

19C 的新特性(RECOVER STANDBY DATABASE FROM SERVICE)

Oracle随着版本的升级,逐渐将步骤缩减,进行封装,19C 之后可谓是达到了所谓的一键刷新,恢复DG同步。

2. 12C 新特性(RECOVER … FROM SERVICE)修复

2.1. 环境准备

以下为测试环境信息:

角色

主机名

IP地址

数据库版本

实例名

DB名

DB_UNIQUE名

services名

TNS名

sys密码

主(RAC)

hfdb30

hfdb31

192.168.40.30

192.18.40.31

19C

hfdb1

hfdb2

hfdb

hfdb

hfdb

hfdb

oracle

备(FS)

dghfdb

192.168.40.40

19C

dghfdb

dghfdb

dghfdb

dghfdb

dghfdb

oracle

2.2. 模拟 GAP 发生

首先,模拟备库断电,主库切几个最新的归档,然后手工删掉,重新开启DG同步。

备库停止 DG 同步进程:

#停止监听
[oracle@hfdb40:/home/oracle]$lsnrctl stop

LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 03-DEC-2024 20:47:05

Copyright (c) 1991, 2019, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=hfdb40)(PORT=1521)))
The command completed successfully

#关闭同步进程,关库
[oracle@hfdb40:/home/oracle]$sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Tue Dec 3 20:50:07 2024
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0

#停止备份同步进程
SYS@dghfdb> alter database recover managed standby database cancel;

Database altered.

SYS@dghfdb> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@dghfdb>

主库切换多次归档:

SYS@hfdb1> alter system switch logfile;

System altered.

SYS@hfdb1> /

System altered.

SYS@hfdb1> alter system archive log current;

System altered.

SYS@hfdb1> /

System altered.

SYS@hfdb1> exit


SYS@hfdb1> archive log list
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     43
Next log sequence to archive   44
Current log sequence           44

SYS@hfdb2> archive log list
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     20
Next log sequence to archive   21
Current log sequence           21

主库删除最近几个归档日志:

[grid@hfdb30:/home/grid]$asmcmd
ASMCMD> cd /dgrecovery1/HFDB/archivelog/2024_12_03
ASMCMD> ls
thread_1_seq_40.264.1186780599
thread_1_seq_41.266.1186780613
thread_1_seq_42.267.1186780619
thread_1_seq_43.269.1186780891
thread_2_seq_17.263.1186780599
thread_2_seq_18.265.1186780613
thread_2_seq_19.268.1186780877
thread_2_seq_20.270.1186780891

ASMCMD> rm -rf thread_2_seq_20.270.1186780891
ASMCMD> rm -rf thread_1_seq_43.269.1186780891
ASMCMD> rm -rf thread_1_seq_42.267.1186780619
ASMCMD> ls
thread_1_seq_40.264.1186780599
thread_1_seq_41.266.1186780613
thread_2_seq_17.263.1186780599
thread_2_seq_18.265.1186780613
thread_2_seq_19.268.1186780877

备库开启同步进程:

[oracle@hfdb40:/home/oracle]$lsnrctl start

LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 03-DEC-2024 21:29:03

Copyright (c) 1991, 2019, Oracle.  All rights reserved.

Starting /oracle/app/oracle/product/19c/db_1/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 19.0.0.0.0 - Production
System parameter file is /oracle/app/oracle/product/19c/db_1/network/admin/listener.ora
Log messages written to /oracle/app/oracle/diag/tnslsnr/hfdb40/listener/alert/log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hfdb40)(PORT=1521)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=hfdb40)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 19.0.0.0.0 - Production
Start Date                03-DEC-2024 21:29:03
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /oracle/app/oracle/product/19c/db_1/network/admin/listener.ora
Listener Log File         /oracle/app/oracle/diag/tnslsnr/hfdb40/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hfdb40)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
Services Summary...
Service "dghfdb" has 1 instance(s).
  Instance "dghfdb", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully
[oracle@hfdb40:/home/oracle]$sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Tue Dec 3 21:29:15 2024
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SYS@dghfdb> startup
ORACLE instance started.

Total System Global Area 3355440576 bytes
Fixed Size                  8902080 bytes
Variable Size             671088640 bytes
Database Buffers         2667577344 bytes
Redo Buffers                7872512 bytes
Database mounted.
Database opened.
SYS@dghfdb> alter database recover managed standby database using current logfile disconnect from session;

Database altered.

SYS@dghfdb> alter system register;

System altered.

主库刷新 DEST 状态:

SYS@hfdb1> alter system set log_archive_dest_state_2=defer;

System altered.

SYS@hfdb1> alter system set log_archive_dest_state_2=enable;

System altered.

SYS@hfdb1> alter system switch logfile;

System altered.

SYS@hfdb1> alter system archive log current;

System altered.

SYS@hfdb1>

查看同步情况,是否存在 GAP:

set line1000
col status for a10
col type for a10
col error for a20
col gap_status for a20
col synchronization_status for a30
col recovery_mode for a30
select inst_id,status,DEST_ID,TYPE,ERROR,GAP_STATUS,SYNCHRONIZED,SYNCHRONIZATION_STATUS,RECOVERY_MODE from GV$ARCHIVE_DEST_STATUS where STatus <> 'INACTIVE' and type = 'PHYSICAL';
-- 显示 UNRESOLVABLE GAP,意味着无法自行修复,需要人工干预
   INST_ID STATUS        DEST_ID TYPE       ERROR                GAP_STATUS           SYNCHRONI SYNCHRONIZATION_STATUS         RECOVERY_MODE
---------- ---------- ---------- ---------- -------------------- -------------------- --------- ------------------------------ ------------------------------
         1 VALID               2 PHYSICAL                        UNRESOLVABLE GAP     NO        CHECK CONFIGURATION            MANAGED REAL TIME APPLY WITH Q                                                                                                                  UERY

         2 VALID               2 PHYSICAL                        UNRESOLVABLE GAP     NO        CHECK CONFIGURATION            MANAGED REAL TIME APPLY WITH Q

                                                                                                                             UERY
SYS@hfdb1> alter system checkpoint;
SYS@hfdb1> col CURRENT_SCN for 999999999999999999
SYS@hfdb1> select current_scn from v$database;

        CURRENT_SCN
-------------------
            1697718
            
SYS@hfdb2> alter system checkpoint;         
SYS@hfdb2> col CURRENT_SCN for 999999999999999999
SYS@hfdb2> select current_scn from v$database;

        CURRENT_SCN
-------------------
            1697822

--
SYS@dghfdb> col group# for a20
SYS@dghfdb> select process,thread#,group#,sequence#,status from gv$managed_standby;

PROCESS                        THREAD# GROUP#                SEQUENCE# STATUS
--------------------------- ---------- -------------------- ---------- ------------------------------------
ARCH                                 1 11                           44 CLOSING
DGRD                                 0 N/A                           0 ALLOCATED
DGRD                                 0 N/A                           0 ALLOCATED
ARCH                                 2 13                           21 CLOSING
ARCH                                 1 10                           45 CLOSING
ARCH                                 1 10                           36 CLOSING
RFS                                  1 N/A                           0 IDLE
RFS                                  2 N/A                           0 IDLE
RFS                                  1 2                            46 IDLE
RFS                                  2 4                            22 IDLE
RFS                                  0 N/A                           0 IDLE

PROCESS                        THREAD# GROUP#                SEQUENCE# STATUS
--------------------------- ---------- -------------------- ---------- ------------------------------------
RFS                                  0 N/A                           0 IDLE
RFS                                  0 N/A                           0 IDLE
RFS                                  0 N/A                           0 IDLE
RFS                                  0 N/A                           0 IDLE
RFS                                  0 N/A                           0 IDLE
MRP0                                 1 N/A                          42 WAIT_FOR_GAP

17 rows selected.

SYS@dghfdb> select count(*) from gv$archived_log where applied='NO';

  COUNT(*)
----------
         7
SYS@dghfdb> select * from v$archive_gap;

   THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#     CON_ID
---------- ------------- -------------- ----------
         1            42             43          1
         2            20             20          1

SYS@dghfdb> select current_scn from v$database;

CURRENT_SCN
-----------
    1693651

SYS@dghfdb> select FILE#,name from v$datafile where CREATION_CHANGE#>1697718;

no rows selected


当前 ADG 已存在 GAP,并且 GAP 期间主库没有增加数据文件,缺少日志号为 42,43,20 即是前面模拟断电删除的归档日志文件,已经确认无法找回,需要人工干预进行修复。

2.3. 12C 新特性修复

备库采用 rman 的新功能,recover standby using service,通过 RMAN 连接到 target 备库,然后用主库的 service 执行恢复备库命令:

语法:

RECOVER DATABASE FROM SERVICE < PRIMARY DB SERVICE NAME > NOREDO USING COMPRESSED BACKUPSET;

备库启动到 nomount 状态:

SYS@dghfdb> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@dghfdb> startup nomount
ORACLE instance started.

Total System Global Area 3355440576 bytes
Fixed Size                  8902080 bytes
Variable Size             671088640 bytes
Database Buffers         2667577344 bytes
Redo Buffers                7872512 bytes
SYS@dghfdb>

备库通过 from service 恢复控制文件:

[oracle@hfdb40:/home/oracle]$tnsping hfdb

TNS Ping Utility for Linux: Version 19.0.0.0.0 - Production on 03-DEC-2024 21:48:32

Copyright (c) 1997, 2019, Oracle.  All rights reserved.

Used parameter files:


Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.40.32)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = hfdb)))
OK (40 msec)
[oracle@hfdb40:/home/oracle]$rman target /

Recovery Manager: Release 19.0.0.0.0 - Production on Tue Dec 3 21:49:08 2024
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

connected to target database: HFDB (not mounted)

RMAN> restore standby controlfile from service hfdb;

Starting restore at 2024-12-03 21:49:33
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=12 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service hfdb
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:05
output file name=/oradata/dghfdb/control01.ctl
output file name=/oradata/dghfdb/control02.ctl
Finished restore at 2024-12-03 21:49:41

备库开启到 mount 状态:

RMAN> alter database mount;

released channel: ORA_DISK_1
Statement processed

RMAN>

备库 restore 新添加的数据文件:

RMAN> run
{
set newname for database to '/oradata/ORADBDG/datafile/%f_%u';
restore datafile 2 from service oradb_pri;
}

executing command: SET NEWNAME

Starting restore at 20-MAR-23
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=22 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service oradb_pri
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00002 to /oradata/ORADBDG/datafile/2_rh1nhdr2
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
Finished restore at 20-MAR-23

恢复主备 GAP:


RMAN> restore standby controlfile from service hfdb;

Starting restore at 2024-12-04 13:41:47
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=12 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service hfdb
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:05
output file name=/oradata/dghfdb/control01.ctl
output file name=/oradata/dghfdb/control02.ctl
Finished restore at 2024-12-04 13:41:55

RMAN> alter database mount;

released channel: ORA_DISK_1
Statement processed

RMAN> recover database from service hfdb noredo using compressed backupset;

Starting recover at 2024-12-04 13:42:25
Starting implicit crosscheck backup at 2024-12-04 13:42:25
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1522 device type=DISK
Crosschecked 4 objects
Finished implicit crosscheck backup at 2024-12-04 13:42:26

Starting implicit crosscheck copy at 2024-12-04 13:42:26
using channel ORA_DISK_1
Finished implicit crosscheck copy at 2024-12-04 13:42:26

searching for all files in the recovery area
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_1_23_mmp2085b_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_2_12_mmp225ps_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_1_24_mmp260l0_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_1_25_mmp2870t_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_2_13_mmp287fl_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_2_14_mmp2bol2_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_1_26_mmp2boys_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_1_27_mmp2j5wg_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_1_28_mmp3bj5s_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_2_15_mmp3bkow_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_2_16_mmp3dbcx_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_1_29_mmp3h4lv_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_2_17_mmp3hd01_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_1_30_mmp49jyf_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_2_18_mmp5pncz_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_2_19_mmp5po6j_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_2_20_mmp5py9b_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_1_31_mmp5qh3w_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_2_21_mmp5qhxb_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_1_32_mmp6cksb_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_2_22_mmp6cn1o_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_1_33_mmp6pc6l_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_1_34_mmp6phb3_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_1_35_mmp72b8k_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_1_36_mmp72f40_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_1_37_mmpcyw98_.arc
File Name: /archive/DGHFDB/archivelog/2024_11_18/o1_mf_1_38_mmpfwjb8_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_2_34_mnzlrdcr_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_1_57_mnzlrfb3_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_2_35_mnzlvd06_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_1_58_mnzlvdyc_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_1_59_mnzlwz7l_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_1_60_mnzmg136_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_2_36_mnzmg1q2_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_1_61_mnzrms9j_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_2_37_mnzrn94b_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_1_62_mnzrnb91_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_1_63_mnzrndns_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_2_38_mnzrnl52_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_2_39_mnzrno7p_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_1_64_mnzrnoln_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_1_65_mnzryf3w_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_1_66_mnzrym3q_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_2_40_mnzrymgs_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_1_67_mnzs7l8s_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_1_70_mnztkodc_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_1_71_mnztkofj_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_2_44_mnztkog8_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_2_43_mnztkokg_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_2_41_mnztkoq2_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_2_45_mnztkotq_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_1_68_mnztkowd_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_1_72_mnztkp31_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_1_73_mnztmr8y_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_1_74_mnztn4j5_.arc
File Name: /archive/DGHFDB/archivelog/2024_12_04/o1_mf_2_46_mnztn5o4_.arc
File Name: /archive/DGHFDB/autobackup/2024_11_19/o1_mf_s_1185450609_mmr2qm0g_.bkp
File Name: /archive/DGHFDB/autobackup/2024_11_19/o1_mf_s_1185453704_mmr6clwq_.bkp

using channel ORA_DISK_1
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using compressed network backup set from service hfdb
destination for restore of datafile 00001: /oradata/dghfdb/datafile/system.261.1185439411
channel ORA_DISK_1: restore complete, elapsed time: 00:00:08
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using compressed network backup set from service hfdb
destination for restore of datafile 00002: /oradata/dghfdb/datafile/sysaux.266.1185439449
channel ORA_DISK_1: restore complete, elapsed time: 00:00:08
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using compressed network backup set from service hfdb
destination for restore of datafile 00003: /oradata/dghfdb/datafile/undotbs1.260.1185439475
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using compressed network backup set from service hfdb
destination for restore of datafile 00004: /oradata/dghfdb/datafile/undotbs2.258.1185439511
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using compressed network backup set from service hfdb
destination for restore of datafile 00005: /oradata/dghfdb/datafile/users.276.1185439523
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using compressed network backup set from service hfdb
destination for restore of datafile 00006: /oradata/dghfdb/datafile/hfdb1.257.1185443509
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using compressed network backup set from service hfdb
destination for restore of datafile 00007: /oradata/dghfdb/datafile/ogg_tbs.286.1185478503
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02

Finished recover at 2024-12-04 13:42:52

RMAN> alter database open;

Statement processed

RMAN>

备库开启日志同步进程:

SYS@dghfdb> alter database recover managed standby database using current logfile disconnect from session;

主库重新激活同步:

SYS@hfdb1>  alter system set log_archive_dest_state_2=defer;

System altered.

SYS@hfdb1> alter system set log_archive_dest_state_2=enable;

System altered.

SYS@hfdb1> alter system switch logfile;

System altered.

SYS@hfdb1> alter system archive log current;

查询是否存在 GAP,确认主备是否同步:

set line1000
col status for a10
col type for a10
col error for a20
col gap_status for a20
col synchronization_status for a30
col recovery_mode for a60
select inst_id,status,DEST_ID,TYPE,ERROR,GAP_STATUS,SYNCHRONIZED,SYNCHRONIZATION_STATUS,RECOVERY_MODE from GV$ARCHIVE_DEST_STATUS where STatus <> 'INACTIVE' and type = 'PHYSICAL';


   INST_ID STATUS        DEST_ID TYPE       ERROR                GAP_STATUS           SYNCHRONI SYNCHRONIZATION_STATUS         RECOVERY_MODE
---------- ---------- ---------- ---------- -------------------- -------------------- --------- ------------------------------ ------------------------------------------------------------
         1 VALID               2 PHYSICAL                        NO GAP               NO        CHECK CONFIGURATION            MANAGED REAL TIME APPLY WITH QUERY
         2 VALID               2 PHYSICAL                        NO GAP               NO        CHECK CONFIGURATION            MANAGED REAL TIME APPLY WITH QUERY

SYS@dghfdb> select process,thread#,group#,sequence#,status from gv$managed_standby;

PROCESS                        THREAD# GROUP#                          SEQUENCE#
--------------------------- ---------- ------------------------------ ----------
STATUS
------------------------------------
DGRD                                 0 N/A                                     0
ALLOCATED

ARCH                                 0 N/A                                     0
CONNECTED

DGRD                                 0 N/A                                     0
ALLOCATED


PROCESS                        THREAD# GROUP#                          SEQUENCE#
--------------------------- ---------- ------------------------------ ----------
STATUS
------------------------------------
ARCH                                 0 N/A                                     0
CONNECTED

ARCH                                 0 N/A                                     0
CONNECTED

ARCH                                 0 N/A                                     0
CONNECTED


PROCESS                        THREAD# GROUP#                          SEQUENCE#
--------------------------- ---------- ------------------------------ ----------
STATUS
------------------------------------
RFS                                  2 N/A                                     0
IDLE

RFS                                  1 N/A                                     0
IDLE

RFS                                  1 1                                      75
IDLE


PROCESS                        THREAD# GROUP#                          SEQUENCE#
--------------------------- ---------- ------------------------------ ----------
STATUS
------------------------------------
RFS                                  2 3                                      47
IDLE

MRP0                                 2 N/A                                    47
APPLYING_LOG


11 rows selected.
SYS@dghfdb>  select count(*) from gv$archived_log where applied='NO';

  COUNT(*)
----------
         0

SYS@dghfdb> select * from v$archive_gap;

no rows selected

SYS@dghfdb>

至此,GAP 已修复完成,可以发现,12C 这个新特性,将一些步骤进行了省略和封装,进一步减少了我们的操作步骤,但是内部的原理仍然是一致的。

恢复控制文件,再recover database。


原文地址:https://blog.csdn.net/hf191850699/article/details/144239984

免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!