ORA-27140 nach Dataguard Switchover

Es werden mehrere Datenbanken in einem gemeinsamen Oracle Home (Oracle 12c) betrieben. Um die geforderte Hochverfügbarkeit zu erreichen, wird jede diese Datenbanken durch Dataguard an einem anderen Unternehmensstandort abgesichert.

Es wird Oracle Grid Infrastructure in einer Oracle-Restart Konfiguration verwendet.

Zu Wartungszwecken wird eine der aus einem gemeinsamen Oracle Home betriebenen Datenbanken vom Standort Wichtighausen auf den Standort Notfallbrunn umgeschalten ("Switchover" mittels Dataguard Broker).

Unmittelbar nach erfolgreicher Umschaltung können sich die Anwender nicht mehr an die in Wichtighausen verbliebenen Primär-Datenbanken anmelden bzw. auf die Daten zugreifen.

In den Alert-Logs finden sich folgende Fehlermeldungen:

ORA-27140: attach to post/wait facility failed

	ORA-27300: OS system dependent operation:invalid_egid failed with status: 1

	ORA-27301: OS failure message: Operation not permitted

	ORA-27302: failure occurred at: skgpwinit6

	ORA-27303: additional information: startup egid = 1001 (oinstall), current egid = 1002 (dba)

Was hat das mit Dataguard zu tun?

Zuerst konnten wir keinen ursächlichen Zusammenhang mit dem Dataguard Switchover feststellen, es wurde in Wichtighausen ja nur die ehemalige Primär-Datenbank gestoppt und als Standby-Datenbank neu gestartet.

Aufgrund der Fehlermeldungen im Alert-Log (insbesondere ORA-27303) haben wir in die Richtung "File-Ownership" weitergesucht und sind auch bald fündig geworden.

Der Oracle User, der sowohl für die Installation von Oracle Grid Infrastructure (Oracle Restart) als auch für die Datenbank-Installation verwendet wurde, hat als Primary Group "oinstall" festgelegt.

Die Oracle-Binaries ($ORACLE_HOME/bin/oracle) hatten quer durch die ganze Konfiguration (es werden mehrere Oracle Homes betrieben) unterschiedliche "Group-Ownership", entweder "oinstall" oder "dba".

Was ist in diesem Umfeld nun richtig - "oinstall" oder "dba"?

Entscheidend für die korrekte "Group-Ownership" ist die sog. "ASM (DBA) Group", die bei der Installation der Oracle Grid Infrastructure (Oracle Restart) festgelegt wird.

Diese kann auch im nachhinein aus der Datei $ORACLE_HOME/rdbms/lib/config.c ermittelt werden ($ORACLE_HOME ist in diesem Fall das Oracle Home für die Oracle Grid Infrastructure):

...

	.Lasm_string: .string "dba"

	...

	#define SS_ASM_GRP "dba"

	...

(Anmerkung: config.c ist ein Hybrid aus Assembler- und C-Code)

Mit dieser Information wurde uns auch klar, was zum Problem geführt hat.

Alle Instanzen aus dem betreffenden Oracle Home wurden mit einem Oracle-Binary ($ORACLE_HOME/bin/oracle) mit der "Group-Ownership" "oinstall" gestartet - wir vermuten, dass möglicherweise Probleme / Fehler beim Patchen des Oracle Home zu dieser "Group-Ownership" geführt haben.

Das ist in dieser Konfiguration (Oracle Exadata) vorerst kein Problem, da die ASM Diskgruppen auf den Cell-Servern auch mit einer "falschen" "Group-Ownership" erreichbar sind.

Wird allerdings eine Datenbank mit Hilfe von Oracle Grid Infrastructure (Oracle Restart) gestartet, z.B. mit srvctl start database, so prüft die Oracle Grid Infrastructure die "Group-Ownership" und korrigiert diese gegebenenfalls (in unserem Fall auf "dba") - leider wird nicht geprüft, ob das Oracle-Binary ($ORACLE_HOME/bin/oracle) gerade in Verwendung ist, z.B. durch andere Datenbank Instanzen.

Wird eine Datenbank mit sqlplus gestartet, erfolgt weder eine Prüfung noch eine Anpassung.

Wird die "Group-Ownership" des Oracle-Binary ($ORACLE_HOME/bin/oracle) während der Laufzeit einer Instanz geändert, kommt es zu gravierenden Problemen beim Zugriff auf das Shared Memory Segment der Instanz.

Auch beim Switchover mittels Dataguard Broker wurde die Instanz der ehemaligen Primär-Datenbank in Wichtighausen durch die Oracle Grid Infrastructure gestartet, das führte zu den o.a. Problemen.

Was haben wir daraus gelernt?

nach dem Patchen eines Oracle Home immer auch die Permission / Ownership des neuen Oracle-Binary ($ORACLE_HOME/bin/oracle) prüfen
im Oracle Grid Infrastructure Umfeld - wenn möglich - primär die Tools der Oracle Grid Infrastructure zur Administration der Datenbank verwenden

Achtung: Falls die "Group-Ownership" des Oracle-Binary ($ORACLE_HOME/bin/oracle) manuell geändert wird (z.B. mit chown oder chgrp) gehen die "Stick-Bits" der "File-Permission" verloren. Dies lässt sich mit

chmod 6751 $ORACLE_HOME/bin/oracle

leicht beheben.

Breadcrumb