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)!