不支持。Oracle Zero Downtime Migration（ZDM）不支持直接迁移 Oracle RAC 集群架构，仅允许以单实例模式迁移 RAC 中的一个活跃数据库实例，需先关停其余节点、禁用集群参数并清理 RAC 特有配置，迁移后依赖云平台自身高可用机制替代 RAC 功能。
Oracle RAC 迁移到云是否支持 ZDM？
不支持直接迁移 rac 架构本身。oracle zero downtime migration（zdm）不支持将源端 oracle rac 集群整体迁移到目标云上的另一个 rac 环境，尤其在 azure、google cloud 或 oci 的标准数据库服务中 —— 因为这些平台的托管数据库服务（如 oci base database service、od@a exadata、oracle database@gcp）均不提供用户可管理的 rac 部署选项。
你实际能做的，是把 RAC 作为高可用逻辑架构剥离，只迁移其承载的数据库实例（即单个 CDB/PDB），并依赖目标云平台自身的高可用机制（如 Data Guard、Exadata 自动故障转移、自动备份恢复等）替代原 RAC 的节点级容错能力。
- ZDM 官方明确要求源库为单实例或 RAC 中的单个数据库实例（需停用其他节点，或仅连接一个 active instance 进行评估和作业启动）
- 若强行在 RAC 多节点环境下运行
zdmcli，会因ORACLE_SID解析冲突、集群注册信息干扰、ASM 实例识别异常等问题导致prereq检查失败或迁移作业中断 - OCI 上的 Exadata Cloud Service 支持 RAC，但仅限于“客户自管型”裸金属部署（非托管服务），此时 ZDM 仍不能自动化部署 RAC Grid Infrastructure，需手动配置 GI + DB 软件栈
迁移前必须做的 RAC 拆解动作
要把 RAC 数据库“变成 ZDM 可接受的源”，不是靠改参数，而是靠收敛访问路径和清理环境状态：
- 确认当前 RAC 中只有一个实例处于
OPEN状态，其余实例全部SHUTDOWN IMMEDIATE；ZDM 不识别srvctl管理的集群状态，只认sqlplus / as sysdba能连上的那个ORACLE_SID - 禁用所有跨实例的高级特性：关闭
Global Enqueue Services (GES)相关等待监控（如gcs log flush）、停用Oracle RAC One Node模式、卸载ACFS（如果数据文件未存于 ASM） - 检查并清理
v$database中的DB_UNIQUE_NAME和INSTANCE_NAME：ZDM 依赖它们生成 Data Guard 配置，若多个实例共用同一DB_UNIQUE_NAME，会在目标端触发 DG broker 冲突 - 导出关键 RAC 元数据供后续验证：运行
crsctl query crs activeversion、srvctl config database -d <db_name>、select * from gv$instance;，确保迁移后能在云上重建必要的服务名与负载均衡策略
ZDM 迁移时如何处理 RAC 特有对象？
RAC 本身不产生用户表或索引，但它引入的系统级对象和依赖项容易在迁移后失效：
-
DBMS_SCHEDULER中定义的 job 若绑定到特定INSTANCE_ID或使用INSTANCE_STICKINESS，迁移后会卡在BROKEN状态；需在迁移前统一改为NULL或显式指定INSTANCE_NAME为目标云单实例名 - 使用
DBMS_SERVICE创建的服务（如sales_svc）在目标端不会自动重建；ZDM 不同步srvctl add service配置，需在切换后手动执行dbms_service.create_service并start_service - 若应用通过 SCAN IP + VIP 连接 RAC，迁移后必须替换为云上提供的单点连接串（如 OCI 的
tnsnames.ora中的CONNECT_DATA=(SERVICE_NAME=...)），否则客户端持续解析失败 - AWR 报告中的
global cache cr block receive time类指标在单实例目标端无意义，迁移后应停用相关监控项，避免误报
为什么 ZDM 日志里总出现 “RAC detected but not supported”？
这不是警告，是 ZDM 的主动拦截机制 —— 它在 prereq 阶段读取 v$active_instances 和 gv$parameter 中的 cluster_database 值，一旦发现值为 TRUE 且 gv$instance 行数 > 1，就立即终止作业并输出该错误。
绕过它不是修改 ZDM 源码或加 --force 参数（ZDM 没有该参数），而是让环境“看起来不是 RAC”：
- 在启动 ZDM 前，用
srvctl stop instance -i <inst2> -d <db_name>彻底关停次要实例，再确认ps -ef | grep pmon只剩一个ora_pmon_<inst1> - 临时修改
init.ora或 SPFILE，设cluster_database=FALSE，重启唯一存活实例（注意：这会导致 CRS 认为该实例脱管，但 ZDM 不关心 CRS 状态） - 确保
$ORACLE_HOME/network/admin/tnsnames.ora中没有指向其他节点的别名；ZDM 解析监听器时若发现多个SID_LIST条目，也会触发校验失败 - 若使用 Oracle 19c+，检查是否启用了
application continuity：ZDM 不兼容该特性，迁移前需执行ALTER SYSTEM SET application_continuity = OFF;
真正难的不是让 ZDM 跑起来，而是让业务在单实例云数据库上跑得和原来 RAC 一样稳 —— 这需要重审连接池超时、事务重试逻辑、后台 job 分布策略，而不是盯着 zdmcli migrate 命令是否成功。
