备库收不到Thread 2归档，大概率因主库RAC节点归档路径未真正共享，需逐节点验证log_archive_dest_1路径一致性、NFS/ASM挂载状态及FAL服务定位能力，并通过ALTER SYSTEM ARCHIVE LOG CURRENT强制将Thread 2新归档写入共享路径。
备库收不到thread 2归档，大概率不是网络或密码文件问题，而是主库两个节点的归档路径根本没共享——thread 2的归档文件物理上压根没传到备库能访问的位置。
先确认主库归档路径是否真正共享
很多DBA看到log_archive_dest_1里写了NFS或ASM路径，就默认“所有节点都往这写”，但实际可能只是配置了，没生效。必须逐节点查：
- 在节点1执行：
SELECT VALUE FROM V$PARAMETER WHERE NAME = 'log_archive_dest_1';，记下路径 - 立刻切到节点2，用
export ORACLE_SID=rac2再查一遍，看路径是否完全一致 - 如果路径不同（比如一个是
/nfs/arch/rac1，另一个是/nfs/arch/rac2），那Thread 2归档就只存在rac2本地目录下，备库连不到 - 用
asmcmd lsdg（ASM）或df -h（NFS）验证该路径是否真被两个节点同时挂载且可写，别信archive log list输出
检查备库FAL服务能否定位Thread 2归档
FAL（Fetch Archive Log）进程靠V$ARCHIVE_DEST_STATUS里的DESTINATION和STATUS找归档。如果Thread 2归档不在主库统一归档路径里，FAL就找不到：
- 在备库查：
SELECT DEST_ID, DESTINATION, STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2; - 如果
STATUS是VALID但ERROR列有内容，重点看是不是ORA-19505（找不到文件）或ORA-27037（路径不可访问） - 在主库节点2上手动
ls -l对应归档路径，确认Thread 2的thread_2_seq_*.arc文件是否存在、权限是否为oracle:oinstall - 若路径是NFS，还要检查挂载选项是否含
nfsvers=4.1,hard,intr，缺了hard会导致部分I/O静默失败
强制让Thread 2归档进入共享路径的补救操作
如果已确认节点2归档路径孤立，又不能停库重配，可用ALTER SYSTEM ARCHIVE LOG CURRENT触发一次手工归档，并指定目标：
- 先在节点2上：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=+ARCH' SCOPE=BOTH SID='rac2';（假设ASM是共享的） - 再执行：
ALTER SYSTEM ARCHIVE LOG CURRENT;，此时新生成的Thread 2归档会落进ASM，备库FAL能直接拉取 - 注意：此操作不清理旧归档，需后续用RMAN在节点2上单独
DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-1' THREAD 2，避免磁盘撑爆 - 长期方案必须统一
log_archive_dest_1配置，且加SID='*'确保集群内所有实例生效
最常被忽略的是：即使用了NFS，若两个节点挂载时用了不同UID或没开noac选项，Linux层就会拒绝跨节点写入——文件看似存在，实则是各自写了自己的副本，备库永远只能看到Thread 1的那份。
