ALTER DATABASE ADD STANDBY LOGFILE 必须手动在备库执行，需严格匹配主库Online Redo Log大小、组数及线程数，且添加前须停止MRP并确认MOUNT状态，否则报ORA-01126；路径权限、命名规范及ASM磁盘组可用性亦需严格校验。
ALTER DATABASE ADD STANDBY LOGFILE 不会自动同步主库变更，必须手动在备库执行，且大小、组数、线程匹配稍有偏差就会导致日志应用卡住或报 ORA-00313、ORA-16191。
查主库Online Redo Log最大尺寸和组数
V$LOG 和 V$LOGFILE 是唯一可信来源，不能凭记忆或配置文件估算。
- 最大尺寸决定所有 STANDBY LOGFILE 的 SIZE 值：
SELECT MAX(BYTES) FROM V$LOG;- 组数决定备库至少要建多少组 SRL：
SELECT COUNT(*) FROM V$LOG;- 单实例主库默认
THREAD 1；RAC 主库需对每个启用的 THREAD 单独配足 SRL（例如 THREAD 1 和 THREAD 2 各有 3 组 online log，则备库至少需 2 × (3 + 1) = 8 组 SRL）
- STATUS 为 CURRENT 或 ACTIVE 的组说明日志切换已发生，SRL 必须在此前就位，否则 RFS 进程会挂起在 WAIT_FOR_LOG备库添加SRL前必须停MRP并确认MOUNT状态
物理备库即使处于MOUNT 状态，只要 MRP 进程正在运行（RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE），直接执行 ALTER DATABASE ADD STANDBY LOGFILE 就会报 ORA-01126。
- 先停恢复：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
- 再确认实例状态：
SELECT STATUS FROM V$INSTANCE;结果必须是
MOUNTED
- 添加完成后才能重启应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
- 别跳过这步：MRP 活跃时加 SRL 失败率接近 100%，不是权限或路径问题，是 Oracle 内部锁机制限制
路径、权限、命名这些细节最容易引发ORA-19502/ORA-27040
Oracle 创建 SRL 时会立即写入 header 块，哪怕文件为空，所以失败几乎都卡在 OS 层。 - 目标目录必须提前创建，且 Oracle 用户有write + execute 权限（chmod 750，不是 755）
- 路径中避免空格、中文、括号；文件名建议用 srl_04.log 这类纯英文+数字格式
- ASM 环境必须指定已 mounted 的 diskgroup，且 USABLE_FILE_MB > 0：
ALTER DATABASE ADD STANDBY LOGFILE '+DG_FRA' SIZE 200M;
- 不要用主库归档路径或闪回区放 SRL——I/O 竞争会导致 RFS 写入延迟，进而拖慢整体同步
主库也该配SRL，但目的完全不同
主库加STANDBY LOGFILE 不是为了接收日志（它不收），而是为角色切换后立刻承担备库职责。
- 主库 SRL 大小和组数要求与备库一致（同样查 V$LOG 确定）
- 主库可随时添加，无需停任何进程，也不依赖 MOUNT 状态
- 但主库 SRL 路径必须本地可写，且不能和自身 online redo 或归档路径冲突
- 如果只在备库配、主库不配，切换后第一次日志传输可能失败，因为新主库（原备库）没有 SRL 接收来自原主库（现备库）的日志
SRL 不是“配了就完事”的一次性操作。主库增删 online log 组、RAC 扩容线程、调整日志尺寸——这些变更都会立刻打破 SRL 匹配关系。最危险的是“以为加过了，其实没对齐”，等切换时才暴露，那时已经晚了。
