备库不生效是因为主备spfile完全独立；需查show parameter spfile确认备库用spfile还是pfile，再通过create pfile from spfile和create spfile from pfile安全同步，并重启验证。
主库改了 spfile 参数，备库不生效？不是同步没配好，是备库压根没读你的主库配置——dg 环境下主备的 spfile 完全独立，连路径、格式、dbid 都不通用。
怎么确认备库到底在用 spfile 还是 pfile？
别猜，直接查：
- 能连上备库（哪怕只是
NOMOUNT）：执行SHOW PARAMETER spfile，返回非空值说明在用spfile；返回空值说明当前用的是pfile - 连不上？去
$ORACLE_HOME/dbs/下看文件：存在spfile<sid>.ora</sid>且没被禁用，优先级高于init<sid>.ora</sid>；但若启动时加了pfile=xxx参数，则强制走pfile - 常见误判：
spfile文件权限不对（比如属主不是oracle、不可读），也会报ORA-01078，但日志里不会明说
为什么不能直接拷贝主库 spfile 到备库？
二进制硬拷贝会出 ORA-01261 或 ORA-01262——spfile 里嵌了主库的 DBID、CONTROLFILE_TYPE 等唯一标识，备库加载时校验失败。
- 正确做法分两步：
主库执行：CREATE PFILE='/tmp/init_primary.ora' FROM SPFILE
备库执行：CREATE SPFILE FROM PFILE='/tmp/init_primary.ora'（路径必须在备库本地可访问） - 关键点：备库的
spfile必须由本地 SQL 命令重建，不能用scp或cp覆盖 - 如果参数只该主库用（如
audit_trail），要在备库生成的pfile中显式注释掉或设为FALSE，否则会被继承
哪些参数改了会导致备库 MRP0 挂起？
不是所有参数都能同步。以下几类一动就卡在 APPLYING_LOG 或直接报错：
-
db_block_size、compatible、db_name：主备值必须严格一致，否则备库启动失败 -
log_archive_dest_2（备库上指向主库的那个）：不能删、不能DISABLE，否则归档传输中断 -
standby_file_management：设为AUTO是常规操作，但如果主库建表空间时备库对应路径不存在，MRP0 会卡住 - 验证方法：改完主库后，立刻在备库查
SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY；若MRP0的STATUS是WAIT_FOR_LOG或ERROR，大概率是参数冲突
修改后怎么验证真正生效？
SHOW PARAMETER 显示的是内存中当前值，不代表 spfile 已持久化，更不代表备库已加载。
- 尤其带
DEFERRED属性的参数（如optimizer_adaptive_statistics），主库改完也不立即生效 - 必须重启备库，并确认其启动时实际加载的是你刚重建的
spfile（查startup日志里的 “using parameter file” 行） - 最后再查
V$PARAMETER和V$SPPARAMETER对比：前者是运行值，后者是spfile持久值，两者一致才算真正落地
最常被忽略的其实是“备库是否真在用你重建的 spfile”——哪怕你 CREATE SPFILE FROM PFILE 成功了，如果 $ORACLE_HOME/dbs/init<sid>.ora</sid> 里没写对 SPFILE=xxx 路径，或者启动时指定了错误的 pfile，它还是会悄悄退回到旧配置。
