Patch Set Updates mit opatchauto in Oracle 12c

Veröffentlicht am von

So war’s bisher

Bei der Installation eines neuen Oracle-Datenbank-Servers geht man gerne so vor, dass  zunächst die komplette Software inklusive aller Patches sowie des aktuellen PSUs installiert und erst dann die erste Datenbank angelegt wird. Dies hat den Vorteil, dass nach dem CREATE DATABASE keine Upgrade- oder sonstigen Aktualisierungs-Skripte mehr in der gerade fertiggestellten Datenbank ausgeführt werden müssen.

Bei RAC- oder Oracle Restart-Systemen bietet die Verwendung des Kommandos „opatch auto“, ausgeführt als root-User in der Grid-Infrastructure-Umgebung, die automatische Aktualisierung sowohl des GridInfra(GI)-, als auch aller vorhandenen Datenbank (DB)-Homes in einem Installationsschritt.

Kleines Problem in 11.2

Dies funktionierte auch in der Version 11.2 schon immer nur dann, wenn in einem installierten DB-Home auch wirklich eine Datenbank vorhanden war. Ansonsten wurde das GI-Home korrekt aktualisiert, das bzw. die DB-Home(s) jedoch ignoriert. Diese konnten dann im Anschluss durch den Befehl

opatch auto <unzipped_patch_location> -ocmrf ocm.rsp -oh <$ORACLE_HOME> [, <$ORACLE_HOME2>, … <$ORACLE_HOMEn>]

nachgezogen werden.

Etwas größeres Problem in 12c

Bei der gestrigen Erst-Installation des PSU1 für die GI Oracle 12.c fiel folgendes auf:

  1. opatch auto ist deprecated. Statt dessen gibt es nun den Befehl opatchauto apply.
  2. Die zuvor geschilderte Problematik beim gleichzeitigen Patchen von GI- und DB-Home bleibt jedoch die selbe.
  3. Der Versuch, ein „leeres“ DB-Home durch Hinzufügen des Parameters -oh $ORACLE_HOME doch zu patchen, schlägt nun fehl. Fehlermeldung: Unknown host name in config

Nach anfänglicher Verwirrung (wieso Hostname? DNS funktioniert doch? Und wieso ging das denn dann beim GI-Home…???) konnte das Problem identifiziert werden:

Bei Ausführung von opatchauto apply entsteht folgende Verzeichnisstruktur:

$GI_HOME/cfgtoollogs/opatchauto/<patch_number>. Hier werden diverse Log- und Konfigurationsdateien gespeichert; u.a. auch eine XML-Datei, die Aufschluss über den Server und das zu patchende Home gibt und offenbar während des Patch-Vorgangs ausgelesen wird. Weitere Dateien sind eine deploy.cfg.log, eine deploy.steps.log, eine deploy.log und eine deploy.debug.log. Jede Datei hat den Prefix <unzipped_patch_location>-yyyy-mm-dd-hh24-mi-ss; dieses Set an Dateien entsteht bei jedem Aufruf von opatchauto apply.

Und bei opatchauto apply -oh $DB_HOME ist die config.xml leer. Der Grund hierfür konnte nicht ermittelt werden; allerdings erklärt sich somit auch die zunächst überraschende Fehlermeldung. Ein Blick in die config.xml der PSU-Installation im GI-Home zeigt nämlich, dass hier in der Tat u.a. der Hostname aufgelistet wird.

Lösung

Die gute Nachricht ist: All die Probleme verschwinden, wenn eine Datenbank im DB-Home existiert. Wie von Zauberhand läuft dann das komplette opatchauto apply für GI und DB in einem Schritt durch. Die config.xml ist dann auch gefüllt. Empfehlung ist also: ab sofort auch bei neuen Servern immer erst die DB anlegen, dann erst das PSU einspielen. Ob dies bei den weiteren PSUs so bleibt, werden wir weiter beobachten!

Schreibe einen Kommentar