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