LOG_ARCHIVE_DEST_n 与 LOG_ARCHIVE_DEST/LOG_ARCHIVE_DUPLEX_DEST/DB_RECOVERY_FILE_DEST 互斥，且 VALID_FOR 和 DB_UNIQUE_NAME 配置错误会导致静默归档失败。
log_archive_dest_n 和 log_archive_dest 不能共存，否则数据库启动失败或归档静默中断——这是 oracle 的硬性限制，不是配置疏忽，而是内核级互斥机制。
为什么 ALTER SYSTEM SET log_archive_dest_1 会报 ORA-16019
错误直接表明：当前实例中 LOG_ARCHIVE_DEST 参数非空（哪怕只是空格），而你又试图启用 LOG_ARCHIVE_DEST_1。Oracle 在参数加载阶段就拒绝这种组合，不等归档发生就报错。
-
SHOW PARAMETER log_archive_dest返回值不是''或' '，就说明冲突已存在 - 即使只设了
LOG_ARCHIVE_DEST_2，只要LOG_ARCHIVE_DEST有值，LOG_ARCHIVE_DEST_1就无法生效 - 注意：
LOG_ARCHIVE_DUPLEX_DEST同样与LOG_ARCHIVE_DEST_n互斥，不能忽略
如何彻底清除 LOG_ARCHIVE_DEST 冲突
光用 ALTER SYSTEM SET log_archive_dest='' 不够——内部缓存仍可能保留旧路径引用，必须重启才能清空状态。
- 执行
ALTER SYSTEM SET log_archive_dest='' SCOPE=BOTH - 确认
SHOW PARAMETER log_archive_dest输出为''（不是 NULL，是空字符串） - 必须重启数据库：
SHUTDOWN IMMEDIATE→STARTUP，否则V$ARCHIVE_DEST_STATUS中仍可能显示 INACTIVE - 若使用 spfile，修改后建议
CREATE SPFILE FROM PFILE再重启，避免 pfile 缓存残留
VALID_FOR 和 DB_UNIQUE_NAME 错误为何查不到日志
这两类问题不会触发 alert.log 报错，但会导致归档“发出去却没人收”，属于静默失败。
-
VALID_FOR=(STANDBY_LOGFILES,PRIMARY_ROLE)这种写法在主库上永远不触发——主库没有 STANDBY_LOGFILES，路径 STATUS 直接为 INACTIVE -
DB_UNIQUE_NAME=mid_std_db必须和备库V$DATABASE.DB_UNIQUE_NAME完全一致（大小写、下划线、拼写一个字符都不能差） - 验证命令：
SELECT DEST_ID, STATUS, VALID_TYPE, VALID_ROLE, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2，重点看 STATUS 是否为 VALID、ERROR 是否为空 - 如果 ERROR 是
ORA-16664或ORA-16047，基本就是DB_UNIQUE_NAME不匹配或LOG_ARCHIVE_CONFIG中漏写了该名
DB_RECOVERY_FILE_DEST 也参与互斥链
这个参数常被忽略，但它和 LOG_ARCHIVE_DEST 是同一层级的互斥项，一旦启用闪回区，再设本地归档路径就会失败。
-
ALTER SYSTEM SET db_recovery_file_dest='+datadg'成功后，LOG_ARCHIVE_DEST必须为空，否则报ORA-16018 - 如果要用
LOG_ARCHIVE_DEST_n指向 ASM（如SERVICE=std1），db_recovery_file_dest可以共存；但指向本地路径时，二者不可并存 - 动态修改受限：10g/11g 中，若已启用
db_recovery_file_dest，LOG_ARCHIVE_DEST_n的LOCATION属性无法在线修改，必须重启
最易被忽略的是 VALID_FOR 的角色与日志类型组合是否真实存在——主库没有 STANDBY_LOGFILES，备库没有 ONLINE_LOGFILES，写错就等于没配；DB_UNIQUE_NAME 看似简单，但大小写敏感且不报错，只能靠 V$DATABASE 对比确认。
