oracle 19c仍支持rac one node，但不再提供独立安装选项，而是整合进标准rac流程，需通过srvctl显式配置为单实例模式运行，并依赖clusterware实现高可用与在线迁移。
Oracle 19c RAC 并没有“取消对 RAC One Node 的支持”——这个说法本身是错的。RAC One Node 在 Oracle 19c 中仍然受支持，但不再作为独立安装选项提供，而是被整合进标准 RAC 安装流程中，且必须通过 srvctl 显式配置为单实例模式运行。
这导致很多 DBA 误以为“不支持了”，实际是部署路径变了，不是功能废弃。
为什么找不到 RAC One Node 的独立安装界面？
从 12.1 开始，Oracle 就移除了图形化安装器（OUI）中单独的 “RAC One Node” 选项。19c 延续这一设计，原因很直接：
- 底层技术栈已统一：RAC One Node 和标准 RAC 共享同一套 Clusterware、ASM（Flex ASM）、OCR/Voting Disk 和服务管理模型；
- 运维一致性优先：DBA 用一套命令（
srvctl）管理单实例集群或全量 RAC，避免两套工具链； - 许可逻辑未变：只要持有 Oracle RAC 许可，RAC One Node 功能就可用，无需额外授权。
如何在 19c 中正确启用 RAC One Node 行为？
关键不是“安装时选它”，而是在数据库创建后，用 srvctl 把服务约束到单节点，并禁用跨节点故障转移能力：
- 创建数据库时仍走标准 RAC 流程（
dbca -silent -responseFile或 DBCA 图形界面），确保使用 ASM 存储和集群注册； - 创建完成后，执行：
srvctl modify database -d <db_name> -n <node_name></node_name></db_name>，将数据库绑定到指定节点； - 停掉另一节点上的实例：
srvctl stop instance -d <db_name> -i <inst_name_on_other_node></inst_name_on_other_node></db_name>； - 验证状态：
srvctl status database -d <db_name></db_name>应只显示一个 ONLINE 实例； - 如需计划内迁移，用：
srvctl relocate database -d <db_name> -n <target_node></target_node></db_name>，这才是 RAC One Node 的核心能力。
哪些场景下会误判为“不支持”？
常见踩坑点集中在配置和验证环节：
- 用
crsctl stat res -t看到多个ora.<db>.db</db>资源处于 OFFLINE，并不表示失败——RAC One Node 本就不该在多节点上同时启动实例； - 没调用
srvctl modify database -n，却期望数据库自动限制在单节点，结果触发默认 RAC 行为（双实例并行）； - 误把 Oracle Linux 8/9 对 ACFS 的支持限制（仅限 RU 19.21+）当成 RAC One Node 不支持——这两者无直接关联；
- 在非 Oracle 官方认证的虚拟化平台（如未经测试的 KVM 配置）上部署，Clusterware 启动失败，归因为“RAC One Node 不兼容”，实则是私网心跳或 OCR 设备权限问题。
真正容易被忽略的是：RAC One Node 的高可用性依赖 Clusterware 的节点驱逐策略和 VIP 漂移机制，而不是实例数量。 即使只跑一个实例，只要集群层健康，故障时仍能自动拉起新实例——这点和传统单机 + Data Guard 有本质区别。配置错一步，就退化成“带集群壳的单机”，失去弹性迁移和滚动补丁能力。
