Release Updates einspielen mit Autoupgrade – Erfahrungen

Ich bin ein großer Freund von Out-of-Place-Patching. Parallel zum laufenden Betrieb kann man neue Software installieren, das verkürzt die Auszeiten. Zudem sammeln sich im ORACLE_HOME-Verzeichnis nicht so viele alte Patches an, das Verzeichnis .patch_storage bleibt angenehm klein.

Wenn man RUs mit AutoUpgrade und Out-of-Place-Patching einspielt, dann hat man für die häufigere RU-Installation und den eher selteneren Versionsupgrade ein ähnliches Verfahren. Das macht das Leben einfacher.

Nach meinem ersten Post zum Thema „Einspielen von Release Upgrades mit Autoupgrade“, bei denen ich das Verfahren in einer kleinen Testumgebung getestet hatte, kommen jetzt ein paar Erfahrungen aus dem Alltag mit größeren Umgebungen.

Rollback von alten Patches

Das Zurückrollen von älteren Patches kann Vorraussetzung für das Einspielen von weiteren Patchen sein.

Die dafür notwendigen Skripte liegen im Vezeichnis $OLD_ORACLE_HOME/sqlpatch.
Wenn die Datenbank-Instanz aus dem neuen ORACLE_HOME heraus gestartet wurde und DataPatch die alten Patches dann zurückrollen will, findet es die dafür notwendigen Skripte nicht.
Das Ergebnis ist ein „PREVENT_EMPTY_DATAPATCH_DIRECTORY_ERROR“-Fehler.

Lösung:

Vorher die SQL-Skripte in das neue Oracle-Home kopieren:

cp -r $OLD_ORACLE_HOME/sqlpatch/* $NEW_HORACLE_HOME/sqlpatch/.

Dieses Problem kann natürlich auch auftreten, wenn man Out-Of-Place-Patching ohne AutoUpgrade macht.

Datenbank im Upgrade-Modus

AutoUpgrade ist ein Upgrade-Tool und startet die Datenbank vor der Ausführung der diversen SQL-Skripte im UPGRADE-Modus. Für den Upgrade ist das OK. Bei Release-Upgrades führt das aber seit RU 19.18 zu einem Problem. Die Einspielung bricht mit dem Fehler „ORA-13516: AWR Operation failed: CATPROC not valid“ab.

Lösungsmöglichkeiten:

1. zusätzlich Patch 35012866 einspielen, wenn man den RU 19.18 mit AutoUpgrade installieren will.
2. RU 19.19 oder höher einspielen

Wenn man den Patch 35012866 bei der Installation des RU 18.18 nicht eingespielt hat, dann hat man nachdem Autoupgrade abgebrochen ist, viele ungültige Objekte und Komponenten in der Datenbank. Lösung dafür:

1. $ORACLE_HOME/rdbms/admin/utlrp.sql in allen Containern laufen lassen
2. Datapatch wiederholen

Ggf. müssen diese beiden Schritte mehrfach wiederholt werden.

NLS_LANG

Ein weiteres Problem hatte ich, weil auf meinem Kundensystem ein Patch installiert war, der nur mit NLS_LANG=American_America.AL32UTF8 eingespielt werden konnte Daher konnte er auch nur mit der gleichen NLS-Einstellung deinstalliert werden. Ansonsten: Fehler ORA-6502 „numeric or value error“ – Anscheinend hat da wohl ein Entwickler ein numerisches Trennzeichen fest verdrahtet. NLS_LANG=American_America.AL32UTF8 ist ohnehin meine empfohlene NLS-Einstellung (mit englischsprachigen Fehlermeldungen finden die Suchmaschinen mehr), aber bei meinem Kunden war NLS_LANG auf German_Germany.AL32UTF8 gesetzt. Ergebnis: Autoupgrade bricht beim Rollback ab. Auf meine Liste der Vorbereitungen bevor ich Autoupgrade ausführe kommt daher:

export NLS_LANG=American_America.AL32UTF8

Sicher ist sicher.

MOS-Notes:

• 2380601.1 – Database Preupgrade tool (via autoupgrade.jar) check list
• 2922690.1- 19.x:datapatch failed with ‚ORA-13516: AWR Operation failed: CATPROC not valid ‚