RMAN在RAC中ALLOCATE CHANNEL默认只连一个节点，因其通道分配严格绑定于当前CONNECT TARGET所连接的实例；需为每个节点显式执行CONNECT TARGET并ALLOCATE CHANNEL，且服务名须指向具体实例而非SCAN。
为什么 ALLOCATE CHANNEL 在 RAC 中会只连一个节点？
默认情况下，rman 连接的是你当前登录的实例（比如用 connect target / 连到 node1），所有 allocate channel 都会在这个实例上下文中执行。即使你在 node2 上跑备份脚本，只要 rman session 没切到它，通道就还是落在最初连接的那个节点上——不是 rac 不支持多节点通道，而是你没显式指定目标实例。
常见错误现象：RMAN-06004: ORACLE error from target database: ORA-12514: TNS listener does not currently know of service requested，或者备份速度卡在单节点吞吐，V$SESSION 里看不到其他节点上有 RMAN 的 BACKUP 类型会话。
- 必须用
CONNECT TARGET显式连接到每个要启用通道的实例，不能依赖本地连接或 SCAN 名自动分发 - 每个
ALLOCATE CHANNEL必须紧跟在对应实例的CONNECT TARGET之后，RMAN 不会跨 connect 复用通道配置 - 如果用 catalog，确保 catalog 数据库能被所有 RAC 节点通过网络访问，否则
REGISTER DATABASE或RESYNC CATALOG可能失败
怎么写多节点 ALLOCATE CHANNEL 脚本？
核心是：为每个节点单独开一个 RMAN session，或者在一个脚本里用 CONNECT TARGET 切换上下文。推荐后者，避免并发控制混乱。
示例（双节点）：
RUN {
CONNECT TARGET sys/oracle@racdb1;
ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT '/backup/node1/%U';
CONNECT TARGET sys/oracle@racdb2;
ALLOCATE CHANNEL c2 DEVICE TYPE DISK FORMAT '/backup/node2/%U';
BACKUP DATABASE PLUS ARCHIVELOG;
RELEASE CHANNEL c1;
RELEASE CHANNEL c2;
}
-
racdb1和racdb2是 tnsnames.ora 里分别指向不同实例的服务名，不能共用同一个 SCAN 服务（如racdb），否则仍可能路由到同一节点 - 通道名（
c1,c2）必须唯一，不能在同一个 RUN 块里重复使用相同名字，否则报RMAN-06002: command not legal here - 不建议用
PARALLELISM替代显式分配——它只控制单个实例内通道数，不会跨实例
CONFIGURE CHANNEL 能不能设成全局生效？
不能。RMAN 的 CONFIGURE CHANNEL 是实例级持久化设置，只对后续在该实例上启动的 RMAN session 生效。你在 racdb1 上 CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/path1/%U'，对 racdb2 完全无影响。
- 想统一管理，得在每个节点上分别执行一遍
CONFIGURE，且路径、磁盘权限、归档日志位置都要提前对齐 - 若用 FRA（Fast Recovery Area），注意
DB_RECOVERY_FILE_DEST参数在各节点必须指向本地路径（不能共享 NFS，除非确认 Oracle 支持且已打补丁），否则BACKUP ARCHIVELOG ALL可能漏掉其他节点的归档 -
SHOW ALL输出里看到的 channel 配置，永远只反映当前连接实例的设置，别误以为是集群范围配置
备份时节点宕机或网络中断怎么办？
RMAN 本身不提供跨节点故障自动转移。一旦某个 ALLOCATE CHANNEL 对应的实例不可达，整个 RUN 块会中止，已分配的通道不会自动释放，残留会话可能占用资源。
- 运行前务必用
tnsping racdb1和tnsping racdb2确认连通性；更稳妥的做法是在脚本开头加sql "SELECT INSTANCE_NAME FROM V$INSTANCE"校验实际连接的是哪个实例 - 不要把所有通道都绑在同一个 RUN 块里——拆成多个独立 RUN，每个只管一个节点，失败不影响其他节点备份
- 检查
V$RMAN_OUTPUT或 RMAN 日志中的channel c1: starting piece行，确认每个通道确实开始写入，而不是卡在waiting for server process
最麻烦的其实是归档日志的分布和清理逻辑——每个节点的归档路径独立，但 DELETE INPUT 如果只在主节点执行，其他节点归档不会被删，磁盘迟早爆掉。这事容易被忽略，得单独配定时任务或在备份后加跨节点清理步骤。
