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。

具体步骤：

1. 启动备库到 NOMOUNT 状态：

   SQL> SHUTDOWN IMMEDIATE;
   SQL> STARTUP NOMOUNT;

2. 从主库恢复控制文件：

   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;

3. 检查主备 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

4. 恢复新添加的数据文件：

   RMAN> RUN {
     SET NEWNAME FOR DATABASE TO '/oradata/ORCL_STBY/%f_%U';
     RESTORE DATAFILE 158 FROM SERVICE orcl;
   }

5. 如果主备数据文件目录不一致，修改控制文件中数据文件位置：

   RMAN> CATALOG START WITH '/oradata/ORCL_STBY/';
   RMAN> SWITCH DATABASE TO COPY;

6. 重命名临时文件和日志文件

   • 设置 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;

7. 恢复主备 GAP：

   RMAN> RECOVER DATABASE FROM SERVICE orcl NOREDO USING COMPRESSED BACKUPSET;

   注意：如果主备库文件目录不一致，则需要 catalog 切换控制文件中路径，否则报错。

3. 开启备库日志应用，检查同步情况

1. 检查主备 SCN 是否一致：

   SQL> SET LINE 300
   SQL> COL HXFNM FOR A100
   SQL> SELECT HXFIL File_num, SUBSTR(HXFNM, 1, 40) HXFNM, FHSCN FROM x$kcvfh;

2. 主库切几次归档：

   SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
   SQL> ALTER SYSTEM SWITCH LOGFILE;

3. 开启备库应用日志：

   SQL> ALTER DATABASE OPEN;
   SQL> ALTER PLUGGABLE DATABASE ALL OPEN;
   SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

4. 查看备库同步是否正常：

   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#;

5. 测试同步情况：

   • 在主库插入数据：

     SQL> INSERT INTO test.test VALUES (999);
     SQL> COMMIT;

   • 在备库查询是否实时同步：

     SQL> ALTER SESSION SET CONTAINER=pdb01;
     SQL> SELECT * FROM test.test;

方法二：通过网络服务直接增量恢复（适用于 12c 及以上版本）

1. 连接目标数据库

   CONNECT TARGET "sys/@orcldg AS SYSDBA"

2. 设置压缩参数以减少网络带宽

   压缩级别选项：

   SET COMPRESSION ALGORITHM 'BASIC';
   SET COMPRESSION ALGORITHM 'LOW';
   SET COMPRESSION ALGORITHM 'MEDIUM';
   SET COMPRESSION ALGORITHM 'HIGH';

   选择合适的压缩级别

   SET COMPRESSION ALGORITHM 'HIGH';

3. 执行恢复命令

   RECOVER DATABASE FROM SERVICE orcl USING COMPRESSED BACKUPSET;

4. 开启备库应用日志

   ALTER DATABASE OPEN;
   ALTER PLUGGABLE DATABASE ALL OPEN;
   ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

5. 验证修复结果

   确保所有的修复操作完成后，检查数据库状态以验证 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 修复过程。这些新功能不仅减少了操作复杂度，还提高了效率和准确性。