Logo Oracle Deutschland   DBA Community  -  Dezember 2012
Tipps & Tricks rund um CRSCTL
von Sebastian Solbach, ORACLE Deutschland B.V. & Co. KG

Egal ob Single Instanz oder für Real Applikation Cluster Datenbanken die Grid Infrastruktur findet man bei immer mehr Systemen im Einsatz. Das liegt sowohl an der vereinfachten Überwachungstätigkeiten für die Oracle Datenbank, Listener und ASM Instanz, als auch an einigen weiterführenden Features, wie der einfachen Service Verwaltung für Single Instanz, DataGuard und/oder RAC. Dabei kommen insbesondere den Cluster Ready Services (CRS), einem Bestandteil der Clusterware Komponente der Grid Infrastruktur, eine wichtige Bedeutung zu, da diese intern alle Ressourcen steuert. Ressourcen können hierbei natürlich nicht nur die Oracle Prozesse (Datenbank, Listener, Virtuelle IP Adressen etc.) sein, sondern auch eigene Applikationen, die unter die Überwachung der Grid Infrastruktur resp. Clusterware gestellt werden. Dies kann von simplen Neustartanforderungen im Single Server Betrieb bis zu klassischen Failover Szenarien in Clusterumgebungen reichen. Diesem Aspekt trägt auch die Tatsache Rechnung, dass es seit einiger Zeit generische Applikations-Agenten (Siebel, Tomcat, GoldenGate, Apache, ...) für die Clusterware gibt und eine abgespeckte GI Installation auf der Oracle eigenen Middleware Hardware (Exalogic) läuft, um die Prozesse zu überwachen.

Diese Cluster Ready Services werden vom Befehl "crsctl" gesteuert. Deshalb lohnt es sich dieses Utility mal genauer anzuschauen, zumal es einige Feinheiten enthält, die nicht direkt aus der Dokumentation bzw. Hilfe des Tools ersichtlich sind.

Vor 11gR2 gab es zur Verwaltung der Ressourcen innerhalb der Clusterware je nach Anforderung einen eigenen "crs_*" Befehl, wie z.b. "crs_start", um eine Ressource zu Starten oder "crs_modify", um Parameter der Ressource zu verändern. Obwohl diese "crs_" Befehle immer noch existieren, ersetzt das CRSCTL Utility sie komplett. D.h. statt "crs_start" gibt es nun einen "crsctl start res" und statt der üblichen Statusabfrage mit "crs_stat" verwendet man nun den Befehl "crsctl stat res". Eine genaue Gegenüberstellung der Befehle findet man in der Dokumentation zu CRSCTL. Anhand von "crsctl stat" kann man viele Besonderheiten des CRSCTL Befehls erklären, weshalb dieser hauptsächlich im Weiteren betrachtet wird und in Beispielen verwendet wird.

Ressourcen?

Die Oracle Clusterware bezeichnet eigentlich (fast) alles als Ressource, weshalb die meisten Befehle sich auf eben diese beziehen. Ressourcen können eigene Applikationen sein, die unter die Überwachung des CRS gestellt werden. Beispiele für Ressourcen sind Oracle Datenbanken, Services, Listener und Netzwerke. Diese Ressourcen kann man sich am einfachsten in tabellarischer Sicht anzeigen lassen: 
# crsctl stat res -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.INFRA.dg
               ONLINE  ONLINE       bumucsvm1
               ONLINE  INTERMEDIATE bumucsvm2
               ONLINE  OFFLINE      bumucsvm3
ora.LISTENER.lsnr
               ONLINE  ONLINE       bumucsvm1
               ONLINE  ONLINE       bumucsvm2
               ONLINE  OFFLINE      bumucsvm3
ora.asm
               ONLINE  ONLINE       bumucsvm1                Started
               ONLINE  INTERMEDIATE bumucsvm2
               ONLINE  OFFLINE      bumucsvm3
ora.net1.network
               ONLINE  ONLINE       bumucsvm1
               ONLINE  ONLINE       bumucsvm2
               ONLINE  OFFLINE      bumucsvm3
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
      1        ONLINE  ONLINE       bumucsvm1
ora.LISTENER_SCAN2.lsnr
      1        ONLINE  ONLINE       bumucsvm2
ora.LISTENER_SCAN3.lsnr
      1        ONLINE  ONLINE       bumucsvm1
ora.bumucsvm1.vip
      1        ONLINE  ONLINE       bumucsvm1
ora.bumucsvm2.vip
      1        ONLINE  ONLINE       bumucsvm2
ora.bumucsvm3.vip
      1        ONLINE  INTERMEDIATE bumucsvm1                FAILED OVER
Die Anzeige ist dabei clusterweit und unterscheidet zwischen lokalen (auf jedem Knoten vorhandenen) und Cluster Ressourcen (können auf jedem Knoten des Clusters laufen). Nicht direkt in der CRSCTL Dokumentation enthalten ist hingegen die Information, dass es noch sogenannte Initiale Ressourcen gibt, die pro Knoten laufen. Diese können mit dem -init Flag angezeigt werden. Der gleiche Flag würde auch für das Anlegen und Modifizieren Initialer Prozesse funktionieren ("crsctl modify res ... -init"): 
# crsctl stat res -t -init
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.asm
      1        ONLINE  ONLINE       bumucsvm1                Started
ora.cluster_interconnect.haip
      1        ONLINE  ONLINE       bumucsvm1
ora.crf
      1        ONLINE  ONLINE       bumucsvm1
ora.crsd
      1        ONLINE  ONLINE       bumucsvm1
ora.cssd
      1        ONLINE  ONLINE       bumucsvm1
ora.cssdmonitor
      1        ONLINE  ONLINE       bumucsvm1
ora.ctssd
      1        ONLINE  ONLINE       bumucsvm1                OBSERVER
ora.diskmon
      1        ONLINE  ONLINE       bumucsvm1
ora.drivers.acfs
      1        ONLINE  ONLINE       bumucsvm1
ora.evmd
      1        ONLINE  ONLINE       bumucsvm1
ora.gipcd
      1        ONLINE  ONLINE       bumucsvm1
ora.gpnpd
      1        ONLINE  ONLINE       bumucsvm1
ora.mdnsd
      1        ONLINE  ONLINE       bumucsvm1
Dabei werden die Initialen Prozesse schon angezeigt, bevor der Clusterstack vollkommen gestartet wurde. Somit kann man schon rechtzeitig einen Hinweis darauf erhalten, ob ein Startprozess ein Problem hat. Die -init Abfragen sind von Natur aus auf den lokalen Knoten beschränkt.

Wichtige Anmerkung: Ressourcen, die mit ora.* Ressourcen benannt sind (Datenbank, Listener, Services), dürfen nicht direkt mit dem CRSCTL Utility verändert werden, es sei denn Oracle Support weist explizit darauf hin. Für Verwaltung und Änderungen der Attribute der ora.* Ressourcen dient das SRVCTL Utility. Wobei die Änderungen, die von SRVCTL durchgeführt werden, sehr wohl über CRSCTL beobachtet werden können.

Neben den Ressourcen können auch die in der Clusterware definierten Types angezeigt werden. Hierbei handelt es sich um Definitionen, auf die sich die einzelnen Ressourcen beziehen. So sind Datenbank Ressourcen z.B. vom Typ "ora.database.type" und Services vom Type "ora.service.type". Auch hier gibt es die Unterscheidung zwischen Initialen Typen und den Standard Clustertypen. Jeder Typ ist im Normalfall eine Ableitung einer "Lokalen" oder "Cluster" Ressource und man kann diese durchaus wie Objekttypen betrachten, da Untertypen die Eigenschaften des übergeordneten Typs erben. So sind beide oben erwähnten Typen (Services und Datenbank) vom base Type "ora.cluster_resource.type" abgeleitet.

Ebenfalls ist es möglich sich die Server und Serverpools im Cluster anzeigen zu lassen, was allerdings leider nicht in tabellarischer Form funktioniert: 
# crsctl stat serverpool
NAME=Free
ACTIVE_SERVERS=bumucsvm3

NAME=Generic
ACTIVE_SERVERS=

NAME=ora.bu
ACTIVE_SERVERS=bumucsvm1 bumucsvm2

Statische und Runtime Informationen

Zu jeder Ressource gibt es statische Informationen. Das sind Informationen, die fest in der Oracle Cluster Registry (OCR) hinterlegt sind und die sich nicht während der Laufzeit ändern. Dazu gehören, neben dem Namen und Typ der Ressource wichtige Informationen wie AUTO_START (wird die Ressource automatisch nach einem Restart gestartet), CHECK_INTERVAL (wie oft wird geprüft, ob z.B. die Prozesse der Ressourcen noch laufen oder ob sich gegen eine Datenbank Connected werden kann) und die Voraussetzungen für das Stoppen und Starten der Ressource (STOP_DEPENDENCY und START_DEPENDENCY).

Diese Informationen können mit -p abgefragt werden: 
# crsctl stat res ora.asm -p
NAME=ora.asm
TYPE=ora.asm.type
ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r--
ACTION_FAILURE_TEMPLATE=
ACTION_SCRIPT=
AGENT_FILENAME=%CRS_HOME%/bin/oraagent%CRS_EXE_SUFFIX%
ALIAS_NAME=ora.%CRS_CSS_NODENAME%.ASM%CRS_CSS_NODENUMBER%.asm
AUTO_START=never
CHECK_INTERVAL=60
CHECK_TIMEOUT=30
DEFAULT_TEMPLATE=PROPERTY(RESOURCE_CLASS=asm) ELEMENT(INSTANCE_NAME= %GEN_USR_ORA_INST_NAME%)
DEGREE=1
DESCRIPTION=Oracle ASM resource
ENABLED=1
GEN_USR_ORA_INST_NAME=
GEN_USR_ORA_INST_NAME@SERVERNAME(bumucsvm1)=+ASM1
GEN_USR_ORA_INST_NAME@SERVERNAME(bumucsvm2)=+ASM3
GEN_USR_ORA_INST_NAME@SERVERNAME(bumucsvm3)=+ASM2
LOAD=1
LOGGING_LEVEL=1
NLS_LANG=
NOT_RESTARTING_TEMPLATE=
OFFLINE_CHECK_INTERVAL=0
PROFILE_CHANGE_TEMPLATE=
RESTART_ATTEMPTS=5
SCRIPT_TIMEOUT=60
START_DEPENDENCIES=weak(ora.LISTENER.lsnr)
START_TIMEOUT=900
STATE_CHANGE_TEMPLATE=
STOP_DEPENDENCIES=
STOP_TIMEOUT=600
TYPE_VERSION=1.1
UPTIME_THRESHOLD=1d
USR_ORA_ENV=
USR_ORA_INST_NAME=+ASM%CRS_CSS_NODENUMBER%
USR_ORA_OPEN_MODE=mount
USR_ORA_OPI=false
USR_ORA_STOP_MODE=immediate
VERSION=11.2.0.1.0
Die vorhandenen Informationen sind allerdings Typen abhängig. So enthält eine Datenbank Ressource z.b. auch ein ORACLE_HOME, welches der ASM Instanz fehlt.

Runtime Informationen hingegen geben Auskunft über den aktuellen Status der Ressource. Wie oft musste die Clusterware die Ressource schon neu starten (RESTART_COUNT)? Wann wurde die Ressource das letzte Mal erfolgreich gestartet (LAST_RESTART)? Wie ist der aktuelle Status? Runtime Informationen sind also alle Eigenschaften, die sich während der Cluster läuft ändern können. Diese können mit -f mit allen statischen Parametern mit ausgegeben werden oder mit -v separat angezeigt werden: 
# crsctl stat res ora.asm  -v
NAME=ora.asm
TYPE=ora.asm.type
LAST_SERVER=bumucsvm1
STATE=ONLINE on bumucsvm1
TARGET=ONLINE
CARDINALITY_ID=ONLINE
CREATION_SEED=132
RESTART_COUNT=0
FAILURE_COUNT=0
FAILURE_HISTORY=
ID=ora.asm bumucsvm1 1
INCARNATION=1
LAST_RESTART=NEVER
LAST_STATE_CHANGE=09/11/2012 11:39:12
STATE_DETAILS=Started
INTERNAL_STATE=STABLE

...
Das funktioniert selbstverständlich auch für Types, Serverpools, Servers und Initialen Ressourcen.

Filterfunktionen

Für mich persönlich eins der best gehüteten Geheimnisse von CRSCTL ist die enthaltene Filterfunktion. Mit dieser lassen sich nicht nur die Ausgabe von "crsctl stat res" nach eigenen Wünschen anpassen, sondern diese können auch in anderen Befehlen verwendet werden: Sie möchten um Beispiel alle Ressourcen mit einem bestimmten Namen mit einem Befehl starten, andere nicht? Auch hier hilft die Filterfunktion.

Die Filterfunktion kann dabei folgenden Argumenten entgegen nehmen "=, >, <, !=, co, st, en", wobei co für CONTAINS, st für STARTS WITH und en für ENDS WITH steht. Wichtig ist, dass die abgefragte Eigenschaft, nicht in der Output Liste stehen muss und daher der Output durchaus auch tabellarisch sein kann. Ein häufiger Anwendungsfall hierfür ist eine übersichtliche Anzeige für Probleme. Führt man "crsctl stat res -t" durch, sieht man alle Ressourcen, was besonders in großen Umgebungen schnell unübersichtlich wird, wenn viele "ONLINE ONLINE" zu sehen sind. Im Normalfall möchte man sich auf die Ressourcen konzentrieren, die nicht gestartet wurden/werden konnten: 
# crsctl stat res -w "STATE = OFFLINE" -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.INFRA.dg
               ONLINE  OFFLINE      bumucsvm3
ora.LISTENER.lsnr
               ONLINE  OFFLINE      bumucsvm3
ora.asm
               ONLINE  OFFLINE      bumucsvm3
ora.gsd
               OFFLINE OFFLINE      bumucsvm1
               OFFLINE OFFLINE      bumucsvm2
               OFFLINE OFFLINE      bumucsvm3
ora.net1.network
               ONLINE  OFFLINE      bumucsvm3
...
Zwar ist die Liste schon kleiner, aber die Liste enthält immer noch die "gsd" Ressource, die nur von Interesse ist, wenn in der Clusterumgebung eine 9i Datenbank existiert. Je nach Anforderung kann diese nun über den Typ, den Namen oder den Status zusätzlich gefiltert werden: 
# crsctl stat res -w "(STATE = OFFLINE) AND (TYPE != ora.gsd.type)" -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.INFRA.dg
               ONLINE  OFFLINE      bumucsvm3
ora.LISTENER.lsnr
               ONLINE  OFFLINE      bumucsvm3
ora.asm
               ONLINE  OFFLINE      bumucsvm3
ora.net1.network
               ONLINE  OFFLINE      bumucsvm3
...
Die Möglichkeiten sind vielfältig. So kann man zum Beispiel sehr schnell herausfinden, welche Datenbanken eine Abhängigkeit auf die INFRA Diskgruppe haben (und welche nicht): 
# crsctl stat res -w "(TYPE = ora.database.type) AND (START_DEPENDENCIES co INFRA)" -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.buvmrac.db
      1        ONLINE  ONLINE       bumucsvm1                Open
      2        ONLINE  ONLINE       bumucsvm2                Open
Das gleiche hätte man mit "crsctl stat res -w "(NAEM en .db) AND (START_DEPENDENCIES co INFRA)" -t erreichen können.

Nützliche Links und Referenzen

  • Clusterware Predefined Agents
  • Oracle Clusterware Administration and Deployment Guide 11g Release 2 (11.2) - E CRSCTL Utility Reference

    • Zurück zur Community-Seite