Oracle 19c ADG 实时同步故障排查与修复：Standby Redo Log（SRL）文件缺失导致备库仅在主库归档后同步

一、故障现象

一套 Oracle 19c Active Data Guard（ADG）主备环境完成配置后，进行数据同步验证时发现：

主库执行 INSERT + COMMIT 后，备库无法实时查询新增数据；只有在主库执行日志切换或强制归档后，备库才能查询到数据。

但从数据库状态来看：

主库正常提供读写服务。
备库显示 READ ONLY WITH APPLY。
主备 Redo 传输进程均存在。
主库归档目的地状态为 VALID。
归档日志能够正常传输与应用。

说明 Data Guard 已具备基本的日志传输与恢复能力，但 Real-Time Apply（实时日志应用）存在异常。

1.1 环境信息

项目	主库	备库
操作系统	AlmaLinux 9	AlmaLinux 9
数据库版本	Oracle 19c（19.25）	Oracle 19c（19.25）
示例 IP	192.168.100.11	192.168.100.12
示例主机名	oracle-primary	oracle-standby
数据库架构	单实例 CDB/PDB	单实例 CDB/PDB
数据库角色	PRIMARY	PHYSICAL STANDBY
打开模式	READ WRITE	READ ONLY WITH APPLY
保护模式	MAXIMUM PERFORMANCE	MAXIMUM PERFORMANCE
Redo 传输方式	ASYNC	RFS 接收
Online Redo	8 组，每组 1024 MB	保留 Online Redo 元数据
数据目录	`/app/data`	`/app/data`
归档目录	`/app/archivelog`	`/app/archivelog`

本次采用 MAXIMUM PERFORMANCE + ASYNC，这是 Oracle Data Guard 常见的最大性能保护配置。

需要区分三个概念：

配置	含义
MAXIMUM PERFORMANCE	Data Guard 数据保护模式
ASYNC	主库向备库异步传输 Redo
Real-Time Apply	备库从 SRL 中实时应用 Redo

ASYNC 并不意味着必须等待归档才能同步。在 SRL 和 Redo Apply 正常工作的前提下，ASYNC 同样能够实现实时日志应用。

1.2 数据同步测试

主库进入业务 PDB：

复制代码

ALTER SESSION SET CONTAINER=TESTPDB;

INSERT INTO ADGTEST(ID) VALUES(4);
COMMIT;

备库查询：

复制代码

ALTER SESSION SET CONTAINER=TESTPDB;

SELECT * FROM ADGTEST WHERE ID=4;

结果：

复制代码

no rows selected

随后主库执行：

复制代码

ALTER SYSTEM ARCHIVE LOG CURRENT;

备库便能够查询到对应数据。

初步定位方向：归档传输与应用正常，重点检查 Standby Redo Log（SRL）实时接收链路。

二、排查数据库与日志传输状态

2.1 检查主备数据库角色

分别在主库、备库的 CDB$ROOT 执行：

复制代码

SELECT
    NAME,
    DATABASE_ROLE,
    OPEN_MODE,
    PROTECTION_MODE
FROM V$DATABASE;

实际检查结果：

主库：

复制代码

DATABASE_ROLE    OPEN_MODE
---------------- ----------------
PRIMARY          READ WRITE

备库：

复制代码

DATABASE_ROLE     OPEN_MODE
----------------- --------------------
PHYSICAL STANDBY READ ONLY WITH APPLY

说明备库已经启用 Redo Apply。

但 READ ONLY WITH APPLY 只能证明恢复服务已启动，不能证明当前 Redo 正在实时应用。

2.2 检查日志传输目的地

主库执行：

复制代码

SELECT
    DEST_ID,
    STATUS,
    TARGET,
    TRANSMIT_MODE,
    VALID_NOW,
    ERROR
FROM V$ARCHIVE_DEST
WHERE DEST_ID IN (1,2);

实际结果：

复制代码

DEST_ID STATUS TARGET  TRANSMIT_MODE VALID_NOW ERROR
------- ------ ------- ------------- --------- -----
1       VALID  PRIMARY               YES
2       VALID  STANDBY ASYNCHRONOUS  YES

主库本地归档及远程备库传输目的地均有效，未报告配置错误。

因此，没有证据需要修改 LOG_ARCHIVE_DEST_2 或将 ASYNC 调整为 SYNC。

2.3 检查 Data Guard 延迟

备库执行：

复制代码

SELECT
    NAME,
    VALUE,
    TIME_COMPUTED,
    DATUM_TIME
FROM V$DATAGUARD_STATS
WHERE NAME IN ('transport lag','apply lag');

故障期间出现：

复制代码

transport lag    +00 01:20:27
apply lag        +00 01:20:27

传输与应用延迟均已超过一小时，结合新增事务长期不可见，说明同步存在实际异常。

延迟指标需要与 DATUM_TIME、日志接收进度共同分析，不能仅凭数值直接判断网络故障。

2.4 检查主库发送与备库接收进程

主库执行：

复制代码

SELECT
    ROLE,
    ACTION,
    THREAD#,
    SEQUENCE#,
    BLOCK#
FROM V$DATAGUARD_PROCESS
WHERE ROLE LIKE 'async%';

结果：

复制代码

ROLE             ACTION  THREAD# SEQUENCE# BLOCK#
---------------- ------- ------- --------- ------
async ORL multi  WRITING       1        16  20649

备库执行：

复制代码

SELECT
    ROLE,
    ACTION,
    THREAD#,
    SEQUENCE#,
    BLOCK#,
    GROUP#
FROM V$DATAGUARD_PROCESS
WHERE ROLE LIKE 'RFS%';

结果：

复制代码

ROLE       ACTION THREAD# SEQUENCE# BLOCK# GROUP#
---------- ------ ------- --------- ------ ------
RFS async  IDLE         1        16  20662      0
RFS ping   IDLE         1        16      0      0

主备进程均在 Sequence 16，传输会话存在。

但备库 RFS 未显示正在使用的日志组，结合事务同步异常，需要进一步检查 SRL。

三、定位根因：备库 SRL 物理文件缺失

SRL 是 Standby Redo Log 的缩写，中文名称为"备用重做日志"。

在 Oracle Data Guard / ADG 架构中，SRL 是备库用于接收主库传输过来的 Redo 数据的日志文件，是实现 Real-Time Apply（实时日志应用）的重要组成部分。

3.1 检查 SRL 状态

备库执行：

复制代码

SELECT
    GROUP#,
    THREAD#,
    SEQUENCE#,
    STATUS,
    ROUND(BYTES/1024/1024) SIZE_MB,
    ROUND(USED/1024/1024,2) USED_MB
FROM V$STANDBY_LOG
ORDER BY GROUP#;

检查发现原有 SRL Group 9～17：

每组 1024 MB。
全部为 UNASSIGNED。
SEQUENCE#=0。
USED=0。

需要注意，UNASSIGNED 本身不代表日志组损坏，尚未使用的 SRL 也可以处于该状态。

因此，继续检查日志文件实际位置。

3.2 核实 SRL 物理文件

备库执行：

复制代码

SET LINESIZE 220
COLUMN MEMBER FORMAT A120

SELECT
    GROUP#,
    TYPE,
    MEMBER
FROM V$LOGFILE
WHERE TYPE='STANDBY'
ORDER BY GROUP#;

发现原有日志文件登记路径类似：

复制代码

/app/data/PRIMARYDB/onlinelog/o1_mf_9_xxxxx.log
/app/data/PRIMARYDB/onlinelog/o1_mf_10_xxxxx.log
...
/app/data/PRIMARYDB/onlinelog/o1_mf_17_xxxxx.log

登录备库服务器检查：

复制代码

ls -lh /app/data/PRIMARYDB/onlinelog/

发现控制文件中登记的旧 SRL 文件实际上并不存在。

这说明数据库元数据与操作系统中的物理日志文件已经不一致。

3.3 检查 Alert Log

备库执行：

复制代码

SET LINESIZE 220
COLUMN MESSAGE_TEXT FORMAT A150

SELECT
    TO_CHAR(
        ORIGINATING_TIMESTAMP,
        'YYYY-MM-DD HH24:MI:SS'
    ) LOG_TIME,
    MESSAGE_TEXT
FROM V$DIAG_ALERT_EXT
WHERE MESSAGE_TEXT LIKE '%ORA-00313%'
   OR MESSAGE_TEXT LIKE '%ORA-27037%'
   OR MESSAGE_TEXT LIKE '%No SRLs available%'
ORDER BY ORIGINATING_TIMESTAMP DESC
FETCH FIRST 50 ROWS ONLY;

日志中出现：

复制代码

ORA-00313: cannot open members of log group 17

ORA-00312: online log 17:
'/app/data/PRIMARYDB/onlinelog/o1_mf_17_xxxxx.log'

ORA-27037: unable to obtain file status

Linux Error: 2: No such file or directory

同时还出现：

复制代码

rfs: No SRLs available for T-1

这些错误与之前发现的物理文件缺失完全吻合。

3.4 根因分析

Oracle ADG 实时应用的主要流程为：

复制代码

主库事务提交
     |
     v
生成 Online Redo
     |
     v
TT03 异步传输 Redo
     |
     v
备库 RFS 接收
     |
     v
写入 Standby Redo Log
     |
     v
MRP 实时应用 Redo
     |
     v
备库查询到最新数据

本次故障的关键问题是：

备库原有 SRL Group 9～17 对应的物理文件缺失，导致 RFS 无法正常使用这些日志组承接实时 Redo。

但归档日志传输与应用仍然可用，因此主库切换归档后，备库又能够查询到新增数据。

至于旧 SRL 文件最初为何缺失，本次没有取得充分证据，不能直接归因于某个部署工具或特定操作。

四、修复处理：重建 SRL 并清理失效日志组

根据排查结果，采用以下方案：

新建具有有效物理文件的 SRL。
验证新日志组和实际文件。
停止 Redo Apply，清理旧 SRL。
恢复文件自动管理和 Redo Apply。
验证新 SRL 是否能够接收实时 Redo。

Oracle 官方要求，在物理备库增删日志组前，停止 Redo Apply，并将 STANDBY_FILE_MANAGEMENT 临时调整为 MANUAL，维护完成后恢复原配置。

Oracle 文档

以下整理为规范操作顺序。涉及数据库日志组变更，生产环境须提前确认维护窗口、磁盘空间、日志组状态及回退方案。

4.1 核实主库 Online Redo 配置

主库执行：

复制代码

SELECT
    THREAD#,
    GROUP#,
    ROUND(BYTES/1024/1024) AS SIZE_MB,
    STATUS
FROM V$LOG
ORDER BY GROUP#;

实际主库为单线程，共 8 组 Online Redo，每组 1024 MB。

本次按照每个 Thread 的 Online Redo 组数加 1 的常见原则，在备库配置 9 组 SRL，每组 1024 MB。

此配置适用于本案例，不应直接照搬到多 Thread 的 RAC 环境。

4.2 停止备库 Redo Apply

首先确认备库：

复制代码

SELECT DATABASE_ROLE, OPEN_MODE
FROM V$DATABASE;

在备库 CDB$ROOT 执行：

复制代码

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

确认：

复制代码

PHYSICAL STANDBY    READ ONLY

然后执行：

复制代码

ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT='MANUAL' SCOPE=MEMORY;

检查：

复制代码

SHOW PARAMETER standby_file_management;

确认参数为 MANUAL。

4.3 创建新的 SRL Group 18～26

确认 Group 18～26 尚未被占用，且备库 DB_CREATE_FILE_DEST 已正确配置：

复制代码

SHOW PARAMETER db_create_file_dest;

实际配置：

复制代码

db_create_file_dest = /app/data

因此使用 Oracle Managed Files（OMF）自动分配日志文件名。

在备库逐组执行：

复制代码

ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 18 SIZE 1024M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 19 SIZE 1024M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 20 SIZE 1024M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 21 SIZE 1024M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 22 SIZE 1024M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 23 SIZE 1024M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 24 SIZE 1024M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 25 SIZE 1024M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 26 SIZE 1024M;

以上命令在本次环境中均执行成功。

检查：

复制代码

SELECT
    GROUP#,
    THREAD#,
    STATUS,
    ROUND(BYTES/1024/1024) AS SIZE_MB
FROM V$STANDBY_LOG
ORDER BY GROUP#;

再查看日志路径：

复制代码

SET LINESIZE 220
COLUMN MEMBER FORMAT A120

SELECT
    GROUP#,
    TYPE,
    MEMBER
FROM V$LOGFILE
WHERE TYPE='STANDBY'
ORDER BY GROUP#;

本次新日志文件自动生成在备库专用目录：

复制代码

/app/data/STANDBYDB/onlinelog/

操作系统检查：

复制代码

ls -lh /app/data/STANDBYDB/onlinelog/
df -h /app

核实 9 组新 SRL 均已实际创建，文件大小、权限及磁盘剩余空间正常。

注意：不能只检查控制文件中的日志组记录，必须核实日志文件实际存在。

4.4 清理旧 SRL Group 9～17

新 SRL 完整创建后，再次确认旧 Group 9～17 均为 UNASSIGNED：

复制代码

SELECT
    GROUP#,
    THREAD#,
    STATUS,
    SEQUENCE#
FROM V$STANDBY_LOG
ORDER BY GROUP#;

本次实际确认旧组均未分配，且其对应物理文件缺失。

保持 Redo Apply 停止及 MANUAL 状态，逐条删除旧日志组：

复制代码

ALTER DATABASE DROP STANDBY LOGFILE GROUP 9;
ALTER DATABASE DROP STANDBY LOGFILE GROUP 10;
ALTER DATABASE DROP STANDBY LOGFILE GROUP 11;
ALTER DATABASE DROP STANDBY LOGFILE GROUP 12;
ALTER DATABASE DROP STANDBY LOGFILE GROUP 13;
ALTER DATABASE DROP STANDBY LOGFILE GROUP 14;
ALTER DATABASE DROP STANDBY LOGFILE GROUP 15;
ALTER DATABASE DROP STANDBY LOGFILE GROUP 16;
ALTER DATABASE DROP STANDBY LOGFILE GROUP 17;

以上各组在本次修复中均成功删除。

生产环境应逐条执行、逐条确认。若出现 ORA 错误，应立即停止后续操作，不得跳过异常继续批量删除。

不使用 Linux rm -rf 删除日志文件，也不能误删备库 Online Redo Group 1～8。

4.5 恢复备库日志应用

清理完成后，执行：

复制代码

ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT='AUTO' SCOPE=MEMORY;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

验证：

复制代码

SELECT DATABASE_ROLE, OPEN_MODE
FROM V$DATABASE;

SHOW PARAMETER standby_file_management;

结果：

复制代码

DATABASE_ROLE     OPEN_MODE
----------------- --------------------
PHYSICAL STANDBY  READ ONLY WITH APPLY

standby_file_management = AUTO

检查剩余 SRL：

复制代码

SELECT
    GROUP#,
    SEQUENCE#,
    STATUS,
    ROUND(BYTES/1024/1024) AS SIZE_MB
FROM V$STANDBY_LOG
ORDER BY GROUP#;

实际仅保留 Group 18～26，共 9 组，每组 1024 MB。

此时新 SRL 仍全部为 UNASSIGNED，说明日志组已创建，但尚未观察到新组承接实时 Redo。

因此继续验证新日志序列的 SRL 分配情况。

五、主库日志切换，验证新 SRL

5.1 检查主库当前 Redo Sequence

主库执行：

复制代码

SELECT
    THREAD#,
    GROUP#,
    SEQUENCE#,
    STATUS
FROM V$LOG
WHERE STATUS='CURRENT';

结果：

复制代码

THREAD#  GROUP#  SEQUENCE#  STATUS
-------  ------  ---------  -------
1        7       16         CURRENT

新 SRL 创建及旧 SRL 清理期间，主库一直处于 Sequence 16。

此时备库新 SRL 尚未分配使用。

5.2 切换前检查归档状态及空间

主库执行：

复制代码

SELECT DEST_ID, STATUS, ERROR
FROM V$ARCHIVE_DEST
WHERE DEST_ID IN (1,2);

两个目的地均为 VALID，没有报告错误。

Linux 检查：

复制代码

df -h /app /app/archivelog

实际 /app 文件系统总容量约 200 GB，剩余约 150 GB，使用率 26%，满足本次单次日志切换的空间条件。

5.3 执行一次主库日志切换

确认维护条件满足后，在主库 CDB$ROOT 执行：

复制代码

ALTER SYSTEM SWITCH LOGFILE;

本次只执行一次，使主库从 Sequence 16 进入 Sequence 17。

需要明确：

SWITCH LOGFILE 会切换当前 Online Redo，并触发相应归档处理。
日志切换后旧事务能够在备库查询到，不代表 Real-Time Apply 一定正常。
此次切换的目的，是观察新 SRL 能否承接新的 Redo 序列。

5.4 验证新 SRL 开始接收

在备库执行：

复制代码

SELECT
    GROUP#,
    SEQUENCE#,
    STATUS,
    ARCHIVED,
    ROUND(USED/1024/1024,2) AS USED_MB
FROM V$STANDBY_LOG
ORDER BY GROUP#;

实际结果中的关键数据：

复制代码

GROUP#  SEQUENCE# STATUS      USED_MB
------  --------- ---------- -------
18      17        ACTIVE         0.01
19       0        UNASSIGNED     0
20       0        UNASSIGNED     0
21       0        UNASSIGNED     0
22       0        UNASSIGNED     0
23       0        UNASSIGNED     0
24       0        UNASSIGNED     0
25       0        UNASSIGNED     0
26       0        UNASSIGNED     0

关键结果：新 SRL Group 18 已分配给 Sequence 17，状态由 UNASSIGNED 变为 ACTIVE，并出现 Redo 写入。

根据 Oracle 官方说明，当 SRL 为 ACTIVE 且 ARCHIVED=YES 时，表示该 SRL 当前正在被写入。

Oracle 文档

这证明新建的 SRL 已经能够正常投入接收工作。

至于新 SRL 为什么没有立即承接此前的 Sequence 16，本次没有取得完整 RFS Trace，不能将"必须日志切换才能生效"视为 Oracle 的固定规则。

本次可以确认的事实是：新日志序列开始后，SRL 成功分配并接收 Redo。

六、验证 ADG Real-Time Apply

6.1 验证原则

本次故障最明显的特点是：

主库一旦切换日志或完成归档，备库就能查询到数据。

因此，如果仅在日志切换后检查旧事务，无法区分归档应用和实时应用。

正确的方法是：

在当前新日志序列中提交事务，不再手动切换日志或强制归档，直接查询备库。

6.2 主库新增测试事务

在主库业务 PDB 执行：

复制代码

ALTER SESSION SET CONTAINER=TESTPDB;

首先确认测试主键未被使用：

复制代码

SELECT ID FROM ADGTEST WHERE ID=5;

然后执行：

复制代码

INSERT INTO ADGTEST(ID) VALUES(5);
COMMIT;

后续测试还产生了 ID=6。

说明：生产环境应使用独立测试表和经过批准的测试账号，不应随意修改真实业务表。

6.3 备库检查新增数据

在备库执行：

复制代码

ALTER SESSION SET CONTAINER=TESTPDB;

SELECT ID, TEST_TIME
FROM ADGTEST
ORDER BY ID;

测试查询结果包含：

复制代码

ID  TEST_TIME
--  -------------------------
1   06-OCT-26 05:18:08 PM
2   07-OCT-26 07:49:53 AM
3   08-OCT-26 02:27:57 PM
4   08-OCT-26 03:55:49 PM
5   08-OCT-26 04:27:19 PM
6   08-OCT-26 04:30:54 PM

其中 ID=4 是日志切换前已提交的事务，ID=5、ID=6 为后续新增的测试记录。

本次已经观察到新 SRL 投入使用及新增数据同步的积极结果。

正式生产验收还应确认测试期间没有发生新的自动日志切换或归档完成事件，避免把归档应用误判成实时应用。

6.4 检查最终同步状态

主库检查当前日志序列：

复制代码

SELECT
    THREAD#,
    SEQUENCE#,
    STATUS
FROM V$LOG
WHERE STATUS='CURRENT';

备库检查传输和应用延迟：

复制代码

SELECT
    NAME,
    VALUE,
    TIME_COMPUTED,
    DATUM_TIME
FROM V$DATAGUARD_STATS
WHERE NAME IN ('transport lag','apply lag');

备库检查归档缺口：

复制代码

SELECT *
FROM V$ARCHIVE_GAP;

备库检查 SRL 使用：

复制代码

SELECT
    GROUP#,
    SEQUENCE#,
    STATUS,
    ARCHIVED,
    ROUND(USED/1024/1024,2) AS USED_MB
FROM V$STANDBY_LOG
ORDER BY GROUP#;

最终应确认：

验收项目	合格要求
主库状态	PRIMARY / READ WRITE
备库状态	PHYSICAL STANDBY / READ ONLY WITH APPLY
SRL	当前日志序列正常分配到有效 SRL
Real-Time Apply	新事务不依赖日志切换即可在备库查询
Transport Lag	符合业务约定阈值
Apply Lag	符合业务约定阈值
Archive Gap	无未解决归档缺口
Alert Log	无新增影响传输或应用的严重错误

Oracle 官方说明，Real-Time Apply 能够直接应用正在写入当前 SRL 的 Redo，而无需等待该日志完成归档。

Oracle 文档

七、生产环境注意事项

7.1 ADG 正常启动，不代表实时同步正常

不能只凭：

复制代码

READ ONLY WITH APPLY

就认为 ADG 没有问题。

生产巡检至少需要结合数据库角色、RFS、MRP、SRL、传输延迟、归档缺口及事务同步测试综合判断。

7.2 SRL 必须同时检查元数据和物理文件

本次故障最有价值的发现是：

数据库中有 SRL 记录，但 Linux 下没有实际文件。

因此，检查 V$STANDBY_LOG 后，还应通过 V$LOGFILE 获取文件路径，并在操作系统中核实实际文件存在性。

这比单纯检查 UNASSIGNED 更能准确定位文件问题。

7.3 ASYNC 不是实时同步异常的原因

本次采用：

复制代码

PROTECTION_MODE = MAXIMUM PERFORMANCE
TRANSMIT_MODE   = ASYNCHRONOUS

属于合理的 Data Guard 配置组合。

ASYNC 不等于归档同步，也不意味着无法执行 Real-Time Apply。

因此，遇到本次类似故障时，不应首先尝试修改为 SYNC，更不应该在未评估事务提交性能和业务 RPO 的情况下调整 Data Guard 保护模式。

7.4 备库 Online Redo 仍需单独整改

本次排查中，备库旧 Online Redo Group 1～8 还出现过：

复制代码

ORA-19527
ORA-00313
ORA-27037

对应的原有 Online Redo 文件路径同样存在访问异常。

这与本次已修复的 SRL Group 9～17 不是同一个问题。

当前 SRL 接收能力恢复，并不代表备库 Online Redo 文件已经修复。

正式开展 Switchover 或 Failover 演练前，应单独检查并治理这些 Online Redo 日志组，避免角色切换后出现日志文件不可用问题。

处理时不得直接删除 Online Redo 或盲目执行 CLEAR LOGFILE，应按日志组状态制定专门维护方案。

八、故障总结

项目	本次实际情况
故障现象	主库提交后备库无法实时查询，归档后才能同步
数据库状态	主备角色及 Redo Apply 服务正常
Redo 传输方式	ASYNC
关键故障证据	SRL 物理文件缺失，出现 ORA-00313、ORA-27037
关联错误	No SRLs available for T-1
故障日志组	Group 9～17
修复措施	创建新 SRL，清理旧日志组
新建日志组	Group 18～26，共 9 组，每组 1024 MB
新日志分配	Group 18 / Sequence 17 / ACTIVE
数据验证	新增测试记录已出现在查询结果中
遗留风险	备库旧 Online Redo Group 1～8 文件异常

最终结论

本次 Oracle 19c ADG 实时同步异常的主要原因，是**备库 Standby Redo Log 的控制文件记录与物理文件不一致，原有 SRL 文件缺失，**导致实时 Redo 接收链路无法正常使用这些日志组。

通过新建有效 SRL、清理失效日志组，并在新的 Redo Sequence 中验证接收状态，确认新的 SRL 已成功投入使用。

本次故障也说明：

归档日志能够正常同步，不代表 Data Guard Real-Time Apply 一定正常。

今后遇到"主库提交事务后备库查询不到，只有归档后才能同步"的问题，建议按照以下顺序排查：

数据库状态 → 日志传输 → RFS/MRP → SRL 状态 → SRL 物理文件 → Alert Log → 修复及事务验证。

避免一开始就重启数据库、反复强制归档，或者盲目修改 Data Guard 保护模式。

九、Oracle 官方参考文档

Oracle 19c --- Creating a Physical Standby Database
Oracle 19c --- Managing Physical Standby Databases
Oracle 19c --- Apply Services / Real-Time Apply
Oracle 19c --- V$STANDBY_LOG