在Oracle RAC集群环境中，Service是连接负载均衡和故障转移的核心组件。很多DBA在通过srvctl stop service命令停止一个服务时，会惊讶地发现数据库实例甚至整个集群资源发生了重启或停止。这并非Oracle的默认行为，而是因为Clusterware中资源之间的依赖关系被错误配置。理解并修正这些依赖，是保障集群稳定运行的关键。
Oracle RAC资源依赖模型解析
在Oracle Clusterware中，每个服务、数据库实例、监听器、VIP等都被抽象为资源对象。资源之间通过依赖关系决定启动和停止的顺序。主要涉及两个属性：START_DEPENDENCIES和STOP_DEPENDENCIES。START_DEPENDENCIES定义了启动当前资源之前必须满足的依赖条件，而STOP_DEPENDENCIES则定义了停止当前资源时，会连带停止哪些依赖它的资源。
依赖类型分为hard、weak、pullup和external等。hard依赖表示强依赖，若被依赖的资源未启动，则当前资源无法启动；停止被依赖资源时，当前资源也必须先停止。weak依赖允许被依赖资源单独停止而不影响当前资源。pullup则是一种反向依赖，当当前资源启动时，会自动拉起它所依赖的资源。理解这些类型对于排查连锁停止问题至关重要。
服务资源（如ora.mydb.myservice.svc）通常依赖数据库资源（ora.mydb.db）和VIP资源。正常情况下，服务应该对数据库实例是hard依赖，但数据库实例绝不应对服务有STOP_DEPENDENCIES。否则停止服务时就会触发数据库实例的停止，形成本末倒置的依赖关系。
诊断Service停止依赖故障
假设遇到如下场景：执行srvctl stop service -d mydb -s myservice后，数据库实例和监听器相继停止。首先需要检查资源依赖配置。可以使用命令crsctl stat res ora.mydb.myservice.svc -p | grep DEPENDENCIES来查看服务资源的依赖属性。同时用crsctl stat res ora.mydb.db -p | grep DEPENDENCIES查看数据库实例的依赖属性。
-- 查看服务资源的依赖定义 crsctl stat res ora.mydb.myservice.svc -p | grep DEPENDENCIES -- 输出示例： START_DEPENDENCIES=hard(ora.mydb.db,ora.mydb.vip) STOP_DEPENDENCIES=hard(intermediate:ora.mydb.db)
上面输出中，服务资源的STOP_DEPENDENCIES包含了ora.mydb.db，这意味着停止该服务时，数据库实例会被强制停止。这种配置通常是由于手动创建资源或使用旧版本工具导入时产生的错误。正确情况下，服务资源不应在STOP_DEPENDENCIES中包含数据库实例，因为服务停止不应影响数据库实例的在线状态。
还可以通过crsctl stat res -t命令观察资源树，当停止服务时，如果数据库实例状态变为OFFLINE，则进一步证实了依赖关系的不合理。另一个有用的命令是crsctl stat res ora.mydb.db -p，查看数据库实例的STOP_DEPENDENCIES，如果为空或只包含VIP等，则问题根源就在服务资源的STOP_DEPENDENCIES上。
修改Service停止依赖关系的步骤
修复此类问题需要修改服务资源的STOP_DEPENDENCIES属性，移除对数据库实例的hard依赖。在修改之前，建议先停止相关服务资源，避免在修改过程中发生意外停止。执行以下命令：srvctl stop service -d mydb -s myservice。然后使用crsctl modify resource命令调整依赖。
-- 修改服务资源的STOP_DEPENDENCIES，移除对数据库实例的依赖 crsctl modify resource ora.mydb.myservice.svc \ -attr "STOP_DEPENDENCIES=''" -- 或者根据实际需要保留对VIP的依赖 crsctl modify resource ora.mydb.myservice.svc \ -attr "STOP_DEPENDENCIES='weak(ora.mydb.vip)'"
上述命令中，将STOP_DEPENDENCIES设置为空或仅保留必要的weak依赖，确保停止服务时不会触发数据库实例停止。修改完成后，使用srvctl start service -d mydb -s myservice重新启动服务，并验证停止服务时数据库实例是否保持在线。
需要注意的是，在修改Clusterware资源属性时，最好使用crsctl modify resource的-attr参数，并确保属性值用单引号包裹。如果存在多个依赖项，用逗号分隔，依赖类型用括号包裹。修改后可以用crsctl stat res ora.mydb.myservice.svc -p再次确认属性已更新。
此外，如果问题根源在于数据库实例的START_DEPENDENCIES中错误地包含了服务资源，也需要一并修正。例如数据库实例的START_DEPENDENCIES不应包含任何服务资源，因为数据库实例的启动不应依赖于某个Service。
最佳实践与预防措施
为了避免服务停止依赖引发连锁故障，建议遵循以下最佳实践：第一，始终使用srvctl命令创建和管理服务，不要直接通过crsctl添加服务资源，因为srvctl会自动建立正确的依赖关系。第二，定期审计集群资源的依赖配置，可以使用脚本遍历所有服务资源并检查其STOP_DEPENDENCIES是否包含数据库实例或监听器资源。
第三，在实施任何资源依赖调整前，先在测试环境验证，并确保有完整的回滚方案。第四，对于已经存在的错误依赖，修改时要先停止服务，防止修改过程中资源被意外停止导致业务中断。第五，理解pullup和weak依赖的适用场景，避免过度使用hard依赖导致资源无法独立启停。
总之，Oracle RAC中的资源依赖是一把双刃剑，合理配置能提升高可用性，错误配置则可能引发灾难性停机。掌握crsctl命令查看和修改依赖的方法是每一位RAC DBA的必备技能。当遇到服务停止连带数据库停止的情况时，应首先检查STOP_DEPENDENCIES，而不是盲目重启资源。
Oracle RACService依赖集群资源管理修改时间：2026-09-23 10:39:10