crsctl管理集群底层服务（css、crs、ctss等），srvctl管理应用层资源（数据库、实例、asm、监听器等）；两者职责分明，混用会导致状态不一致或启停失败。
crsctl 管理集群底层服务（CSS、CRS、CTSS等），srvctl 管理应用层资源（数据库、实例、ASM、监听器、服务等）；两者不能混用，误用会导致状态不一致或启停失败。
查集群整体是否在线，用 crsctl check cluster
这是最轻量、最安全的连通性验证方式，不依赖 OCR 或 ASM，适合日常巡检或故障初判：
-
crsctl check cluster：检查所有节点是否可达、集群心跳是否正常；加-n rac01可指定单节点 -
crsctl check crs：检查本节点 CRS 进程（ohasd、crsd、cssd、ctssd）是否运行；若返回CRS-4638: Oracle High Availability Services is online才算通过 - 注意：
crsctl check has和crsctl check ctss在启用 NTP 时可能显示Observer mode，这属于正常，不代表异常
看资源当前状态，优先用 crsctl stat res -t
该命令输出带层级结构的资源树（VIP、SCAN VIP、监听器、ASM、数据库实例等），比旧版 crs_stat -t 更清晰，且是 11gR2+ 官方推荐：
- 资源状态列中
ONLINE表示已启动并注册到集群，OFFLINE不代表故障，可能是被手工停掉或未配置自动启动 - 若某资源显示
INTERMEDIATE或反复OFFLINE → ONLINE，大概率是依赖关系断裂（比如 ASM 没起来，数据库实例就起不来） - 不要用
crsctl status res <res_name></res_name>查单个资源——它只返回原始状态字符串，没上下文，排查效率低
启停数据库和 ASM，必须用 srvctl
srvctl 会自动处理依赖链（例如启动数据库前先确保 ASM 已 mount、监听器已运行），绕过它直接用 SQL*Plus 或 crsctl 启停，会导致 OCR 记录与实际状态脱节：
- 启动整个数据库（含所有实例）：
srvctl start database -d p19c0 - 只启一个实例：
srvctl start instance -d p19c0 -i p19c01 - 启 ASM 实例及磁盘组：
srvctl start asm -n rac01（注意：不是start diskgroup，后者只挂载 DG，不启动 ASM 进程） - 停止监听器要指定名称：
srvctl stop listener -l LISTENER；若省略-l，默认操作的是LISTENER，但 SCAN 监听器名通常是LISTENER_SCAN1，需先用srvctl config scan_listener确认
查配置信息，srvctl config 是唯一可信源
OCR 中记录的配置才是集群实际生效的设置，srvctl config 直接读 OCR，比查 $ORACLE_HOME/network/admin/tnsnames.ora 或 SQL 查询 v$parameter 更可靠：
- 查数据库注册信息：
srvctl config database -d p19c0 -a（含 SPFILE 路径、Oracle Home、实例映射） - 查 SCAN 地址和端口：
srvctl config scan；输出中的SCAN name必须能被客户端 DNS 解析，否则 TNS-12545 - 查 VIP 配置：
srvctl config vip -n rac01；若 VIP 绑定在错误网卡（比如绑到了 public 网卡却走 private 子网），客户端连接会超时 - 切记：
srvctl config输出里没有的资源，srvctl就无法管理——比如手工创建的 service 没用srvctl add service注册进 OCR，srvctl status service就查不到
真正容易出问题的不是命令记不住，而是混淆了“谁管什么”：crsctl 动的是集群骨架，srvctl 动的是跑在骨架上的业务。一旦用 crsctl 去 stop 一个数据库资源，srvctl 就会认为它“本不该存在”，下次 start 可能直接报 CRS-2529；反过来，srvctl 无法强制 kill 一个卡死的 cssd 进程——那得回到 crsctl 或系统级手段。边界划不清，运维就变成救火。
