作者 | JiekeXu
来源 |公众号 JiekeXu DBA之路（ID: JiekeXu_IT）
如需转载请联系授权 | (个人微信 ID：JiekeXu_DBA)
大家好，我是 JiekeXu,江湖人称“强哥”，荣获 Oracle ACE Pro 称号，墨天轮 MVP，墨天轮年度“墨力之星”，拥有 Oracle 11g OCP/OCM 认证,MySQL 5.7/8.0 OCP 认证以及 PCA、PCTA、OBCA、OGCA、KCP 等众多国产数据库认证证书,今天和大家一起来看看利用 Oracle 19c 新特性 from service 修复备库 GAP ！欢迎点击最上方蓝字“JiekeXu DBA之路”关注我的微信公众号，然后点击右上方三个点“设为星标”顶，更多干货文章才能第一时间推送，谢谢！
前 言
相信我们 DBA 在 Oracle DataGuard 环境中遇到过因主库归档空间有限，归档日志又没有备份，空间满的时候直接删除了归档，导致丢失归档日志，而备库还没有及时接收到这个归档，导致备库出现了 GAP 现象。因为日志的中断，备库无法再继续应用之后的日志，出现了主备数据不一致，如果主库归档策略设置不合理的话，甚至还会影响主库的可用性。这个时候，我们只能通过增量备份的方式来恢复备库，首先查询备库当前的 SCN，然后在主库基于此 SCN 号备份，然后将此备份传输到备库，备库使用此备份恢复。从 12cR1 开始，RMAN 提供了一个 Restore database from service 的子句可以通过网络来执行 recover 和 restore 命令。
一、from service 介绍
RMAN 可让您通过网络连接到包含所需文件的物理备库，从而还原或恢复文件。您可以还原整个数据库、数据文件、控制文件、spfile 参数文件或表空间。在需要同步主库和备库的情况下，通过网络恢复文件非常有用。
数据库级别：restore database from service <服务别名>
表空间级别：restore tablespace from service <服务别名>
控制文件：restore controlfile to '指定的位置' from service <服务别名>
SPFILE: restore spfile from service <服务别名>当备库出现 GAP 不同步了，我们可能在 11g 的版本中会使用传统的基于 SCN 的增量备份恢复方案，但如果是 12c 以上的版本，那么我们就可以使用 12c 的新特性基于网络的方式来恢复，下面四小节是基于 19c 的官方文档整理而成的。
12c 新特性 RECOVER … FROM SERVICE 修复备库 GAP
18c 新特性 RECOVER STANDBY DATABASE FROM SERVICE 修复备库 GAP
1.1 关于通过网络 RESTORE 恢复文件
RMAN 通过使用 RESTORE 命令的 FROM SERVICE 子句，通过网络从物理备库还原数据库文件。
FROM SERVICE 子句提供了必须从中还原文件的物理备库的服务名称。在还原操作过程中，RMAN 会在物理备库上创建需要还原的文件的备份集，然后通过网络将这些备份集传输到目标数据库。
使用 RESTORE 命令的 SECTION SIZE 子句可执行多部分还原操作。要加密在物理备用数据库上创建的备份集，请在 RESTORE 命令前使用 SET ENCRYPTION 命令指定所使用的加密算法。
要以压缩备份集的形式从物理备库传输文件，请在 RESTORE 命令中使用 USING COMPRESSED BACKUPSET 子句。默认情况下，RMAN 使用 RMAN 配置中设置的算法压缩备份集。您可以在 RESTORE 语句前使用 SET COMPRESSION ALGORITHM 命令覆盖默认值并设置不同的算法。
1.2 关于通过网络 RECOVER 恢复文件
您可以通过网络从主库获取增量备份，然后将该增量备份应用到物理备库，从而执行恢复。
RMAN 作为 TARGET 连接到物理备库。只恢复数据文件中使用过的数据块，从而优化恢复过程。使用 FROM SERVICE 子句指定必须从中获取增量备份的主库的服务名称（PS：如果这里是级联备库的话，也可以从备库拉取增量数据）。
要在恢复过程中使用多分区备份集，请在 RECOVER 命令中指定 SECTION SIZE 子句。要以加密备份集的形式从主库传输所需文件，请在 RESTORE 命令前使用 SET ENCRYPTION 命令指定用于创建备份集的加密算法。
要压缩用于通过网络恢复文件的备份集，请使用 USING COMPRESSED BACKUPSET 命令。RMAN 在主库上创建备份集，然后将这些备份集传输到目标数据库时，会对备份集进行压缩。
1.3 通过网络恢复数据文件
通过网络连接到主库或物理备库，使用 RESTORE 命令恢复丢失或损坏的数据文件。
在本例中，主库的 DB_UNIQUE_NAME 为 MAIN，物理备库的 DB_UNIQUE_NAME 为 STANDBY。主库中的数据文件 sales.dbf 丢失。您想从物理备库中恢复该数据文件。物理备库的服务名称是 standby_tns。使用带有 FROM SERVICE 子句的 RESTORE 命令，可以使用物理备库中的数据文件恢复主库中丢失的数据文件。主库和物理备库中的密码文件是相同的。
使用以下步骤，通过使用物理库中的数据文件来还原主库中的数据文件 sales.dbf：
以具有 SYSBACKUP 权限的用户身份连接主库,使用 AES128 加密算法加密,确保备库中的 tnsnames.ora 文件包含与主库相对应的条目，还要确保主库和物理备库的密码文件相同。
rman
RMAN> CONNECT TARGET "sbu@main AS SYSBACKUP";
Enter the password for the sbu user when prompted.
--指定备份集必须使用 AES128 加密算法加密
RMAN> SET ENCRYPTION ALGORITHM 'AES128';
--使用物理备库上的数据文件还原主库上的数据文件。以下命令将创建多分区备份集来执行还原操作。
RESTORE DATAFILE '/oradata/datafiles/sales.dbf'
FROM SERVICE standby_tns
SECTION SIZE 120M;1.4 使用 RECOVER 命令向前滚动物理备库
RMAN 通过以下方式向前滚动物理备库：创建包含主数据库更改的增量备份，通过网络将增量备份传输到物理备库，然后将增量备份应用到物库。主库数据文件的所有更改（从备用数据文件头中的 SCN 开始）都包含在增量备份中。
您可以使用 RECOVER … FROM SERVICE 命令将物理备库上的数据文件与主库上的数据文件同步。该命令将刷新备用数据文件，并将它们向前滚动到与主数据库相同的时间点。但是，备用控制文件仍包含旧的 SCN 值，这些值低于备库数据文件中的 SCN 值。因此，要完成物理备库的同步，必须刷新备库控制文件，然后更新刷新后的备库控制文件中的数据文件名、联机重做日志文件名和重做日志文件名。
如果网络资源有限，则可以使用 BACKUP INCREMENTAL 命令在主库上创建增量备份，然后使用增量备份向前滚动物理备库。
使用带有 FROM SERVICE 子句的 RECOVER STANDBY DATABASE 命令，可以用对主库所做的更改刷新物理备库。
本示例假定主数据库的 DB_UNIQUE_NAME 为 MAIN，其网络服务名称为 primary_db。备用数据库的 DB_UNIQUE_NAME 是 STANDBY，其服务名称是 standby_db。
要根据对主库所做的更改刷新物理备库，确保满足以下前提条件：
在物理备库和主库之间建立 Oracle Net 连接。
为此，可以在物理备库的 tnsnames.ora 文件中添加与主库相对应的条目。
主库和物理备库的密码文件是相同的。
将主库和物理备库初始化参数文件中的 COMPATIBLE 参数设置为 12.0。
启动 RMAN 并以目标身份连接到物理备库，建议同时连接到 catalog 恢复目录。
以下命令以 TARGET 身份连接到物理备库，以 CATALOG 身份连接到恢复目录。使用已被授予 SYSBACKUP 权限的 sbu 用户建立与物理备库的连接。物理备库的网络服务名称是 standby_db，恢复目录的网络服务名称是 catdb。
CONNECT TARGET "sbu@standby_db AS SYSBACKUP";
CONNECT CATALOG rman@catdb;使用带有 FROM SERVICE 子句的 RECOVER STANDBY DATABASE 命令向前滚动物理备库。
FROM SERVICE 子句指定了主库的服务名称，必须使用该名称来向前滚动物理备库。前滚操作完成后，将重新启动备库。
下面的示例使用服务名称为 primary_db 的主库向前滚动物理备库。
RECOVER STANDBY DATABASE FROM SERVICE primary_db;
--(仅限 Active Data Guard）执行以下步骤恢复重做数据并以只读模式打开物理备库：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE UNTIL CONSISTENT;
ALTER DATABASE OPEN READ ONLY;在物理备库上启动托管恢复进程。
以下命令将启动托管恢复进程：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;示例 2 通过压缩恢复备库
--四种压缩模式
SET COMPRESSION ALGORITHM 'BASIC';
SET COMPRESSION ALGORITHM 'LOW';
SET COMPRESSION ALGORITHM 'MEDIUM';
SET COMPRESSION ALGORITHM 'HIGH';
CONNECT TARGET "sys/<password>@standby as sysdba"
SET COMPRESSION ALGORITHM 'BASIC';
RECOVER DATABASE FROM SERVICE primary
USING COMPRESSED BACKUPSET;二、19c RAC GAP 真实案例处理
2.1 环境说明
源库为两节点 Linux x86 Oracle 19c RAC 补丁为 RU19.15，这里脱敏暂定为 A 库,物理备库为 19c RU15 单机文件系统,这里暂定为 B 库；另新建一级联备库为 19c RU23 也是单机文件系统，这里暂定为 C 库.数据量大概为 6T 左右，主机配置都挺高144c 512G。
2.2 GAP 现象
这里的 C 库是级联灾备库由于新建没几天还没有纳管到监控，所以出现了延迟也没有告警，更没有人巡检到。当过了十几天想起来的时候登录排查发现已经延迟 15 天 7 个小时多了，归档删除任务是每小时都删除 15 天之前的数据，故中间段的归档日志已经被删除了，且是新建的级联备库没有备份归档，那么只能通过增量恢复来修复了。
## 查看备库状态，有 15 天 7 个多小时的延迟
SQL> set linesize 150;
SQL> set pagesize 9999;
SQL> column name format a13;
SQL> column value format a20;
SQL> column unit format a30;
SQL> column TIME_COMPUTED format a30;
SQL> select name,value,unit,datum_time,time_computed from v$dataguard_stats where name in ('transport lag','apply lag');
NAME VALUE UNIT DATUM_TIME TIME_COMPUTED
------------- -------------------- ------------------------------ ------------------------------ ---------------------------
transport lag +00 00:00:56 day(2) to second(0) interval 07/08/2024 14:54:20 07/08/2024 14:54:20
apply lag +15 07:41:28 day(2) to second(0) interval 07/08/2024 14:54:20 07/08/2024 14:54:20
SQL> select * from v$archive_gap;
no rows selected
SQL> select status from v$instance;
STATUS
------------
OPEN然后排查发现 MRP 进程已经不存在了，重新启用 MRP0 进程之后 alert 日志报错 ORA-01111、ORA-01110 不知道 181 号文件，且显示在 dbs 目录下有个未知名字的文件 UNNAMED00181，但实际情况也没有产生。可查看如下日志：
## 查看 mrp0 发现已经不存在了
SQL> SELECT PROCESS, STATUS,SEQUENCE#,thread# FROM V$MANAGED_STANDBY;
PROCESS STATUS SEQUENCE# THREAD#
--------- ------------ ---------- ----------
ARCH CLOSING 204697 1
DGRD ALLOCATED 0 0
DGRD ALLOCATED 0 0
ARCH CLOSING 204702 1
ARCH CLOSING 204703 1
ARCH CLOSING 204701 1
RFS IDLE 204704 1
RFS IDLE 0 1
RFS IDLE 211552 2
RFS IDLE 0 0
RFS IDLE 0 0
RFS IDLE 0 0
12 rows selected.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE parallel 32 USING CURRENT LOGFILE DISCONNECT;
## alert 日志如下
PR00 (PID:107752): Managed Standby Recovery starting Real Time Apply
2024-07-08T17:53:03.353684+08:00
Errors in file /u01/app/oracle/diag/rdbms/JIEKEDBADG/JIEKEDB/trace/JIEKEDB_dbw0_9386.trc:
ORA-01186: file 181 failed verification tests
ORA-01157: cannot identify/lock data file 181 - see DBWR trace file
ORA-01111: name for data file 181 is unknown - rename to correct file
ORA-01110: data file 181: '/u01/app/oracle/product/19.0.0/dbhome_1/dbs/UNNAMED00181'
2024-07-08T17:53:03.353730+08:00
File 181 not verified due to error ORA-01157
2024-07-08T17:53:03.381689+08:00
PR00 (PID:107752): MRP0: Background Media Recovery terminated with error 1111
2024-07-08T17:53:03.381796+08:00
Errors in file /u01/app/oracle/diag/rdbms/JIEKEDBADG/JIEKEDB/trace/JIEKEDB_pr00_107752.trc:
ORA-01111: name for data file 181 is unknown - rename to correct file
ORA-01110: data file 181: '/u01/app/oracle/product/19.0.0/dbhome_1/dbs/UNNAMED00181'
ORA-01157: cannot identify/lock data file 181 - see DBWR trace file
ORA-01111: name for data file 181 is unknown - rename to correct file
ORA-01110: data file 181: '/u01/app/oracle/product/19.0.0/dbhome_1/dbs/UNNAMED00181'
PR00 (PID:107752): Managed Standby Recovery not using Real Time Apply
Stopping change tracking
2024-07-08T17:53:03.507656+08:00
Recovery Slave PR00 previously exited with exception 1111.
## 查看 dbs 目录下文件不存在
jiekedb:/home/oracle/tmp(JIEKEDB)$ ll /u01/app/oracle/product/19.0.0/dbhome_1/dbs/UNNAMED00181
ls: cannot access /u01/app/oracle/product/19.0.0/dbhome_1/dbs/UNNAMED00181: No such file or directory2.3 GAP 问题排查
既然本地 dbs 目录下还没有生成数据文件，说明还没同步过来，很大情况是 “convert” 和 “standby_file_management” 等相关参数设置有问题。我们登录两个备库查看一下。
----级联备库查看是否有新增文件
SQL> select file_id,file_name from dba_data_files where file_id>=181;
no rows selected
--备库查看是否有新增文件
select count(*) from dba_data_files where file_id>=181;
COUNT(*)
----------
6
--备库查看
15:13:26 SYS@JIEKEDB> show parameter arch
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
archive_lag_target integer 0
log_archive_config string DG_CONFIG=(JIEKEDBDG,JIEKEDBADG,JIEKEDB)
log_archive_dest string
log_archive_dest_1 string LOCATION=/data/jiekedb/archivelog VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=JIEKEDBDG
log_archive_dest_2 string SERVICE=JIEKEDB LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=JIEKEDB
log_archive_dest_3 string SERVICE=JIEKEDBADG ASYNC VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=JIEKEDBADG
----级联备库查看
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.23.0.0.0
SQL> show parameter arch
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
archive_lag_target integer 0
log_archive_config string DG_CONFIG=(JIEKEDBADG,JIEKEDBDG,JIEKEDB)
log_archive_dest_1 string LOCATION=/data/jiekedb/archivelog VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=JIEKEDBADG
log_archive_dest_2 string SERVICE=JIEKEDB LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=JIEKEDB
log_archive_dest_3 string SERVICE=JIEKEDBDG ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=JIEKEDBDG
------级联备库查看此参数为 MANUAL
SQL> show parameter standby_file
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string MANUAL
------级联备库查看 convert 此参数为空
SQL> show parameter convert
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert string
log_file_name_convert string +REDO/JIEKEdb/onlinelog, /data/jiekedb/onlinelog/redo
pdb_file_name_convert string
SQL> show parameter db_create_file_dest
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_create_file_dest string通过查看参数设置，果然级联备库的参数设置有问题，“db_file_name_convert”参数不知什么时候被人置空了，且“standby_file”参数设置为手动了，这里就不去查具体时间了，这样肯定会出问题，就解释了上面没有在 dbs 目录下产生 UNNAMED00181 文件的问题以及没有正常转换的问题，更没有将 181 以后的 6 个数据文件正常同步到级联备库。
181 号文件及以后的数据文件刚好是生产环境源端添加表空间的 6 个数据文件，由于源库表空间告警，添加了 6 个数据文件扩容表空间，但是这个级联备库参数设置错误，导致没有正常同步过来，此时又因为 15 天之前的归档日志被删除了也没有备份，那么只能增量恢复了。这里则先将这两个参数修改为正确的值在重启数据库生效，下一步准备恢复。
--级联备库修改
ALTER SYSTEM SET db_file_name_convert='+DATA/jiekedb/datafile','/data/jiekedb/datafile','+DATA/jiekedb/tempfile','/data/jiekedb/tempfile' SCOPE=SPFILE SID='*';
ALTER SYSTEM SET standby_file_management='AUTO' SCOPE=BOTH;
shu immediate
startup
=======alert=======
alter database rename file '/u01/app/oracle/product/19.0.0/dbhome_1/dbs/UNNAMED00181' to '/data/jiekedb/datafile/jiekedb_data.461.1172399609'
ORA-1511 signalled during: alter database rename file '/u01/app/oracle/product/19.0.0/dbhome_1/dbs/UNNAMED00181' to '/data/jiekedb/datafile/jiekedb_data.461.1172399609'...
2024-07-08T18:08:40.562983+08:00
Errors in file /u01/app/oracle/diag/rdbms/jiekedbadg/jiekedb/trace/jiekedb_mz00_109262.trc:
ORA-01110: data file 181: '/u01/app/oracle/product/19.0.0/dbhome_1/dbs/UNNAMED00181'
ORA-01565: error in identifying file '/u01/app/oracle/product/19.0.0/dbhome_1/dbs/UNNAMED00181'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 72.4 修改级联备库 GAP
因此级联库为 19c，我们便可以使用新特性基于网络来增量恢复级联备库。又因数据量较大，我们便将其放到后台执行。
vim /home/oracle/tmp/rman_duplicate_service.cmdSET COMPRESSION ALGORITHM 'BASIC';
recover standby database from service 'JIEKEDBDG' USING COMPRESSED BACKUPSET;
vim rman_service.sh
rman target / cmdfile=/home/oracle/tmp/rman_duplicate_service.cmd log=/home/oracle/tmp/rman_dup_service.log append
chmod 755 rman_duplicate_service.cmd
chmod 755 rman_service.sh
nohup sh /home/oracle/tmp/rman_service.sh &
tail -120f rman_dup_service.log注意：如果主库为 RAC 又使用了 OMF 自动管理，备库使用文件系统不能用 OMF 自动管理，db_create_file_dest 参数需要置空，不然 from service 无法增量备份，会把主库全部数据文件全量备份一遍，相当于全备。
--主库
SYS@jiekedb1> show parameter db_create_file_dest
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_create_file_dest string +DATA
--备库和级联备库
SQL> show parameter db_create_file_dest
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_create_file_dest string
SQL> show parameter db_file_name_convert
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert string +DATA/jiekedb/datafile, /data/jiekedb/datafile, +DATA/jiekedb/tempfile, /data/jiekedb/tempfile查看上面 rman_dup_service.log 日志，等待增量同步完成后，打开数据库应用 MRP0 进程。但是会在 alert 日志中一直刷 standby redo log 日志不存在的错误，因为在增量恢复的过程中可能有点小问题，直接是源端备库的路径，所以报日志路径不存在，需要手动重建备库 standby redo log 日志组。
2.5 重建 standby redo log
重建日志组这里也有一点儿小问题,就是有一两组一直是 active 状态，怎么切换他的状态都不会改变，我们只能 clear 掉在新建。
set lines 200 pages 9999 LONG 5000
col member for a80
select a.thread#,a.group#,b.member,b.type,a.bytes/1024/1024 MB from v$log a,v$logfile b where a.group#=b.group#
union all
select a.thread#,a.group#,b.member,b.type,a.bytes/1024/1024 MB from v$standby_log a,v$logfile b where a.group#=b.group#;
THREAD# GROUP# MEMBER TYPE MB
---------- ---------- -------------------------------------------------------------------------------- ------- ----------
......
1 20 /data/jiekedb/onlinelog/redo/group_20.280.1129292293 ONLINE 500
1 20 /data/jiekedb/onlinelog/redo/group_20.281.1129292295 ONLINE 500
1 14 /data/jiekedb/fra/JIEKEDBADG/onlinelog/o1_mf_14_m8qlhbbf_.log STANDBY 500
1 15 /data/jiekedb/fra/JIEKEDBDG/onlinelog/o1_mf_15_kz74bht7_.log STANDBY 500
1 16 /data/jiekedb/fra/JIEKEDBADG/onlinelog/o1_mf_16_m8qlhdvk_.log STANDBY 500
1 17 /data/jiekedb/fra/JIEKEDBADG/onlinelog/o1_mf_17_m8qlhhbr_.log STANDBY 500
2 24 /data/jiekedb/fra/JIEKEDBDG/onlinelog/o1_mf_24_kz74g0mn_.log STANDBY 500
2 25 /data/jiekedb/fra/JIEKEDBADG/onlinelog/o1_mf_25_m8qlhkto_.log STANDBY 500
2 26 /data/jiekedb/fra/JIEKEDBADG/onlinelog/o1_mf_26_m8qlhnjh_.log STANDBY 500
2 27 /data/jiekedb/fra/JIEKEDBADG/onlinelog/o1_mf_27_m8qlh7kq_.log STANDBY 500
3 34 /data/jiekedb/fra/JIEKEDBDG/onlinelog/o1_mf_34_kz74loqs_.log STANDBY 500
3 35 /data/jiekedb/fra/JIEKEDBDG/onlinelog/o1_mf_35_kz74mx6z_.log STANDBY 500
3 36 /data/jiekedb/fra/JIEKEDBDG/onlinelog/o1_mf_36_kz74o20r_.log STANDBY 500
3 37 /data/jiekedb/fra/JIEKEDBDG/onlinelog/o1_mf_37_kz74p6h3_.log STANDBY 500
4 44 /data/jiekedb/fra/JIEKEDBDG/onlinelog/o1_mf_44_kz74qbxr_.log STANDBY 500
4 45 /data/jiekedb/fra/JIEKEDBDG/onlinelog/o1_mf_45_kz74rhfc_.log STANDBY 500
4 46 /data/jiekedb/fra/JIEKEDBDG/onlinelog/o1_mf_46_kz74smvv_.log STANDBY 500
4 47 /data/jiekedb/fra/JIEKEDBDG/onlinelog/o1_mf_47_kz74trbl_.log STANDBY 500
SQL> select GROUP#,THREAD#,BYTES/1024/1024 mb,status,FIRST_TIME,NEXT_TIME, LAST_TIME from v$standby_log;
GROUP# THREAD# MB STATUS FIRST_TIME NEXT_TIME LAST_TIME
---------- ---------- ---------- ---------- ------------------- ------------------- -------------------
14 1 500 ACTIVE 2024-07-09 13:56:35 2024-07-09 13:58:46
15 1 500 ACTIVE 2024-07-08 19:09:28
16 1 500 UNASSIGNED
17 1 500 UNASSIGNED
24 2 500 ACTIVE 2024-07-08 19:06:48
25 1 500 UNASSIGNED
34 1 500 UNASSIGNED
35 1 500 UNASSIGNED
36 1 500 UNASSIGNED
37 1 500 UNASSIGNED
44 1 500 UNASSIGNED
45 1 500 UNASSIGNED
46 1 500 UNASSIGNED
47 1 500 UNASSIGNED逐个删除上面查到的 standby log ，如上 group 15 和 24 一直处于 active 状态，只能 clear 掉。
alter database drop logfile group 47,group 46,group 45,group 44;
alter database drop logfile group 37,group 36,group 35,group 34;
alter database add standby logfile thread 1 group 47 ('/data/jiekedb/onlinelog/redo/group_47.282.1129292295','/data/jiekedb/fra/JIEKEDBADG/onlinelog/group_47.283.1129292295') size 500M ;
alter database add standby logfile thread 1 group 46 ('/data/jiekedb/onlinelog/redo/group_46.284.1129292295','/data/jiekedb/fra/JIEKEDBADG/onlinelog/group_46.285.1129292295') size 500M ;
......
SQL> show parameter standby_file_management
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string MANUAL
SQL> alter database clear logfile group 24;
Database altered.
SQL> alter database clear logfile group 15;
Database altered.2.6 开库启动 MRP0
alter database open;
alter database recover managed standby database parallel 32 using current logfile disconnect;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
set linesize 150;
set pagesize 9999;
column name format a13;
column value format a20;
column unit format a30;
column TIME_COMPUTED format a30;
select name,value,unit,datum_time,time_computed from v$dataguard_stats where name in ('transport lag','apply lag');
--停止 MRP0
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SELECT ROLE, THREAD#, SEQUENCE#, ACTION FROM V$DATAGUARD_PROCESS;
--V$DATAGUARD_PROCESS 视图取代了 V$MANAGED_STANDBY 视图，该视图在 Oracle 数据库 12c 版本 2(12.2.0.1) 中已弃用，可能在未来的版本中不支持。
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#,BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;
PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
--------- ------------ ---------- ---------- ---------- ----------
ARCH CLOSING 1 49835 315392 1228
DGRD ALLOCATED 0 0 0 0
DGRD ALLOCATED 0 0 0 0
ARCH CLOSING 2 50562 378880 846
ARCH CLOSING 2 50563 368640 349
ARCH CLOSING 1 49834 356352 898
RFS IDLE 1 49836 238239 1
RFS IDLE 0 0 0 0
RFS IDLE 1 0 0 0
RFS IDLE 0 0 0 0
MRP0 APPLYING_LOG 1 49836 238239 614400
RFS IDLE 0 0 0 0
RFS IDLE 1 0 0 0
RFS IDLE 2 50564 315720 5
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 02.7 观察 from service 操作步骤
首先使用命令 recover standby database from service 'JIEKEDBDG';将备库根据已有参数文件重启至 nomount 然后恢复控制文件启动到 mount 状态，接着将参数 standby_file_management设置为手动恢复主库新增的这 6 个数据文件，使用 restore from service 'JIEKEDBDG' datafile 181, 182, 183, 184, 185, 186;命令,做了 switch 转换，重命名等，这都属于增量恢复，这里在说一句就是你的 convert 参数一定要设置正确，不然直接从第一号文件开始恢复就不能增量了。
Recovery Manager: Release 19.0.0.0.0 - Production on Mon Jul 8 19:08:03 2024
Version 19.23.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
connected to target database: JIEKDB (DBID=657075540, not open)
RMAN> recover standby database from service 'JIEKEDBDG';
2>
Starting recover at 2024-07-08 19:08:04
using target database control file instead of recovery catalog
Oracle instance started
Total System Global Area 214748362096 bytes
Fixed Size 37352816 bytes
Variable Size 25232932864 bytes
Database Buffers 188978561024 bytes
Redo Buffers 499515392 bytes
contents of Memory Script:
{
restore standby controlfile from service 'JIEKEDBDG';
alter database mount standby database;
}
executing Memory Script
Starting restore at 2024-07-08 19:08:18
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1909 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service JIEKEDBDG
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
output file name=/data/jiekedb/controlfile/control01.ctl
output file name=/data/jiekedb/controlfile/control02.ctl
Finished restore at 2024-07-08 19:08:23
released channel: ORA_DISK_1
Statement processed
For record type ARCHIVED LOG RECIDS from 33702 to 418488 are re-used before resync
Executing: alter system set standby_file_management=manual
contents of Memory Script:
{
set newname for datafile 181 to
"/data/jiekedb/datafile/jieke_data.461.1172399609";
set newname for datafile 182 to
"/data/jiekedb/datafile/jieke_data.462.1172399967";
set newname for datafile 183 to
"/data/jiekedb/datafile/jieke_data.463.1172400223";
set newname for datafile 184 to
"/data/jiekedb/datafile/jieke_data.464.1172766735";
set newname for datafile 185 to
"/data/jiekedb/datafile/jieke_data.465.1172766893";
set newname for datafile 186 to
"/data/jiekedb/datafile/jieke_data.466.1172767147";
restore from service 'JIEKEDBDG' datafile
181, 182, 183, 184, 185, 186;
catalog datafilecopy "/data/jiekedb/datafile/jieke_data.461.1172399609",
"/data/jiekedb/datafile/jieke_data.462.1172399967",
"/data/jiekedb/datafile/jieke_data.463.1172400223",
"/data/jiekedb/datafile/jieke_data.464.1172766735",
"/data/jiekedb/datafile/jieke_data.465.1172766893",
"/data/jiekedb/datafile/jieke_data.466.1172767147";
switch datafile all;
}
executing Memory Script
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
Starting restore at 2024-07-08 19:08:28
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=2161 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service JIEKEDBDG
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00181 to /data/jiekedb/datafile/jieke_data.461.1172399609
channel ORA_DISK_1: restore complete, elapsed time: 00:00:45
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service JIEKEDBDG
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00182 to /data/jiekedb/datafile/jieke_data.462.1172399967
channel ORA_DISK_1: restore complete, elapsed time: 00:00:45
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service JIEKEDBDG
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00183 to /data/jiekedb/datafile/jieke_data.463.1172400223
channel ORA_DISK_1: restore complete, elapsed time: 00:00:45
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service JIEKEDBDG
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00184 to /data/jiekedb/datafile/jieke_data.464.1172766735
channel ORA_DISK_1: restore complete, elapsed time: 00:00:45
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service JIEKEDBDG
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00185 to /data/jiekedb/datafile/jieke_data.465.1172766893
channel ORA_DISK_1: restore complete, elapsed time: 00:00:45
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service JIEKEDBDG
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00186 to /data/jiekedb/datafile/jieke_data.466.1172767147
channel ORA_DISK_1: restore complete, elapsed time: 00:00:45
Finished restore at 2024-07-08 19:12:59
cataloged datafile copy
datafile copy file name=/data/jiekedb/datafile/jieke_data.462.1172399967 RECID=311 STAMP=1173813179
cataloged datafile copy
datafile copy file name=/data/jiekedb/datafile/jieke_data.461.1172399609 RECID=312 STAMP=1173813179
cataloged datafile copy
datafile copy file name=/data/jiekedb/datafile/jieke_data.463.1172400223 RECID=313 STAMP=1173813185
cataloged datafile copy
datafile copy file name=/data/jiekedb/datafile/jieke_data.464.1172766735 RECID=314 STAMP=1173813185
cataloged datafile copy
datafile copy file name=/data/jiekedb/datafile/jieke_data.465.1172766893 RECID=315 STAMP=1173813192
cataloged datafile copy
datafile copy file name=/data/jiekedb/datafile/jieke_data.466.1172767147 RECID=316 STAMP=1173813192
datafile 181 switched to datafile copy
input datafile copy RECID=312 STAMP=1173813179 file name=/data/jiekedb/datafile/jieke_data.461.1172399609
datafile 182 switched to datafile copy
input datafile copy RECID=311 STAMP=1173813179 file name=/data/jiekedb/datafile/jieke_data.462.1172399967
datafile 183 switched to datafile copy
input datafile copy RECID=313 STAMP=1173813185 file name=/data/jiekedb/datafile/jieke_data.463.1172400223
datafile 184 switched to datafile copy
input datafile copy RECID=314 STAMP=1173813185 file name=/data/jiekedb/datafile/jieke_data.464.1172766735
datafile 185 switched to datafile copy
input datafile copy RECID=315 STAMP=1173813192 file name=/data/jiekedb/datafile/jieke_data.465.1172766893
datafile 186 switched to datafile copy
input datafile copy RECID=316 STAMP=1173813192 file name=/data/jiekedb/datafile/jieke_data.466.1172767147接下来 recover 数据库基于增量 SCN 93208937278 从第一号数据文件往后恢复，一直到 185 号数据文件，由于 186 号文件已经应用到 SCN 93208937278 故直接跳过了。下面中间过程由于篇幅过长我这直接省略了。
contents of Memory Script:
{
recover database from service 'JIEKEDBDG';
}
executing Memory Script
Starting recover at 2024-07-08 19:13:18
using channel ORA_DISK_1
skipping datafile 186; already restored to SCN 93208937278
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using network backup set from service JIEKEDBDG
destination for restore of datafile 00001: /data/jiekedb/datafile/system.378.1128999715
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using network backup set from service JIEKEDBDG
destination for restore of datafile 00002: /data/jiekedb/datafile/sysaux.306.1128998837
channel ORA_DISK_1: restore complete, elapsed time: 00:00:55
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using network backup set from service JIEKEDBDG
destination for restore of datafile 00003: /data/jiekedb/datafile/undotbs1.374.1128974213
。。。。。。
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using network backup set from service JIEKEDBDG
destination for restore of datafile 00183: /data/jiekedb/datafile/jieke_data.463.1172400223
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using network backup set from service JIEKEDBDG
destination for restore of datafile 00184: /data/jiekedb/datafile/jieke_data.464.1172766735
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using network backup set from service JIEKEDBDG
destination for restore of datafile 00185: /data/jiekedb/datafile/jieke_data.465.1172766893
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03接下来就是介质恢复了，通过应用归档日志前滚数据库完成一致性恢复，最后将参数 standby_file_management 设置为 auto 完成整个增量恢复过程。
starting media recovery
archived log for thread 1 with sequence 203963 is already on disk as file /data/jiekedb/archivelog/1_203963_1129114545.arc
......
archived log for thread 2 with sequence 210847 is already on disk as file /data/jiekedb/archivelog/2_210847_1129114545.arc
archived log for thread 2 with sequence 210848 is already on disk as file /data/jiekedb/archivelog/2_210848_1129114545.arc
archived log file name=/data/jiekedb/archivelog/1_203963_1129114545.arc thread=1 sequence=203963
archived log file name=/data/jiekedb/archivelog/2_210824_1129114545.arc thread=2 sequence=210824
......
archived log file name=/data/jiekedb/archivelog/2_210848_1129114545.arc thread=2 sequence=210848
archived log file name=/data/jiekedb/archivelog/1_203987_1129114545.arc thread=1 sequence=203987
media recovery complete, elapsed time: 00:00:31
Finished recover at 2024-07-08 20:46:25
Executing: alter system set standby_file_management=auto
Finished recover at 2024-07-08 20:46:25
Recovery Manager complete.最后，我们只需要打开数据库，重建 standby redo log，启用 MRP0 即可，这些步骤官网上没有说明，但也需要操作哦！
三、参考链接
12.1c 《Database Backup and Recovery User's Guide》 Restoring and Recovering Files Over the Network https://docs.oracle.com/database/121/BRADV/rcmadvre.htm#CACFAHHJ
19c 《Database Backup and Recovery User's Guide》 20.7 Restoring and Recovering Files Over the Network https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/rman-recovery-advanced.html#GUID-8E64485B-3788-4389-A892-8C560F12443F
23ai 《Backup and Recovery User's Guide》 19.7 Restoring and Recovering Files Over the Network https://docs.oracle.com/en/database/oracle/oracle-database/23/bradv/rman-recovery-advanced.html#GUID-DF586DC2-A0F0-4EFD-AF8A-FC6C0B553C31全文完，希望可以帮到正在阅读的你，如果觉得有帮助，可以分享给你身边的朋友，同事，你关心谁就分享给谁，一起学习共同进步~~~
❤️ 欢迎关注我的公众号【JiekeXu DBA之路】，一起学习新知识！
分享几个数据库备份脚本
一文搞懂 Oracle 统计信息我的 Oracle ACE 心路历程
MOP 系列|MOP 三种主流数据库索引简介
Oracle 主流版本不同架构下的静默安装指南关机重启导致 ASM 磁盘丢失数据库无法启动
Oracle SQL 性能分析(SPA)原理与实战演练Oracle 11g 升级到 19c 需要关注的几个问题
Windows 10 环境下 MySQL 8.0.33 安装指南
SQL 大全（四）|数据库迁移升级时常用 SQL 语句
OGG|使用 OGG19c 迁移 Oracle11g 到 19C(第二版)
Oracle 大数据量导出工具——sqluldr2 的安装与使用从国产数据库调研报告中你都能了解哪些信息及我的总结建议
使用数据泵利用 rowid 分片导出导入 lob 大表及最佳实践
在归档模式下直接 rm dbf 数据文件并重启数据库还有救吗？欢迎关注我的公众号【JiekeXu DBA之路】，一起学习新知识！
——————————————————————————
公众号：JiekeXu DBA之路
墨天轮：https://www.modb.pro/u/4347
CSDN ：https://blog.csdn.net/JiekeXu
ITPUB：https://blog.itpub.net/69968215
腾讯云：https://cloud.tencent.com/developer/user/5645107
——————————————————————————
扫一扫
1000
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
