standby redo log组数不足会导致mrp无法实时应用日志、transport_lag持续上涨但status仍显示valid；最小组数为（online redo log组数＋1）×thread#数量，rac环境必须为每个thread显式添加且验证文件存在、大小匹配、状态为unassigned。
Standby Redo Log数量不足会导致MRP进程无法实时应用日志，transport_lag持续上涨但V$ARCHIVE_DEST_STATUS.STATUS仍显示VALID——这是最典型的“假正常”故障，必须立刻补足组数并验证THREAD绑定。
怎么算够不够：先查主库online redo log组数和THREAD数
缺组不是靠猜的。单实例环境THREAD#恒为1，RAC必须查清楚有几个线程：
-
SELECT THREAD#, INSTANCE FROM GV$INSTANCE—— 看主库实际跑几个实例 -
SELECT GROUP#, BYTES FROM V$LOG—— 看每组online redo log大小（单位字节） -
SELECT COUNT(*) FROM V$LOG—— 看online redo log总组数
Standby Redo Log最小组数 = (online redo log组数 + 1) × THREAD#数量。比如主库3组+RAC双实例，就得至少(3+1)×2=8组；只建了4组，就必然卡住。
RAC环境下漏配THREAD是最高频的致命错误
在备库执行ALTER DATABASE ADD STANDBY LOGFILE时，不带THREAD子句默认只绑THREAD 1。主库THREAD 2产生的归档到了RFS手里，却无对应SRL可写，RFS直接挂起，但状态不报错。
- 必须显式为每个THREAD单独加：
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 200M、ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 200M - 加完立刻查：
SELECT GROUP#, THREAD#, STATUS FROM V$STANDBY_LOG，确认每组THREAD#值正确且STATUS为UNASSIGNED（不是INVALID） - 别信“执行成功就完事”——
V$STANDBY_LOG里没出现对应THREAD行，等于没加
路径、权限、文件真实存在，三者缺一不可
手工指定路径时，ALTER DATABASE ADD STANDBY LOGFILE语句看似成功，但OS层文件根本没生成，MRP启动直接报ORA-00313。
- 建之前先
mkdir -p /u02/oradata/STBY/，再chown oracle:oinstall /u02/oradata/STBY/ - 建完立刻
ls -l /u02/oradata/STBY/standbyredo*.log，确认文件存在、属主正确、大小匹配 -
DB_CREATE_FILE_DEST对SRL无效，别依赖它自动创建 - 主备目录结构不一致时，路径必须手改，不能直接复制主库SQL
补完之后必须验证MRP是否真在apply
加完SRL只是第一步。MRP能否跑起来，要看三个点是否全部满足：
- 主库侧：
SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST WHERE DEST_ID = 2，ERROR列必须为空 - 备库侧：
SELECT PROCESS, STATUS, CLIENT_PROCESS, SEQUENCE# FROM V$MANAGED_STANDBY，看到MRP0且STATUS = APPLYING_LOG - 延迟指标：
SELECT NAME, VALUE FROM V$DATAGUARD_STATS WHERE NAME = 'transport_lag'，值应稳定在秒级而非小时级
最容易被忽略的是：SRL大小必须≥主库online redo log单组字节数，否则MRP一启动就报ORA-00354——这个错误不会出现在加SRL阶段，而是在ALTER DATABASE RECOVER MANAGED STANDBY DATABASE时才暴露。
