Oracle 12c Data Guard 环境中的 GAP 修复方法
概述
上文中提到Oracle 12c 引入了多项新技术来简化 Data Guard 环境中的 GAP 修复过程，如（RECOVER … FROM SERVICE）。这些新特性不仅减少了操作步骤，还提高了效率和准确性。本文档将详细说明如何利用这些新特性进行 GAP 修复。
示例场景
为了更好地理解整个过程，我们假设以下情景：
- 模拟备库断电：备库突然断电，导致与主库之间的日志同步中断。
- 主库切几个最新的归档：主库继续工作并切换了多个归档日志。
- 手工删除归档日志：模拟过程中手工删除了一些归档日志文件。
- 重新开启 DG 同步：尝试重新同步时发现存在 GAP。
步骤详解
1. 记录备库当前 SCN 号
首先，记录备库当前的 SCN 号，以便后续使用。
-- 在备库上查询当前 SCN 号
SQL> SELECT CURRENT_SCN FROM V$DATABASE;
CURRENT_SCN
-----------
47879834
2. 使用 RECOVER STANDBY USING SERVICE 恢复
采用 RMAN 的新功能 recover standby using service，通过 RMAN 连接到 target 备库，并用主库的服务名执行恢复命令。
语法：
RECOVER DATABASE FROM SERVICE <primary_db_service_name> NOREDO USING COMPRESSED BACKUPSET;
注意：确认主库的 TNS 已配置，这里的 <primary_db_service_name> 即 TNSNAME。
具体步骤：
-
启动备库到 NOMOUNT 状态：
SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP NOMOUNT; -
从主库恢复控制文件：
RUN {RESTORE STANDBY CONTROLFILE FROM SERVICE <primary_service_name>;ALTER DATABASE MOUNT; }这里
<primary_service_name>是主库的服务名，例如orcl-- 备库恢复控制文件 RMAN> RESTORE STANDBY CONTROLFILE FROM SERVICE orcl; -- 备库启动到mount状态 SQL> ALTER DATABASE MOUNT; -
检查主备 GAP 期间是否添加了数据文件：
查询备库上数据文件头最小的 SCN
SELECT MIN(fhscn) FROM x$kcvfh; -- 示例输出: 47879834在主库上查询低 SCN 后新增加的数据文件
SELECT FILE# FROM V$DATAFILE WHERE CREATION_CHANGE# >= <min_scn>; -- 示例中 <min_scn> 为 47879834，查询得到缺失的数据文件号为 158。-- 查询在指定 SCN 后新增的数据文件 SQL> SELECT FILE# FROM V$DATAFILE WHERE CREATION_CHANGE# >= 47879834; FILE# ---------- 158 -
恢复新添加的数据文件：
RMAN> RUN {SET NEWNAME FOR DATABASE TO '/oradata/ORCL_STBY/%f_%U';RESTORE DATAFILE 158 FROM SERVICE orcl; } -
如果主备数据文件目录不一致，修改控制文件中数据文件位置：
RMAN> CATALOG START WITH '/oradata/ORCL_STBY/'; RMAN> SWITCH DATABASE TO COPY; -
重命名临时文件和日志文件
-
设置
STANDBY_FILE_MANAGEMENT为手动：SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL; -
清除日志文件组：
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1; SQL> ALTER DATABASE CLEAR LOGFILE GROUP 2; SQL> ALTER DATABASE CLEAR LOGFILE GROUP 3; ... -- 重复以上命令直至所有需要清除的日志文件组都被处理。 -
重命名日志文件：
SQL> ALTER DATABASE RENAME FILE '/oradata/ORCL/redo01.log' TO '/oradata/ORCL_STBY/redo01.log'; ... SQL> ALTER DATABASE RENAME FILE '/oradata/ORCL/standby_redo04.log' TO '/oradata/ORCL_STBY/standby_redo04.log'; ... -- 重复以上命令直至所有需要重命名的日志文件都被处理。 -
重命名临时文件：
SQL> ALTER DATABASE RENAME FILE '/oradata/ORCL/temp01.dbf' TO '/oradata/ORCL_STBY/temp01.dbf'; ... -- 重复以上命令直至所有需要重命名的临时文件都被处理。 -
设置
STANDBY_FILE_MANAGEMENT为自动：SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;
-
-
恢复主备 GAP：
RMAN> RECOVER DATABASE FROM SERVICE orcl NOREDO USING COMPRESSED BACKUPSET;注意：如果主备库文件目录不一致，则需要 catalog 切换控制文件中路径，否则报错。
3. 开启备库日志应用，检查同步情况
-
检查主备 SCN 是否一致：
SQL> SET LINE 300 SQL> COL HXFNM FOR A100 SQL> SELECT HXFIL File_num, SUBSTR(HXFNM, 1, 40) HXFNM, FHSCN FROM x$kcvfh; -
主库切几次归档：
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; SQL> ALTER SYSTEM SWITCH LOGFILE; -
开启备库应用日志：
SQL> ALTER DATABASE OPEN; SQL> ALTER PLUGGABLE DATABASE ALL OPEN; SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; -
查看备库同步是否正常：
SQL> SET LINE 300 SQL> COL MEMBER FOR A60 SQL> SELECT T1.GROUP#, T1.THREAD#, T1.BYTES / 1024 / 1024, T1.STATUS, T2.MEMBER FROM GV$STANDBY_LOG T1, GV$LOGFILE T2 WHERE T1.GROUP# = T2.GROUP#; -
测试同步情况：
-
在主库插入数据：
SQL> INSERT INTO test.test VALUES (999); SQL> COMMIT; -
在备库查询是否实时同步：
SQL> ALTER SESSION SET CONTAINER=pdb01; SQL> SELECT * FROM test.test;
-
方法二：通过网络服务直接增量恢复（适用于 12c 及以上版本）
-
连接目标数据库
CONNECT TARGET "sys/@orcldg AS SYSDBA" -
设置压缩参数以减少网络带宽
压缩级别选项：
SET COMPRESSION ALGORITHM 'BASIC'; SET COMPRESSION ALGORITHM 'LOW'; SET COMPRESSION ALGORITHM 'MEDIUM'; SET COMPRESSION ALGORITHM 'HIGH';选择合适的压缩级别
SET COMPRESSION ALGORITHM 'HIGH'; -
执行恢复命令
RECOVER DATABASE FROM SERVICE orcl USING COMPRESSED BACKUPSET; -
开启备库应用日志
ALTER DATABASE OPEN; ALTER PLUGGABLE DATABASE ALL OPEN; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; -
验证修复结果
确保所有的修复操作完成后，检查数据库状态以验证 GAP 是否已经成功修复。
-- 查看是否有剩余的 GAP SELECT * FROM V$ARCHIVE_GAP;-- 检查应用的最大序列号 SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED='YES';-- 检查管理进程的状态 SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;
总结
通过上述步骤，可以利用 Oracle 12c 提供的新特性显著简化 Data Guard 环境中的 GAP 修复过程。这些新功能不仅减少了操作复杂度，还提高了效率和准确性。