在Oracle RAC的日常运维中，检查集群状态几乎是每天必做的事情。而crsctl stat res -t这条命令，就是最常用的全景式状态查看工具。它会以树形结构把集群中的所有资源按依赖关系分层展示出来，包括数据库、实例、监听、服务、ASM磁盘组、虚拟IP、SCAN VIP等。输出的信息量很大，如果不知道每列字段的含义，很容易看得一头雾水，甚至漏掉关键异常。这篇文章就来把这份输出彻底讲透。
一、命令输出的整体结构是什么样的
执行crsctl stat res -t后，输出首先会列出集群名称和当前时间，随后按资源组逐段展示。每一段以类似ora.DATA.dg这样的资源名称开头，紧跟一个缩进的树形结构，列出该资源依赖的下层资源。比如数据库资源ora.orcl.db下面会挂两个实例资源ora.orcl.db的子项，格式上用__作为子资源的标记。
输出的列头通常是固定的几项：Target表示资源应该达到的目标状态，也就是管理员或集群策略期望它处于的状态；State表示资源当前实际的状态；Server或Online on node表示资源当前运行在哪个节点上；State details则记录状态的详细说明，比如资源是在什么时间点启动的。
理解Target和State的配合关系非常关键。当两者一致且都为Online时，说明资源运行正常。当Target是Online而State是Offline时，说明资源本该运行但没有运行起来，这往往意味着启动失败或者被异常终止。当Target是Offline而State也是Offline时，则可能是管理员主动停止的资源，属于正常维护状态。所以判断资源是否异常，不能只看State一列，必须把Target和State放在一起对照。
二、核心资源类型的解读要点
RAC集群的资源大致可以分为几大类。第一类是节点级别的资源，比如ora.vip类型的节点虚拟IP资源，以及ora.scan1.vip、ora.LISTENER_SCAN1.lsnr这类SCAN相关资源。如果发现某个VIP资源Offline，该节点上的应用连接将无法通过这个IP访问数据库，客户端会出现连接超时的现象。
第二类是存储类资源，主要是ora.+.asm（ASM实例）和ora.xxx.dg（磁盘组资源）。ASM实例资源的状态直接影响磁盘组能否被挂载，进而影响数据库的启动。如果看到磁盘组资源State显示为Offline或Intermediated，需要检查ASM告警日志和磁盘设备的权限、路径是否正常。数据库对磁盘组有依赖关系，所以磁盘组异常时数据库资源通常也无法Online。
第三类是数据库和实例资源，形如ora.orcl.db和其下的实例子项。实例子项的状态列会显示Online加节点名，表示该实例正运行在对应节点上。如果实例显示Offline而Target是Online，说明实例启动失败，此时应该立即查看该实例的告警日志定位原因，常见的问题包括参数文件损坏、联机日志不可访问、归档目录满等。
-- 输出片段示例（节选）
$ crsctl stat res -t
--------------------------------------------------------------------------------
Name Target State Server State details
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
ONLINE ONLINE racnode1 STABLE
ONLINE ONLINE racnode2 STABLE
ora.LISTENER.lsnr
ONLINE ONLINE racnode1 STABLE
ONLINE ONLINE racnode2 STABLE
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.orcl.db
1 ONLINE ONLINE racnode1 Open,STABLE
2 ONLINE ONLINE racnode2 Open,STABLE
ora.scan1.vip
1 ONLINE ONLINE racnode1 STABLE
三、State details里的STABLE和INTENDED含义
在较新版本的Clusterware中，State details一列常见的值有STABLE、STARTING、STOPPING等。STABLE表示资源状态已经稳定，没有正在进行的变更操作。如果看到STARTING，说明资源正在启动过程中，此时不必急于干预，可以等待片刻再复查。如果资源长时间停留在STARTING状态，就要怀疑启动脚本被挂起或者依赖的资源出现了问题。
数据库实例资源还会在State details中显示数据库的打开状态，例如Open、Mounted、Started。Open表示实例已经打开对外提供服务，Mounted表示只挂载了控制文件，Started表示实例启动但未挂载数据库。利用这些信息，可以不用登录SQLPlus就能快速判断实例处于什么阶段，这对批量巡检多套RAC环境特别实用。
四、常见异常状态与排查思路
实际排障时，重点关注的场景有几种。第一种是某节点上大量资源同时Offline，这通常意味着该节点发生了驱逐，需要检查该节点的ocssd日志、系统日志以及是否存在网络心跳、磁盘心跳异常。第二种是单个资源反复重启，State details中可能显示STABLE但资源的启动时间很短，可以结合crsctl stat res 资源名 -p查看RESTART_COUNT之类的统计信息来判断资源是否在重启循环中。
排查时可以配合几个常用命令。crsctl stat res -t -init用于查看节点级别的基础守护资源（如ora.crsd、ora.cssd、ora.evmd）的状态，这些资源由init进程管理，不出现在普通输出里。想看资源的完整属性定义，可以用crsctl stat res 资源名 -p，输出中的AUTO_START、SERVER_POOLS、DEPENDENCIES等参数对分析资源为何没有在某节点启动很有帮助。
-- 查看基础守护资源状态 crsctl stat res -t -init -- 查看某个数据库资源的详细属性 crsctl stat res ora.orcl.db -p | grep -i "state\|auto_start\|server_pool" -- 定位具体的资源日志位置 getdiag.sh
另外还有一个小技巧：输出内容太多时可以用crsctl stat res -w "STATE = OFFLINE" -t直接过滤出所有处于Offline状态的资源，巡检效率会高很多。把这条命令写进日常巡检脚本，配合对Target列的判断逻辑，就能自动发现状态不一致的异常资源。
总的来说，解读crsctl stat res -t输出的核心是三点：先看Target和State是否一致，再确认各资源运行在预期的节点上，最后通过State details和资源属性深入定位异常根因。养成对照依赖关系逐层检查的习惯，大部分RAC资源类故障都能在第一时间被发现和定位。
Oracle RACcrsctl stat res集群状态检查修改时间：2026-09-10 06:44:38