crsctl y srvctl: comandos para administrar Oracle Grid Infrastructure

Oracle Grid Infrastructure es el paquete que instala dos cosas al mismo tiempo: Oracle Clusterware, que es lo que hace que varios servidores se comporten como un clúster, y Oracle ASM, que gestiona el almacenamiento. En un servidor único ese mismo software se llama Oracle Restart. En varios servidores es un clúster, y ese es el caso que cubre esta nota.

El trabajo del día a día se hace con dos utilidades, crsctl y srvctl. Se parecen lo suficiente para confundirlas y hacen cosas distintas, así que empecemos por ahí.

Dos utilidades, dos territorios

crsctl administra la pila de Clusterware: los procesos que sostienen el clúster. Vive en Grid_home/bin y las operaciones que arrancan o paran la pila hay que ejecutarlas como root.

srvctl administra lo que corre encima de esa pila: bases de datos, instancias, listeners, direcciones VIP, el SCAN, los disk groups. Se ejecuta como el dueño del Oracle home que estás administrando, no como root.

La regla práctica está escrita en los dos manuales de Oracle, y conviene tomarla en serio: los recursos cuyo nombre empieza por ora. los pone Oracle y se administran con srvctl. Con crsctl solo si el Soporte de Oracle lo pide expresamente. El motivo que da la documentación es que manipularlos con crsctl puede dejar la configuración del clúster en mal estado.

Ver en qué estado está todo

Antes de arrancar o parar nada conviene saber de dónde partes. Estas son las comprobaciones de la pila del clúster:

crsctl check crs                     # los tres demonios locales: CRS, CSS y EVM
crsctl check cluster -all            # lo mismo, en todos los nodos
crsctl stat res -t                   # tabla de recursos y en qué nodo está cada uno
crsctl stat res ora.racdb.db -p      # atributos configurados de un recurso
crsctl stat res ora.racdb.db -f      # todos los atributos, incluidos los internos
crsctl query css votedisk            # voting disks y si están online
crsctl config crs                    # si Clusterware arranca solo al encender el servidor
olsnodes -n -i -s -t                 # nodos, número, VIP, si están activos y si están pinned
oifcfg getif                         # qué interfaz es la pública y cuál la privada
ocrcheck                             # integridad y ubicaciones del OCR
ocrconfig -showbackup                # copias automáticas del OCR y dónde están
cluvfy comp crs -n rac1,rac2         # verificar la instalación de Clusterware

crsctl check cluster acepta -all o una lista de nodos separados por espacios. Si no le pasas ninguno de los dos, revisa solo el nodo desde el que lo lanzas, que es una fuente habitual de falsa tranquilidad.

Para los recursos que corren encima, manda srvctl:

srvctl status database   -db RACDB
srvctl status instance   -db RACDB -instance RACDB1
srvctl status service    -db RACDB
srvctl status nodeapps
srvctl status vip        -node rac1
srvctl status listener   -listener LISTENER
srvctl status asm        -node rac1
srvctl status scan
srvctl status scan_listener
srvctl status diskgroup  -diskgroup DATA
srvctl status server     -server rac1

Cambiando status por config obtienes lo que hay guardado en el OCR en lugar del estado en este momento. Es la diferencia entre cómo debería estar el clúster y cómo está, y cuando algo no cuadra, comparar las dos salidas suele señalar el problema:

srvctl config database  -db RACDB
srvctl config service   -db RACDB
srvctl config nodeapps
srvctl config vip       -node rac1
srvctl config asm       -detail
srvctl config listener  -listener LISTENER
srvctl config scan
srvctl config scan_listener

Arrancar y parar la pila del clúster

Aquí está la distinción que más se pasa por alto. crsctl tiene dos parejas de comandos que suenan igual y no lo son:

# Clusterware en uno, varios o todos los nodos
crsctl stop  cluster                 # solo el nodo local
crsctl stop  cluster -all            # todos los nodos del clúster
crsctl stop  cluster -n rac1 rac2    # los nodos que indiques, separados por espacios
crsctl start cluster -all

# Toda la pila, incluido OHAS, solo en el nodo local
crsctl stop  crs
crsctl stop  crs -f                  # fuerza la parada si queda algún recurso arriba
crsctl start crs

crsctl stop crs baja también Oracle High Availability Services, el proceso que arranca todo lo demás cuando enciendes el servidor. Solo actúa en el nodo local y falla si queda algún recurso en marcha.

Oracle recomienda crsctl stop cluster cuando vayas a parar más de un nodo, y el motivo es concreto: ese comando evita que los recursos se reubiquen en otros servidores antes de que la pila se detenga. Bajando nodo por nodo con stop crs provocas reubicaciones que después toca deshacer a mano.

Todo lo anterior va como root. También el autoarranque:

crsctl disable crs   # Clusterware no arranca al encender el servidor
crsctl enable  crs   # vuelve a arrancar solo

Los dos afectan únicamente al nodo donde los ejecutas, así que en un clúster de cuatro nodos hay que repetirlos cuatro veces. Es un detalle que se olvida al preparar una ventana de mantenimiento y aparece cuando un nodo vuelve solo del reinicio.

Arrancar y parar recursos

srvctl stop  database -db RACDB -stopoption IMMEDIATE
srvctl start database -db RACDB
srvctl stop  instance -db RACDB -instance RACDB1 -stopoption IMMEDIATE
srvctl start instance -db RACDB -instance RACDB1
srvctl stop  service  -db RACDB -service OLTP -node rac1
srvctl start service  -db RACDB -service OLTP
srvctl stop  listener -listener LISTENER
srvctl start listener -listener LISTENER
srvctl stop  nodeapps -node rac1
srvctl start nodeapps
srvctl stop  vip -node rac1
srvctl start vip -node rac1
srvctl stop  scan -scannumber 1
srvctl start scan -scannumber 1
srvctl stop  scan_listener -scannumber 1
srvctl start scan_listener -scannumber 1
srvctl stop  diskgroup -diskgroup DATA -node rac1,rac2
srvctl start diskgroup -diskgroup DATA -node rac1,rac2

-stopoption acepta los mismos valores que un shutdown de base de datos: NORMAL, TRANSACTIONAL, IMMEDIATE y ABORT.

Varios de estos recursos tienen otros colgando de ellos. Parar una VIP, el SCAN, los nodeapps o un disk group falla si hay dependencias arriba: hay que bajarlas antes o añadir -force. Y para la instancia ASM casi siempre es preferible crsctl stop cluster en lugar de srvctl stop asm, porque baja ASM junto con todo lo que depende de él y en el orden correcto.

Un detalle sobre ASM que cuesta una tarde si no lo sabes: desde 12c, los comandos de ASM hay que lanzarlos con el binario srvctl del Grid home. El srvctl del home de la base de datos no sirve para administrar ASM, aunque exista y responda.

Mover un servicio o un listener SCAN a otro nodo

srvctl relocate service -db RACDB -service OLTP -oldinst RACDB1 -newinst RACDB2
srvctl relocate scan_listener -scannumber 1 -node rac2

relocate service mueve un servicio de una instancia a otra, de una en una: una instancia origen y una destino por comando. El cambio es temporal y no reescribe la lista de instancias preferidas y disponibles del servicio, así que un reinicio devuelve el servicio a su sitio.

En relocate scan_listener, el número va de 1 a 3, porque hay como máximo tres SCAN listeners. Si omites -node, SRVCTL elige el destino por ti.

Cambiar la ubicación del OCR

El OCR es el registro donde Clusterware guarda la configuración del clúster. Se puede mover con el clúster arriba, pero antes de tocarlo hay cuatro cosas que conviene tener claras:

Todos los comandos van como root, desde Grid_home/bin.
Puede haber hasta cinco ubicaciones, y cada ocrconfig -add tiene que apuntar a un disk group distinto.
El OCR hereda la redundancia del disk group donde vive. Si quieres alta redundancia para el OCR, el disk group tiene que haberse creado así; no se cambia después.
Mira las copias con ocrconfig -showbackup antes de empezar. Con la pila parada en todos los nodos, esa lista puede diferir de un nodo a otro.

El movimiento en sí son tres pasos: añadir la ubicación nueva, borrar la vieja y comprobar.

# 1. Ver dónde está el OCR ahora mismo
ocrcheck

# 2. Añadir la ubicación nueva y quitar la anterior
ocrconfig -add +DATA
ocrconfig -delete +DGVIEJO

# 3. Confirmar el resultado
ocrcheck

El orden no es un detalle de estilo. Si borras la única ubicación que tienes antes de añadir la nueva, te quedas sin OCR.

Un aviso sobre ocrcheck -local, que en muchos apuntes aparece descrito como la forma de revisar el OCR con la pila parada. No hace eso. La opción -local revisa el OLR, el registro local que cada nodo mantiene por separado con la información que necesita para arrancar. Son dos ficheros distintos y responden a preguntas distintas.

Si trabajas con 12c o posterior

Los comandos de esta nota usan palabras completas (-db, -node, -service). Los apuntes que circulan por internet suelen usar letras (-d, -n, -s), que es lo que había hasta 11.2.

Desde 12c las letras están deprecadas. Siguen funcionando por compatibilidad con scripts antiguos, pero la documentación ya solo describe las palabras, y el motivo del cambio es el que uno esperaría: la misma letra significaba cosas distintas según el comando. -o es el mejor ejemplo. En 11.2 era la opción de parada de srvctl stop database; hoy -o es -oraclehome, y la opción de parada se llama -stopoption y no tiene equivalente en una sola letra.

Si heredas un script lleno de letras, este comando te da la traducción sin adivinar:

srvctl stop database -help -compatible

Imprime cada parámetro con su nombre largo y, entre paréntesis, la letra que le correspondía. Las equivalencias más frecuentes son estas:

Hasta 11.2	Desde 12c	Qué indica
`-d`	`-db`	nombre único de la base de datos
`-i`	`-instance`	nombre de la instancia
`-n`	`-node`	nombre del nodo
`-s`	`-service`	nombre del servicio
`-l`	`-listener`	nombre del listener
`-g`	`-diskgroup`	nombre del disk group
`-a`	`-all`	todos los recursos de ese tipo
`-f`	`-force`	forzar la operación

La tabla resuelve el caso común, no todos. Varias letras se reutilizaban: -i era también el número de SCAN listener y la instancia de origen de un relocate, y -n valía además para el nombre del SCAN y para el nodo destino. Con -help -compatible lo compruebas comando por comando.

Un último detalle de versiones: crsctl check ctss, que comprueba el servicio de sincronización de hora del clúster, sigue existiendo, pero CTSS está deprecado desde 19c.

Fuentes

Todos los comandos y las advertencias de esta nota están verificados contra la documentación oficial de Oracle para 19c, que es la versión con soporte extendido más habitual en producción. La sintaxis es la misma en 21c y 23ai salvo donde se indica.

Oracle Clusterware Administration and Deployment Guide, 19c. Dentro de ella están la referencia de CRSCTL, el capítulo Managing Oracle Cluster Registry and Voting Files y la referencia de SRVCTL para operaciones de Grid Infrastructure, que es donde viven los comandos de ASM, SCAN, VIP y listeners.
Oracle Real Application Clusters Administration and Deployment Guide, 19c — y la referencia de SRVCTL, donde está la tabla completa de parámetros deprecados.
Las mismas dos guías para la versión actual: Clusterware y Real Application Clusters.

Esta nota parte de la recopilación de comandos que publicó Raúl Ibáñez Peral en dbajunior.com bajo licencia CC BY 4.0. El texto es nuevo y la sintaxis está actualizada a las versiones con soporte.

Aquel artículo remitía a los manuales a través de Tahiti, el portal con el que Oracle publicaba su documentación. Tahiti se retiró y hoy tahiti.oracle.com redirige a docs.oracle.com, así que la ruta que indicaba ya no existe. Los dos libros que citaba sí siguen publicados, con el mismo título, en la ruta nueva.