Oracle RAC: täglicher Betrieb und Fehlerszenarien

Täglicher Betrieb und Störungsbehebung für einen installierten, laufenden Oracle-RAC-Cluster (Grid Infrastructure 19c): Health Check, Diagnose von Node Evictions, Node in Wartung nehmen, gesamten Cluster geplant herunterfahren und starten, Nodes hinzufügen und entfernen, Service-Verwaltung (preferred/available, AC/TAC), Änderung von SCAN/VIP/Port/Interconnect, Backup und Wiederherstellung von OCR/OLR, Verlagerung von OCR und Voting Files. Keine Installationsanleitung (zuerst RAC-Installation); für Patches siehe RAC Rolling Patch, für Diskgruppen ASM im täglichen Betrieb. Jedes Szenario folgt dem Muster Diagnose → Sicherheitsnetz → Durchführung → Verifizierung → Nacharbeiten.

Topologie: Bestehender RAC mit 2–8 Nodes (Grid Infrastructure 19c; Unterschiede zu 23ai/26ai in den Hinweisen)

Szenarien

• Cluster-Health-Check (täglich / vor Wartungsarbeiten) — Ändert nichts: Geprüft werden Clusterware-Stack, Ressourcen, OCR/Voting, ASM, Interconnect, Uhrzeit und letzte Warnungen. Wähle das Szenario für die tägliche Prüfung, vor jeder Wartung und jedem Patch und als ersten Schritt, wenn eine Beschwerde eingeht.
• Ein Node wurde aus dem Cluster entfernt oder hat sich selbst neu gestartet (Eviction-Diagnose) — Nur lesend: Wähle dieses Szenario, wenn ein Node unerwartet neu gestartet oder aus dem Cluster entfernt wurde. Anhand von Clusterware-Alert-Log, ocssd.trc, Betriebssystem-Logs und den Werten von misscount/disktimeout wird ermittelt, ob die eigentliche Ursache im Netzwerk, im Storage oder im Betriebssystem liegt.
• Einen Node für Wartungsarbeiten stoppen und wieder starten — Wähle dieses Szenario, wenn auf einem Node ein Betriebssystem-Patch, ein Kernel-Update oder eine Hardwarewartung ansteht. Die übrigen Nodes laufen weiter; die Services der Instance auf diesem Node werden verlagert, die Sessions enden nach Ablauf der Drain-Zeit.
• Gesamten Cluster geplant herunterfahren und starten — Wähle dieses Szenario, wenn alle Nodes gleichzeitig heruntergefahren werden müssen, etwa bei SAN- oder Rechenzentrumswartung. Vollständige Ausfallzeit: Alle Datenbanken, ASM und Clusterware stoppen auf allen Nodes.
• Neuen Node zum Cluster hinzufügen — Wähle dieses Szenario, wenn ein neuer Server in den Cluster aufgenommen wird (Kapazitätserweiterung, Hardwareerneuerung). Ohne Ausfallzeit: Vorabprüfungen (cluvfy), Grid Home (addnode.sh), DB Home und neue Instance (dbca -addInstance).
• Node aus dem Cluster entfernen — Wähle dieses Szenario, wenn ein Server dauerhaft aus dem Cluster ausscheidet (Rückgabe, Hardwaredefekt). Die Instance wird gelöscht, DB und Grid Home werden von diesem Node entfernt, der Node wird aus dem Cluster gelöscht; die übrigen Nodes bleiben in Betrieb.
• Service anlegen, ändern, verlagern oder löschen — Wähle dieses Szenario, um einen Service für die Anwendung zu definieren, seine Platzierung (preferred/available) oder seine Failover-Einstellung (TAF/Application Continuity) zu ändern oder einen laufenden Service auf eine andere Instance zu verlagern. Die Datenbank bleibt geöffnet.
• Änderung von SCAN, VIP, Listener-Port oder Interconnect — Wähle dieses Szenario, wenn sich SCAN-Name/-IPs, die VIP eines Nodes, der Listener-Port oder das private Netzwerk (Interconnect) ändern. Eine Interconnect-Änderung erfordert den Stopp des gesamten Clusters; die übrigen Änderungen verursachen eine kurze Verbindungsunterbrechung.
• OCR- und OLR-Backup erstellen, Backups prüfen — Keine Ausfallzeit: manuelles OCR-Backup, OLR-Backup auf jedem Node und Kopie der Backups außerhalb der Cluster-Disks. Wähle das Szenario vor jedem riskanten Eingriff wie Patch, Hinzufügen/Entfernen von Nodes oder Netzwerkänderung.
• OCR beschädigt oder CRS-Diskgruppe verloren: aus dem Backup wiederherstellen — Wähle dieses Szenario, wenn ocrcheck eine Beschädigung zeigt, CRSD nicht startet (PROT-/PROC-Fehler) oder die CRS-Diskgruppe vollständig verloren ist. Der gesamte Cluster stoppt; die OCR wird im Exclusive-Modus aus dem Backup geladen, bei verlorener Diskgruppe werden Diskgruppe, Voting Files und ASM-spfile neu angelegt.
• Clusterware startet auf einem Node nicht: OLR beschädigt — Wähle dieses Szenario, wenn bei laufenden übrigen Nodes crsctl start crs nur auf einem Node OHASD nicht starten kann und ocrcheck -local einen OLR-Fehler meldet. Betroffen ist nur dieser Node: Die OLR wird aus dem Backup geladen.
• OCR und Voting Files in eine andere Diskgruppe verlagern — Ohne Ausfallzeit: ocrconfig -add/-delete und crsctl replace votedisk. Wähle dieses Szenario bei einem Storage-(SAN-)Wechsel, zur Erhöhung der Redundanz der CRS-Diskgruppe oder um die OCR zusätzlich in eine zweite Diskgruppe zu schreiben.

Vor dem Start

• Auf allen Nodes gibt es root-Zugriff und eine Login-Shell für die Benutzer grid/oracle (sudo -iu grid); die Profile von grid und oracle laden die Umgebung von Grid/DB Home.
• Vor dem Start ist der Cluster intakt: CRS auf allen Nodes online, keine Ressource offline, die laufen sollte. Andernfalls behebe das Problem zuerst mit dem Health Check.
• Wartungsfenster und Change Record sind freigegeben; die Anwendungsteams sind informiert; im Monitoring ist ein Blackout gesetzt. …Dieser Vorgang verursacht eine vollständige Ausfallzeit.…
• Es gibt ein aktuelles RMAN-Backup der Datenbank und Backups der Archive Logs… (Hinzufügen/Löschen einer Instance ändert Redo Thread und Undo-Tablespace)….
• Es gibt ein außerhalb der Cluster-Disks aufbewahrtes OCR-Backup (…), oder der Pfad des automatischen Backups in einer intakten Diskgruppe ist bekannt. …Für die CRS-Diskgruppe stehen genügend leere, auf allen Nodes sichtbare Disks für …-Redundanz bereit.…
• Der neue Node (…) hat dieselbe Betriebssystemversion und denselben Kernel wie die vorhandenen Nodes; die Betriebssystemvorbereitung aus der RAC-Installation und die Storage-Vorbereitung sind erledigt; die Namen der Public-/Private-Interfaces sind gleich; die Shared LUNs sind auch diesem Node zugewiesen; die VIP-Adresse … ist frei.
• Der ungefähre Zeitpunkt des Vorfalls ist bekannt. Ist AHF (TFA) installiert, erfolgt die Diagnosesammlung mit einem Befehl; andernfalls werden die Logs manuell ausgewertet.

Phasen der Anleitung

• Cluster-Health-Check — Clusterware-Stack auf allen Nodes prüfen · Zustand der Ressourcen auflisten · Zustand von Datenbank, Services und Listenern prüfen · Integrität von OCR, Voting und OLR prüfen · ASM und Füllstand der Diskgruppen prüfen · Netzwerkkonfiguration und Zeitsynchronisation prüfen …
• Gesamten Cluster stoppen — Zustand vor dem Stoppen festhalten · Manuelles OCR-Backup erstellen (Sicherheitsnetz) · Alle Datenbanken stoppen · Clusterware auf allen Nodes stoppen · OHASD stoppen (…) · Wartungsarbeiten durchführen
• Gesamten Cluster starten — Clusterware starten (…) · Warten, bis alle Nodes dem Cluster beigetreten sind · Prüfen, ob die Datenbanken geöffnet sind · Ressourcen nach dem Start vergleichen
• Neuen Node vorbereiten und Vorabprüfungen — Aktuelle Cluster-Konfiguration festhalten · Betriebssystemvorbereitung des neuen Nodes verifizieren · Neuen Node in /etc/hosts eintragen (…) · SSH-Äquivalenz für den Benutzer grid auf den neuen Node erweitern · SSH-Äquivalenz für den Benutzer oracle auf den neuen Node erweitern · cvuqdisk-RPM auf den neuen Node übertragen …
• Grid Infrastructure auf den neuen Node erweitern — Manuelles OCR-Backup erstellen (Sicherheitsnetz) · Grid Home auf den neuen Node erweitern (addnode.sh) · orainstRoot.sh ausführen (neuer Node) · root.sh ausführen (neuer Node) · grid-Umgebung auf dem neuen Node einrichten · Neuen Node im Cluster verifizieren
• DB Home und neue Instance — DB Home auf den neuen Node erweitern · root.sh des DB Home ausführen (neuer Node) · oracle-Umgebung auf dem neuen Node einrichten · Neue Instance hinzufügen (dbca -addInstance) · Neue Instance in die Service-Konfiguration aufnehmen · Neue Instance verifizieren
• Nach dem Hinzufügen des Nodes — OLR-Backup des neuen Nodes erstellen · OCR-Backup der neuen Konfiguration erstellen · Monitoring, Backup und Betriebsabläufe aktualisieren
• Instance und DB Home entfernen — Services von … leeren (Instance bleibt geöffnet) · Instance löschen (dbca -deleteInstance) · DB-Home-Inventar auf den Ziel-Node beschränken (…) · DB Home entfernen (deinstall -local) (…) · DB-Home-Inventar auf den verbleibenden Nodes aktualisieren
• Clusterware vom Ziel-Node entfernen — Pin-Status prüfen und bei Bedarf aufheben · Grid Home entfernen (deinstall -local) (…) · Node aus der Cluster-Definition löschen · Löschen verifizieren und übrig gebliebene VIP entfernen
• Nach dem Entfernen des Nodes — OCR-Backup der neuen Konfiguration erstellen · Überbleibsel bereinigen und Einträge aktualisieren
• Service: Diagnose — Aktuelle Konfiguration der Services anzeigen
• Service: Durchführung — Service anlegen und starten · Platzierung und Einstellungen des Service ändern · Service gemäß neuer Platzierung starten · Service auf eine andere Instance verlagern · Service stoppen und löschen
• Service: Verifizierung — Prüfen, ob der Service in der Datenbank und im Listener sichtbar ist
• Netzwerkänderung: Diagnose und Sicherheitsnetz — Aktuelle Netzwerkkonfiguration festhalten · Manuelles OCR-Backup erstellen (Sicherheitsnetz) · Backup des GPnP-Profils erstellen (…)
• SCAN-Name / -IPs ändern — Neue SCAN-Auflösung verifizieren · SCAN-VIPs und -Listener mit den neuen Werten neu anlegen · remote_listener der Datenbank aktualisieren · Verbindung über SCAN verifizieren
• OCR- und OLR-Backup — Vorhandene OCR-Backups und Backup-Speicherort anzeigen · Manuelles OCR-Backup erstellen · Letztes manuelles Backup außerhalb des Clusters kopieren und verifizieren · Manuelles OLR-Backup erstellen (…) · Auch ASM-spfile und Passwortdatei sichern
• OCR-Wiederherstellung: Diagnose — Zustand der OCR und von Clusterware prüfen · Diskgruppe und Disks von ASM-Seite prüfen · Wiederherzustellendes Backup verifizieren
• OCR-Wiederherstellung: Durchführung — Clusterware stoppen (…) · Clusterware auf Node 1 im Exclusive-Modus starten · ASM mit temporärer Parameterdatei starten (falls spfile verloren) · Diskgruppe … neu anlegen · OCR aus dem Backup wiederherstellen · Voting Files neu anlegen …
• OCR-Wiederherstellung: Verifizierung und Nacharbeiten — Cluster und OCR verifizieren · Änderungen nach dem Backup prüfen · Neues OCR-Backup erstellen und eigentliche Ursache beheben