OPatch 11.2.0.3 eine Diva?

Martin Schmitter — Tue, 18 Sep 2012 12:17:00 GMT

In den letzten Tagen erreichen mich immer wieder Fragen zu Problemen mit dem OPatch auf Windows Systemen. Diese möchte ich zum Anlass nehmen, die bekanntesten Stolpersteine zu demonstrieren. Diese beziehen sich nur auf die Windows Version und treten so unter Linux und Unix Systemen nicht auf.

Grundsätzliche Anforderung für die Verwendung ist eine aktuelle OPatch Version, passend zum ORACLE_HOME. Diese kann im Oracle Support Portal heruntergeladen werden (OPATCH Placeholder Patch 6880880). Bei der Demonstration wird die Version 11.2.0.3 für x86-64 verwendet.

Vorbereitend für die Verwendung des OPatches ist darauf zu achten, dass man alle relevante Umgebungsvariablen setzt. z.B.:

set ORACLE_HOME=C:\app\oracle\product\11.2.0.3\db1
Set PATH= C:\app\oracle\product\11.2.0.3\db1\bin;C:\app\oracle\product\11.2.0.3\db1\OPatch;%PATH%

Einfacher geht es mit Unserem Tool TVD-BasEnv™
http://www.trivadis.com/produkte/datenbank-tools/tvd-basenvtm.html

Verwendet man mehrere ORACLE_HOMEs mit unterschiedlichen Versionen auf erster oder zweiter Stelle, kann es notwendig sein, auch das JAVA_HOME und PERL_HOME zu setzen.

Nach dem man Alles vorbereite hat und ans Patchen will, geht es dann auch schon los. Mal schauen was es denn schon so gibt:

Cmd>OPatch lsinventory

Und schon geht der Ärger los:

Der CLASSPATH

Cmd>OPatch lsinventory
Exception in thread "main" java.lang.NoClassDefFoundError: Files
OPatch failed with error code = 1
Cmd>

Wir sehen hier eine sehr aussagekräftige Fehlermeldung. Und Logfiles gibt es natürlich auch nicht. Wenn man es nicht schon kennt, sucht man bestimmt lange.

Das Problem wird im Oracle Dokument ID 1442459.1 beschrieben.

Auf dem System ist eine Java Runtime Environment 6 (JRE6) installiert. Für die JRE6 würde die Umgebungsvariable CLASSPATH gesetzt:

Cmd>set classpath
Cmd>CLASSPATH=.;C:\Program Files (x86)\Java\jre6\lib\ext\QTJava.zip

Oracle empfiehlt den Eintrag dauerhaft aus der System Umgebung zu entfernen. Da die Seiteneffekte für mich nicht überschaubar sind, nehme ich den Eintrag nur für das Command Window raus.

Cmd>set classpath=.;

Und schon geht es…

Cmd>OPatch lsinventory
Oracle Interim Patch-Installationsprogramm Version 11.2.0.3.0
Copyright (c) 2012, Oracle Corporation. All rights reserved. Alle Rechte vorbehalten.
Oracle Home       : C:\app\oracle\product\11.2.0.3\db1
Central Inventory : C:\Program Files\Oracle\Inventory
   from           : n/a
OPatch version    : 11.2.0.3.0
OUI version       : 11.2.0.3.0
Log file location : C:\app\oracle\product\11.2.0.3\db1\cfgtoollogs\opatch\opatch2012-09-05_16-32-41PM_1.log
Lsinventory Output file location : C:\app\oracle\product\11.2.0.3\db1\cfgtoollogs\opatch\lsinv\lsinventory2012-09-05_16-32-41PM.txt
-----------------------------------------------------------------------------
Oracle Database 11g                                                  11.2.0.3.0
In diesem Oracle-Standardverzeichnis sind 1 Produkte installiert.
In diesem Oracle-Standardverzeichnis sind keine Interim-Patches installiert.
-----------------------------------------------------------------------------
OPatch succeeded.

Die srvm.jar Datei

Nach dem wir einen Erfolgreichen OPatch lsinventory ausführen konnten, wollen wir nun endlich den Bundle Patch ausführen.

Cmd>OPatch apply
...

Following files are active:
C:\app\oracle\product\11.2.0.3\db1\oui\jlib\srvm.jar
C:\app\oracle\product\11.2.0.3\db1\oui\jlib\srvm.jar
C:\app\oracle\product\11.2.0.3\db1\oui\jlib\srvm.jar
C:\app\oracle\product\11.2.0.3\db1\oui\jlib\srvm.jar
C:\app\oracle\product\11.2.0.3\db1\oui\jlib\srvm.jar
C:\app\oracle\product\11.2.0.3\db1\oui\jlib\srvm.jar
C:\app\oracle\product\11.2.0.3\db1\oui\jlib\srvm.jar
C:\app\oracle\product\11.2.0.3\db1\oui\jlib\srvm.jar

...

Das Problem wird in Oracle Support Note ID 1446273.1 beschrieben.

Der OPatch Version 11.2.0.3 hat einen Bug. Workaround ist im Verzeichnis %ORACLE_HOME%\Opatch\jlib die Datei oracle.opatch.classpath.jar in z.B. oracle.opatch.classpath.jar1 um zu benennen.

Offene Dateien

Nach dem man alle Oracle Dienste vorschriftsmäßig gestoppt hat, bekommt man recht häufig doch noch die Meldung, dass Dateien noch im Zugriff sind. Als besonders hartnäckig zeigt sich hier unteranderem die oci.dll.

...
Following files are active:
C:\app\oracle\product\11.2.0.3\db1\bin\oci.dll
...

Häufig gibt es noch unentdeckte Oracle Prozesse die diese aufhalten. Diese kann man am besten mit einem Tool, den Process Explorer von Sysinternals, auf die Spur kommen. In der Suche gibt es eine Möglichkeit nach Prozessen zu suchen, die eine DLL im Zugriff haben.

An dem Beispiel sieht man sehr schön, dass der Distributed Transaction Coordinator Service auf die oci.dll zugreift und deswegen ein OPatch nicht laufen wird.

Ein weiterer guter Bekannter neben dem der Distributed Transaction Coordinator Service ist der Windows Management Instrumentation Service. Eine Besonderheit ist hier, dass ein einfaches Stoppen und setzen auf manuelles Starten nicht reicht. Der Service startet sehr schnell wieder neu. Es hat sich bewährt, den Service kurzzeitig zu deaktivieren.

Wenn man die paar kleinen Tricks kennt, ist OPatch ein zuverlässiges Werkzeug, um die Oracle Patche einzuspielen.

Viel Erfolg

ASM: Extended Disk Partitionen und der UEFI Bug auf Windows 2008 R2

Martin Schmitter — Fri, 18 Nov 2011 16:39:00 GMT

Immer häufiger kommt es zu der Anforderung bei der Installation von Oracle Datenbanken, dass auch ASM verwendet werden soll. Dabei bin ich auf einen Bug gestoßen der recht knifflig ist.

Für die Installation der ASM Disks muss man zunächst mittels Diskpart eine Extended Partition anlegen.

z.B.:

DISKPART> select disk 1
Disk 1 is now the selected disk.

DISKPART> online disk
DiskPart successfully onlined the selected disk.

DISKPART> attributes disk clear readonly
Disk attributes cleared successfully.

DISKPART> create part ext
DiskPart succeeded in creating the specified partition.

DISKPART> create part log
DiskPart succeeded in creating the specified partition.

Nach dem man dann die Disk mit asmtool(g) gestempelt hat und die ASM Instanz installiert hat, sowie mühevoll die DB installiert und konfiguriert hat, tut man das was man immer tut:

Reboot

Wenn das System dann nicht mehr booten will, könnte es an dem UEFI Bug liegen:

http://support.microsoft.com/kb/982929/en-US

http://support.microsoft.com/kb/2223832/en-US

Was ist passiert? Es gibt einen neuen Partitionstypen, die UEFI Partition. Wird nun eine Extended Partition erzeugt, wird diese fälschlicherweise als UEFI Partition erkannt. Das führt dazu, dass das Betriebssystem nicht mehr sauber booten kann.

Zum Leben erwecken kann man das System nur indem man die Disks von dem System trennt.

Abhilfe schafft der oben genannte Patch. Leider muss man diesen schon in die Setupmedien von Windows 2008 R2 einspielen, d.h. man muss das ganze OS noch mal neu aufsetzen.

Viel Spaß

Was ist eigentlich UEFI?: http://www.uefi.org/about/

Oracle@Windows

OPatch 11.2.0.3 eine Diva?

Der CLASSPATH

Die srvm.jar Datei

Offene Dateien

ASM: Extended Disk Partitionen und der UEFI Bug auf Windows 2008 R2