1.问题分析

触发场景：
备库故障停机，期间主库持续写入数据并执行了归档日志清理（例如为了释放磁盘空间等），导致备库恢复以后，其本地LSN与主库LSN出现断层，备库虽然能够启动，但归档功能异常，无法与主库同步，监视器中会显示归档不连续的错误日志。
解决思路：
以主库当前的数据为基准，重构备库的数据文件，再让备库从当前LSN点开始追同步。
具体分为三步：
1）在主库基于当前LSN做全量备份
2）将备份文件传输给备库，执行恢复
3）重新启动备库及守护集群，加入集群

2.准备测试环境
准备一套主备集群，首先启动监视器，查看集群状态，此时可以看到，集群工作状态正常。

此示例以主机A(192.168.244.142),备机B（192.168.244.139）为示范

3.模拟测试

3.1停止备机

首先女执行备库离线，模拟备库故障场景：
停止守护进程和数据库实例，并查看状态

3.2查看主机归档

现在连接主机的数据库，查看归档状态
SELECT ARCH_NAME, ARCH_TYPE, ARCH_DEST, ARCH_IS_VALID FROM SYS.V$DM_ARCH_INI;

此时可以看到，本地归档（指向本机）依旧有效，实时归档（指向备机）已经无效。

3.3主库写入数据

此时模拟备库掉线情况下，主机依旧在执行业务，写入数据，推进LSN，使主备库的LSN不一致。
– 1. 创建测试表
CREATE TABLE TEST_TABLE (ID INT, NAME VARCHAR(50));

– 2. 插入两条数据
INSERT INTO TEST_TABLE VALUES (1, ‘before_arch_clean’);
INSERT INTO TEST_TABLE VALUES (2, ‘test_data’);
COMMIT;

– 3. 查询确认数据已插入
SELECT * FROM TEST_TABLE;

– 4. 记录当前时间（关键！删除前的时间点，恢复要用）
SELECT SYSDATE FROM V$DATABASE;

3.4删除日志

首先执行两次ALTER SYSTEM SWITCH LOGFILE,强制将当前正在写的日志文件封存归档
再删除所有历史归档日志，模拟为了清理磁盘而做出的清理行为，这一步是制造主备库归档断层的关键。

4.重启备库

此时再重启备库的实例与守护，查看归档是否连续
启动备库实例
DmServiceGRP1_RT_03 start

启动备库守护进程
DmWatcherServiceGRP1_RT_03 start

再去监视器查看状态

查看监视器可知，备库虽然回到了集群，但是备库的归档已经无效，备库的LSN停留在 13154501（对应插入前两条数据时的状态），主库已经推进到 13154576（清理归档后的状态）。中间的日志已经被删除，备库无法追平 → 归档断层。

5.开始恢复

5.1主库全量备份

到主库上执行全量备份
BACKUP DATABASE FULL TO “rebuild_backup”
BACKUPSET ‘/home/dmdba/backup_20260731’;

通过查看文件，已经备份完成。

5.2备份传输到备机

此时备机上可以看到相应的备份

5.3关闭备库

关闭备库守护进程

DmServiceGRP1_RT_03 stop
#关闭备库实例
./DmWatcherServiceGRP1_RT_03 stop

确认备库已关闭

ps -ef | grep “dmserver|dmwatcher” | grep -v grep

5.4执行还原

cd /home/dmdba/dmdbms/bin
dmrman
RESTORE DATABASE ‘/home/dmdba/dmdbms/data/DAMENG/dm.ini’
FROM BACKUPSET ‘/home/dmdba/backup_rebuild_20260731’;

如图所示，已经还原成功。

5.5.执行恢复

RECOVER DATABASE ‘/home/dmdba/dmdbms/data/DAMENG/dm.ini’ FROM BACKUPSET ‘/home/dmdba/backup_20260731’;

5.6更新魔数

RECOVER DATABASE ‘/home/dmdba/dmdbms/data/DAMENG/dm.ini’ UPDATE DB_MAGIC;

重启备库

6.校验集群

此时，再次查看监视器，可以观察到，主备库的归档已经恢复正常，备库追平主库，集群整体已恢复正常。

登录备库，也能查询到刚刚主库写入的数据

至此，关于模拟备库掉线后，主库写入数据，删除日志导致的归档不连续问题已经完成测试。# 一级标题