Oracle 11g RAC配置Restart实现非集群高可用

Oracle Restart与RAC：澄清一个常见的配置误区

在Oracle高可用领域，有一个问题时不时会被提出来：“怎样在Oracle 11g RAC中配置Oracle Restart？” 然而，这个问题的前提本身可能就存在偏差。简单来说，Oracle Restart并不是为RAC设计的，它只适用于单机环境。在真正的11g RAC架构中，OHASD和CRS已经接管了全部的高可用管理职责，Oracle Restart既不会启用，也无法与之共存。

Oracle Restart仅适用于单实例非集群环境，RAC中由CRS全权负责高可用管理；二者共用ohasd.bin但初始化参数与资源模型不同，RAC下crsctl stat res -t显示集群资源即表明已启用CRS模式。

如果你在RAC节点上看到了ohasd.bin进程，别误会，那只是Oracle高可用服务栈的一部分，并非Oracle Restart在运行。后者仅存在于“单实例 + Grid Infrastructure”这种非集群部署模式中。

为什么不能在RAC中配置Oracle Restart

要理解这一点，得先看看Oracle Restart的定位。它是Oracle 11g引入的一套轻量级高可用机制，目标场景非常明确：单主机、无共享存储、无集群通信需求的数据库部署。它的启动入口通常是/etc/init.d/ohasd脚本。

但在RAC环境下，情况就完全不同了。安装RAC后，这个启动脚本会被crsctl start crs所替代，并且ohasd会直接演进为完整的CRS栈。可以说，RAC从底层就建立在更强大的集群就绪服务之上。

• 架构冲突：RAC必须启用Cluster Ready Services，而它与Oracle Restart虽然共用ohasd.bin等二进制文件，但初始化参数和资源管理模型是两套完全不同的东西。
• 模式覆盖：当你执行crsctl check crs，如果看到返回CRS-4638: Oracle High A vailability Services is online，这就说明系统已经运行在完整的集群服务模式下，Oracle Restart的模式已经被覆盖了。
• 操作失败：如果试图在RAC节点上手动执行类似srvctl add database -d ... -r SINGLE的命令，或者去修改ora..db资源的类型，结果往往是资源注册失败，或者直接报出CRS-2551这类错误。

如何确认当前是CRS模式而非Oracle Restart模式

区分两者其实并不复杂，一个关键命令就能看穿本质。运行：

crsctl stat res -t

观察输出内容。如果其中间出现了ora.asm、ora.cssd、ora.crsd、ora.cluster_interconnect.haip这类典型的集群资源，并且状态显示为ONLINE，那么毫无疑问，你正处在CRS模式之下。

相比之下，纯粹的Oracle Restart模式输出会简单得多，通常只会列出ora..db、ora..lsnr等本地资源。而且，在Restart模式下，往往需要加上-init参数（即crsctl stat res -init -t）命令才会有响应。

• 注意区分初始化资源：crsctl stat res -init -t显示的是OHASD管理的初始化资源（比如ora.cssd、ora.ctssd），这些资源在RAC和Restart环境下都存在，因此不能单凭这个来判断运行模式。
• 真正的区分点：关键在于crsctl stat res -t的输出是否包含一个清晰的Cluster Resources分区。有，就是RAC；没有，才是Restart。
• 进程检查法：通过ps -ef | grep crsd查看crsd.bin进程是否存在是最直接的。存在即为CRS模式。如果只有ps -ef | grep ohasd有输出而找不到crsd.bin，那才可能（注意，也仅仅是可能）是Restart模式，不过在11.2及以后版本中，默认并不会单独启用它。

如果误以为需要Oracle Restart，实际要做什么

在RAC环境里，“自动重启失败组件”这个需求，其实早已由CRS全权负责了，根本不需要额外配置一个Oracle Restart。你的关注点应该放在确保CRS本身能可靠地完成这项工作上。

• 设置资源自动启动：确保所有关键资源（比如数据库、ASM、服务）的AUTO_START属性被正确设置为always。例如：crsctl modify resource “ora.racdb.db” -attr “AUTO_START=always”。
• 检查集群基石：定期验证OCR和Voting Disk的可访问性，这是CRS能够执行自动恢复的前提。使用ocrcheck和crsctl query css votedisk命令进行检查。
• 规范监听器管理：监听器必须通过srvctl工具进行管理，而不是手工启停。否则，CRS无法感知其状态变化，自然也就不会触发重启动作。
• 确保存储可访问：数据库实例的SPFILE必须位于ASM或OCFS2这类集群文件系统上。否则，节点重启后，CRS可能无法挂载所需的磁盘组，导致实例启动失败。

说到底，RAC环境下的高可用保障，其复杂性并不在于“额外添加一个Restart功能”，而在于确保整个CRS栈的依赖链条完整且健壮。OCR损坏、Voting Disk不可见、ASM磁盘组未挂载、私有网络不通……这其中任何一个环节出问题，都可能导致CRS启动失败或资源无法上线。这些问题，远比纠结“是否启用了Restart”要关键和实际得多。