Oracle 11g RAC配置Restart实现非集群高可用
OracleRestart仅适用于单实例非集群环境，无法在RAC中配置。RAC环境下由ClusterReadyServices全权负责高可用管理，二者架构冲突。可通过检查集群资源命令或进程确认当前为CRS模式。RAC中应确保CRS栈依赖完整，设置资源自动启动并规范管理，而非启用OracleRestart。
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.、ora.等本地资源。而且，在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”要关键和实际得多。