oracle rac中需逐节点检查归档模式、路径配置、归档日志生成及线程归属：用select log_mode from v$database确认全局一致；show parameter log_archive_dest_1与v$archive_dest查本地配置与状态；v$archived_log验证各节点thread#日志连续性；归档归属由thread#决定，备份须覆盖所有线程。
检查单节点是否处于归档模式
oracle rac 中每个实例独立维护自己的归档状态，不能只查一个节点就下结论。最直接的方式是连到任一实例后执行：
archive log list。但要注意，该命令输出中的
database log mode 行只反映当前实例所在数据库的归档模式（archive mode 或 no archive mode），而 automatic archival 和 archive destination 是实例级配置，可能与其他节点不一致。更可靠的做法是查动态性能视图：
SELECT log_mode FROM v$database;。这个值在所有节点上必须一致——RAC 所有实例共享同一份控制文件，所以
v$database.log_mode 在所有节点查询结果应完全相同。若出现差异，说明控制文件异常或某节点未正常加载。确认各节点归档路径与实际写入位置
RAC 中归档日志默认由本地实例生成并写入本地 LOG_ARCHIVE_DEST_1（或其它显式配置的归档目标），不是自动跨节点分发。这意味着：节点1的归档日志不会自动出现在节点2的归档目录里，除非你手动配置了远程归档（如 LOG_ARCHIVE_DEST_2 指向另一节点的 ASM 磁盘组或 NFS 路径）。
查每个节点的实际归档配置：
SHOW PARAMETER log_archive_dest_1。重点关注三类值：
-
LOCATION后的路径（如+FRA、/u01/arch） - 是否含
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)等限定 - 是否启用
REOPEN或设了DELAY
v$archive_dest 查实时状态：SELECT dest_id, status, target, destination, error FROM v$archive_dest WHERE status != 'INACTIVE';。特别注意
status = 'ERROR' 的条目——常见于权限不足、磁盘满、ASM 别名不存在等，这类错误往往只在出问题的节点上可见。验证归档日志是否真实生成且连续
仅看参数和状态还不够，得确认归档日志确实被创建出来，并且序列号不跳变。在每个节点分别运行：
SELECT thread#, sequence#, first_time, next_time, applied FROM v$archived_log ORDER BY sequence# DESC FETCH FIRST 5 ROWS ONLY;。关键点：
-
thread#应与该节点实例号一致（通常节点1对应thread#=1，节点2对应thread#=2） - 各节点的
sequence#序列应各自连续增长，不要求跨节点对齐 -
applied = 'YES'仅对物理备库有意义；RAC 主库本体没有这个概念，此处恒为NO或空
v$archived_log 查询为空，或最近几条 next_time 停滞超过 10 分钟，大概率归档进程（ARCn）卡住或被禁用。跨节点归档归属的实质是线程隔离
RAC 归档日志的“归属”本质由 thread# 决定，而非物理节点名。每个实例启动时绑定唯一 thread，重做日志按线程分组，归档也按线程生成。因此：
- 节点1生成的归档日志，
thread#=1，哪怕写入共享 ASM 目录，逻辑上仍属于线程1 - 恢复时需同时应用线程1和线程2的归档，缺一不可
- 备份脚本若只扫某个节点的本地路径，会漏掉其他线程的日志——必须统一从共享存储（如
+FRA）扫描所有thread#的归档
host_name 区分节点，但在归档路径中真正起作用的是 thread# 和 sequence#。一旦误以为“节点2的归档在节点2目录下”，就可能漏备份或误删。
