crsctl stat res: syntax and optimization

crsctl is the Oracle Clusterware Control utility which is used to manage your Oracle CRS/GI/Restart configuration and crsctl stat res is most likely the most used/known mix of options used with the crsctl command which provides information about all the resources registered in your cluster. Unfortunately, crsctl stat res is not really humanly readable and is restricted in term of what information is shown and you then need to dig more into crsctl stat res to have more interesting information which is what uses rac-status.sh for example.

For example, if you want to have all the information about the services, you need to use the below syntax (-p is for static configuration and it would be -v for the runtime configuration):

# crsctl stat res -p -w "TYPE = ora.service.type"

crsctl stat res also has some nice syntax which can be used in the filer operators (it is not regexp level but it is pretty cool):

Filter Operators: =, >, <, !=, co, st, en, nc, nci, coi, eqi
  where
    co  --> contains
    st  --> starts with
    en  --> ends with
    nc  --> does not contain
    coi --> contains, case-insensitive
    nci --> does not contain, case-insensitive
    eqi --> equals, case-insensitive

For example, if you want the information about the listeners, and knowing that there are many types of listeners in an Oracle cluster like ora.listener.type, ora.scan_listener.type, ora.leaf_listener.type, ora.asm_listener.type, you could write the easy:

# crsctl stat res -v -w "TYPE co listener"

which will list all the listener types.

As these crsctl stat res commands return many information you may not be interested in, you can grep for what you want from this output. The issue I started to face is that more and more systems have more and more resources (hundreds of services, databases, etc ...) and crsctl stat res (and then my scripts rac-status.sh and oraenv++) was becoming slow which is not what we want. Hopefully, there is an easy way of greatly optimising these performances by using the -attr option allowing you to select only the columns you want:

[root@exa01db01]# time crsctl stat res -p -w "TYPE = ora.service.type" > /dev/null
real    0m33.047s
user    0m31.989s
sys     0m0.390s
[root@exa01db01]# time crsctl stat res -p -w "TYPE = ora.service.type" -attr "NAME,TYPE,ACL,ENABLED,ENABLED@SERVERNAME(exa01db01),ENABLED@SERVERNAME(exa01db02),ROLE,PLUGGABLE_DATABASE" > /dev/null
real    0m2.249s   <== 16 times faster !
user    0m0.882s
sys     0m0.164s
[root@exa01db01]#

Wow, 16 times faster in specifying the columns you want ! this crsctl -attr is a rocket !

This is how I recently greatly improved the performances of rac-status.sh and oraenv++. I just found one weird behavior when using the -attr option, see below:

[root@exa01db01]# crsctl stat res -v -w "NAME co LISTENER_SCAN2"
NAME=ora.LISTENER_SCAN2.lsnr
LAST_RESTART=11/09/2021 19:38:10
LAST_STATE_CHANGE=11/09/2021 19:38:10
[root@exa01db01]# crsctl stat res -v -w "NAME co LISTENER_SCAN2" -attr "NAME,LAST_RESTART,LAST_STATE_CHANGE"
NAME=ora.LISTENER_SCAN2.lsnr
LAST_RESTART=1636447090
LAST_STATE_CHANGE=1636447090
[root@exa01db01]# 

See these date formats ? they are different whether you use the -attr option or not. The date format is a human readable one without -attr and is an epoch sec if you use the -attr option. No big deal but it is good to know if you work on the restart dates:

[root@exa01db01]# date -d @1636447090
Tue Nov  9 19:38:10 AEDT 2021
[root@exa01db01]#

Bye for now !