Zu Oracle

Bereich:
Versionsinfo:
RAC
12.1
Erstellung:
Letzte Überarbeitung:
06/2017 KS
06/2017 KS

RAC aber sicher

Auch ein Oracle 12c Real Application Clusters (RAC) will gesichert werden, damit bei einem Ausfall des Cluster-Systems die Gesamtverfügbarkeit nicht allzu sehr kompromittiert wird.

Schnell können durch einen übereifrigen Storage-Administrator ASM-Diskgruppen überschrieben und damit alle Services im Cluster "lahmgelegt" werden.

Zur Vermeidung eines solchen Szenarios dient das ab Version 12.1.0.2 zur Verfügung stehende Feature "ASM Filter Driver", auf das aber im Rahmen dieses Monatstipps nicht näher eingegangen wird.

Dieser Monatstipp beschreibt wichtige Komponenten eines Oracle RAC, die in Ergänzung zu den Datenbanken ebenfalls gesichert werden müssen. Es wird die entsprechende Backup-Methode erläutert sowie der Restore in einem Worst-Case-Szenario, bei dem die Diskgruppe, die bei der Installation des Clusters für OCR und Voting Disks angegeben wurde, verloren geht.

Ähnlich wie bei der Datenbank ist es auch bei einem RAC empfehlenswert, einen Desaster-Test auf einem Test-Cluster durchzuspielen.

Die Komponenten der Cluster-Diskgruppe

Welche Komponenten sind bei einem Ausfall, der bei der Installation erstellten Cluster-Diskgruppe (im Folgenden OCRVOTE genannt) betroffen und wie sind sie gegebenenfalls zu sichern?

Oracle Cluster Registry

Die Oracle Cluster Registry (OCR) ist das Bestandsverzeichnis für alle im Cluster definierten und zu überwachenden Ressourcen, Services und Komponenten.

Vom Ausfall der OCR ist der gesamte Cluster betroffen.

 

Ein Backup der OCR wird automatisch alle 4 Stunden erstellt (ab 12c innerhalb von ASM):

[root@server-a:/]>ocrconfig -showbackup

server-a 2017/05/03 06:18:26 +FRA:/../OCRBACKUP/backup00.ocr.287.943510705  
server-a 2017/05/03 02:18:21 +FRA:/../OCRBACKUP/backup01.ocr.286.943496301  
server-a 2017/05/02 22:18:18 +FRA:/../OCRBACKUP/backup02.ocr.285.943481897  


Hier empfiehlt es sich, diese Backups zusätzlich auf Tape oder auf einen Fileserver zu sichern (als root-User):

[root@server-a:/]>ocrconfig -copy +FRA:/../OCRBACKUP/backup00.ocr.287.943510705
/backup/backup00.ocr.287.943510705

 

Alternativ besteht die Möglichkeit, alle OCR-Backups auf dem Fileserver zu sichern (als root-User):

[root@server-a:/]>ocrconfig -backuploc /backup

 

Voting Disks

Die Voting Disks dienen vor allem der Auflösung einer sogenannten Split-Brain-Situation, die bei einem Ausfall des Netzwerk- bzw. Storage-Heartbeats entstehen kann. Bei einem Verlust der Voting Disks erfolgt ein Stopp des gesamten Clusters.

Ein explizites Backup ist nicht erforderlich, da die Voting Disks nur den aktuellen Zustand eines Clusters reflektieren. Sie können im Desaster-Fall somit wieder neu aufgebaut werden (siehe Beispiel unten).

 

ASM-Passwort-File

Das ASM-Passwort-File dient vor allem in der Flex ASM Architektur zur Anmeldung an die ASM-Instanz. Wenn das ASM Passwort-File in dieser Konfiguration verloren geht, ist kein Connect der Datenbank-Instanzen zu ASM möglich.

Zunächst muss die Lokation des ASM-Passwort-Files ermittelt werden (als grid-User):

[grid@server-a:]>ASMCMD> pwget --asm
+ocrvote/orapwasm

 

Danach kann die Datei mittels ASMCMD PWCOPY gesichert werden:

[grid@server-a:]>asmcmd pwcopy --asm +ocrvote/orapwasm /backup/asmpasswortfile
copying +ocrvote/orapwasm -> /backup/asmpasswortfile
ASMCMD-9456: password file should be located on an ASM disk group

Die Fehlermeldung "ASMCMD-9456" kann an dieser Stelle ignoriert werden.


ASM-Parameter-File

Das ASM-Parameter-File beinhaltet die INIT.ORA Parameter der ASM-Instanz. Bei Verlust können die kundenindividuellen INIT.ORA-Einstellungen nur über ein Backup des ASM-SPFILEs wiederhergestellt werden.

Die Lokation ist folgender Abfrage zu entnehmen (als grid-User):

[grid@server-a:]>asmcmd spget
+OCRVOTE/s-sl-rac12/ASMPARAMETERFILE/registry.253.943698201

 

Gesichert wird es wie folgt (als grid-User):

[grid@server-a:]>
asmcmd spcopy +OCRVOTE/../ASMPARAMETERFILE/registry.253.943698201
/backup/asmparameterfile

 

Grid Infrastructure Management Repository (GIMR)

Das GIMR ist die Datenbank zur Speicherung der Cluster-Health-Monitor-Daten. Nach Angabe von Oracle Doc-ID 1568402.1 besteht keine Notwendigkeit, diese Datenbank zu sichern. Sie kann nach einem Desaster-Fall neu angelegt werden (siehe Beispiel unten). Allerdings sind dann die gesammelten System-Metriken nicht mehr verfügbar.


Metadaten der Diskgruppe

Die Informationen zu einer Diskgruppe wie z. B. die beteiligten LUNs, die Redundanz, die ASM/RDBMS-Kompatibilität etc. liegen auf den Platten selbst.

Die Metadaten sollten einmal pro Woche oder nach jeder Änderung an den Disks oder den Diskgruppen gesichert werden (als grid-User):

[grid@server-a:]>asmcmd md_backup /backup/md.full
Disk group metadata to be backed up: FRA
Disk group metadata to be backed up: OCRVOTE
Disk group metadata to be backed up: DATA
(..)

 

Vorgehen nach einem Ausfall der Cluster-Diskgruppe

Wenn Sie dieses Szenario simulieren wollen, könnten Sie z. B. alle zur Cluster-Diskgruppe OCRVOTE gehörenden Disks oder LUNs mit dem Unix Utility "dd" formatieren.

Das Löschen einer Diskgruppe, die Voting-Disks enthält, ist auf andere Art und Weise nicht möglich. Beim Versuch, die aktive Cluster-Diskgruppe zu entfernen erhält man folgenden Fehler:

SYS@+ASM1> drop diskgroup ocrvote;
drop diskgroup ocrvote
*
ERROR at line 1:
ORA-15039: diskgroup not dropped
ORA-15276: ASM diskgroup OCRVOTE has cluster voting files

 

Wie erkennen Sie, dass die "richtige" Diskgruppe gelöscht wurde?

[root@server-a:/]>ocrcheck
PROT-601: Failed to initialize ocrcheck
PROC-22: The OCR backend has an invalid format

[root@server-a:/]>crsctl check crs
CRS-4638: Oracle High Availability Services ist online
CRS-4535: Kommunikation mit Cluster Ready Services nicht möglich
CRS-4530: Kommunikationsfehler bei Verbindungsaufnahme mit Cluster Synchronization Services Daemon
CRS-4534: Kommunikation mit Event Manager nicht möglich

Im CRS Alert-Log:

2017-05-03 11:38:41.769 [OCRCHECK(6846)]CRS-1006: The OCR location +OCRVOTE/s-sl-rac12/OCRFILE/registry.255.944323637 is inaccessible. Details in /u01/app/grid/diag/crs/server-a/crs/trace/ocrcheck_6846.trc.

Im Datenbank Alert-Log:

2017-05-03 11:42:01.202000 +02:00
NOTE: ASMB terminating
Errors in file /u01/app/oracle/diag/rdbms/rac1db/rac1db_2/trace/rac1db_2_asmb_6716.trc:
ORA-15064: communication failure with ASM instance
ORA-03113: end-of-file on communication channel
Process ID:
Session ID: 116 Serial number: 23322
Errors in file /u01/app/oracle/diag/rdbms/rac1db/rac1db_2/trace/rac1db_2_asmb_6716.trc:
ORA-15064: communication failure with ASM instance
ORA-03113: end-of-file on communication channel


1. Stoppen der Grid Infrastructure (GI) auf allen Knoten (als root-User)

[root@server-a:/]>crsctl stop crs -f

 

2. Starten der GI im exclusiven Modus nur auf einem Knoten (als root-User)

Als erstes muss die GI auf einem Knoten gestartet werden mit:

[root@server-a:/]>crsctl start crs -excl -nocrs


3. Diskgruppe OCRVOTE anlegen (als grid-User)

Aus der Sicherung der Meta-Daten kann ein SQL-Skript mit den Befehlen zur Definition der Diskgruppe erstellt werden:

[grid@server-a:]>
asmcmd md_restore /backup/md.full -S /tmp/md_ocrvote.sql -G ocrvote
Current Diskgroup metadata being restored: OCRVOTE


Inhalt des SQL-Skripts /tmp/md_ocrvote.sql

create diskgroup OCRVOTE NORMAL redundancy failgroup OCRVOTE1 disk 'ORCL:OCRVOTE1' name OCRVOTE1 size 5129M failgroup OCRVOTE3 disk 'ORCL:OCRVOTE3' name OCRVOTE3 size 5129M failgroup OCRVOTE2 disk 'ORCL:OCRVOTE2' name OCRVOTE2 size 5129M attribute 'compatible.asm' = '12.1.0.0.0', 'compatible.rdbms' = '12.1.0.0.0';
(..)
alter diskgroup /*ASMCMD AMBR */ OCRVOTE add directory '+OCRVOTE/s-sl-rac12';
alter diskgroup /*ASMCMD AMBR */ OCRVOTE add directory '+OCRVOTE/ASM';
alter diskgroup /*ASMCMD AMBR */ OCRVOTE add directory '+OCRVOTE/_MGMTDB';
alter diskgroup /*ASMCMD AMBR */ OCRVOTE add directory '+OCRVOTE/_MGMTDB/1E99393E59880E3CE053AB630A0A9EF0/TEMPFILE';
alter diskgroup /*ASMCMD AMBR */ OCRVOTE add directory '+OCRVOTE/_MGMTDB/FD9AC0F7C36E4438E043B6A9E80A24D5/DATAFILE';
alter diskgroup /*ASMCMD AMBR */ OCRVOTE add directory '+OCRVOTE/_MGMTDB/00054F0998EE6346E053AA630A0A66A3/TEMPFILE';
alter diskgroup /*ASMCMD AMBR */ OCRVOTE add directory '+OCRVOTE/_MGMTDB/FD9B43BF6A646F8CE043B6A9E80A2815/DATAFILE';

Das SQL-Skript kann jetzt editiert werden, gegebenenfalls müssen neue LUNs angegeben bzw. bei Verwendung von ASMLib der Disk-Header neu erstellt werden.


Nun kann das SQL-Skript mit Hilfe der ASM-Instanz ausgeführt werden:

SYS@+ASM1> @md_ocrvote.sql
(..)
Diskgroup created.

 

4. OCR Restore (als root-User)

Für den Restore OCR wird das vorher gesicherte OCR-File verwendet:

[root@server-a:/]>ocrconfig -restore /backup/backup00.ocr.287.943510705

Bei diesem Kommando gilt das Motto "Keine Meldung ist eine gute Nachricht"


5. Neuanlage der Voting Disks (als root-User)

Die Voting Disks werden folgendermaßen neu angelegt:

[root@server-a:/]>crsctl replace votedisk +ocrvote
Voting Disk 18bfe72b6cab4f8abff500d34cf39e89 wurde erfolgreich hinzugefügt.
Voting Disk 77a64e55b0724f7abfd4bcaedda10be8 wurde erfolgreich hinzugefügt.
Voting Disk c9ee4acb29bb4f5fbf444047a6e70cac wurde erfolgreich hinzugefügt.
Voting Disk-Gruppe wurde erfolgreich durch +ocrvote ersetzt.
CRS-4266: Voting-Dateien erfolgreich ersetzt


6. ASM-Parameterfile-Restore

Im GPNP-Profile (gebraucht für den Urstart der Clusterware) steht immer noch die Lokation in der OCRVOTE-Diskgruppe, obwohl sie dort nicht mehr existiert (als grid-User):

[grid@server-a:]>gpnptool get                                              
<.... SPFile="+OCRVOTE/../ASMPARAMETERFILE/registry.253.943698201" ....>


Deshalb die Sicherung zurückspielen mit dem -u Parameter (als grid-User):

grid@server-a:]>asmcmd spcopy -u /backup/asmparameterfile +ocrvote


7. Neustart GI auf einem Server (als root-User)

[root@server-a:/]>crsctl stop crs
[root@server-a:/]>crsctl start crs -wait


Es erscheint folgende Fehlermeldung im CRS Alert.log, da das GIMR neu angelegt werden muss:

CRS-5017: Bei Ressourcenaktion "ora.mgmtdb start" ist folgender Fehler aufgetreten:
ORA-01078: failure in processing system parameters
ORA-01565: error in identifying file '+OCRVOTE/_mgmtdb/spfile-MGMTDB.ora'
ORA-17503: ksfdopn:10 Failed to open file +OCRVOTE/_mgmtdb/spfile-MGMTDB.ora
ORA-15173: entry 'spfile-mgmtdb.ora' does not exist in directory '_mgmtdb'
ORA-06512: at line 4
. Weitere Einzelheiten finden Sie unter "(:CLSN00107:)" in "/u01/app/grid/diag/crs/server-a/crs/trace/crsd_oraagent_grid.trc".
CRS-2674: Starten von "ora.mgmtdb" auf "server-a" nicht erfolgreich
CRS-2679: Versuch, "ora.mgmtdb" auf "server-a" zu bereinigen
CRS-2681: Bereinigen von "ora.mgmtdb" auf "server-a" erfolgreich
CRS-6024: Starten der von Oracle Cluster Ready Services verwalteten Ressourcen ist abgeschlossen
CRS-4123: Oracle High Availability Services wurde gestartet.

 

8. GIMR neu anlegen (als grid-User)

Es empfiehlt sich hierzu das Utility MDBUtil aus MOS Doc ID 2065175.1 herunterladen. Vorher sollte die Ressource für die GIMR gelöscht werden:

[grid@server-a:]>srvctl remove mgmtdb -force


Anschließend das heruntergeladene Skript ausführen:

[grid@server-a:]>mdbutil.pl --addmdb --target=+OCRVOTE


Das MDBUtil hat folgenden Output:

2017-05-03 15:00:58: I Starting To Configure MGMTDB at +OCRVOTE...
2017-05-03 15:01:05: I Container database creation in progress...
2017-05-03 15:11:24: I Plugable database creation in progress...
2017-05-03 15:15:41: I Executing "/tmp/mdbutil.pl --addchm" on server-a as root to configure CHM.
root@server-a's password:
2017-05-03 15:23:00: I Starting To Configure CHM...
2017-05-03 15:23:03: I CHM Configure Successfully Completed!


Ein Blick auf die Ressource:

[grid@server-a:]>srvctl status mgmtdb
Database is enabled
Instance -MGMTDB is running on node server-a


9. GI auf den anderen Knoten starten (als root-User)

Bei userem Beispiel-Cluster handelt es sich um einen 2-Knoten-Cluster, deshalb ist nur der Start auf dem "server-b"-Knoten erfoderlich:

[root@server-b:/]>crsctl start crs -wait


Folgende Fehlermeldung kann sich im CRS Alert-Log (vor allem bei der FLEX ASM Architektur) befinden, wenn das ASM-Passwortfile noch nicht zurückgesichert wurde:

CRS-4123: Von Oracle High Availability Services verwaltete Ressourcen werden gestartet
(..)
2017-05-03 15:40:57.821 [ORAROOTAGENT(25476)]CRS-5019: Alle OCR-Speicherorte befinden sich auf ASM-Datenträgergruppen [OCRVOTE]. Keine dieser Datenträgergruppen ist gemountet. Einzelheiten finden Sie unter "(:CLSN00140:)" in  "/u01/app/grid/diag/crs/server-b/crs/trace/ohasd_orarootagent_root.trc".

 

10. ASM-Passwort-File zurücksichern (als grid-User)

Das gesicherte ASM-Passwort-File folgendermaßen zurückkopieren:

[grid@server-a:]>
asmcmd pwcopy --asm /backup/asmpasswortfile +ocrvote/orapwasm
copying /backup/asmpasswortfile -> +ocrvote/orapwasm

 

11. Überprüfen der Cluster-Services

Zuletzt sollten noch die Cluster-Services überprüft werden mit (als grid-User):

[grid@server-a:/]>crsctl status res -t -w "STATE = OFFLINE"
[grid@server-a:/]>crsctl status res -t

 

Fazit

Mit der Sicherung der beschriebenen Oracle 12c Real Application Clusters Komponenten und der testweisen Durchführung eines Worst-Case-Szenarios kann der Aufwand für die Wiederherstellung der Cluster-Diskgruppe stark minimiert und die Verfügbarkeit eines Cluster-Systems dadurch deutlich erhöht werden.

Diese und weitere spannende Dinge rund um den Real Application Clusters lernen Sie in unserem RAC 12c Kurs kennen. Schauen Sie sich doch einfach einmal auf unseren Schulungsseiten um.

 

Hinweis

Wie im letzen Monatstipp versprochen, finden alle, die an der Überwachung ihrer Alert-Datei unter Linux interessiert sind, hier den entsprechenden Beitrag.

Suche

Kontakt

IT-Consulting:

  Witneystraße
    089 6228 6789-0

Schulungszentrum:

  Grünwalder Weg
    089 679090-40

E-Mail Verteiler Monatstipps

Bitte nehmen Sie mich in den Verteiler der monatlichen Tipps & Tricks auf.