如何配置RAC环境下的RMAN备份通道_ALLOCATE CHANNEL针对不同节点-Oracle-PHP中文网

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 如果只在主节点执行，其他节点归档不会被删，磁盘迟早爆掉。这事容易被忽略，得单独配定时任务或在备份后加跨节点清理步骤。