Mit Oracle 12c werden die zu einem Patch gehörenden SQL-Befehle nicht mehr mit [inlinecode]catbundle.sql[/inlinecode] installiert sondern mit dem Tool „datapatch“, was sich ebenfalls im OPatch Verzeichnis befindet. Im Gegensatz zum [inlinecode]catbundle.sql[/inlinecode] prüft datapatch vorher ab, ob die Voraussetzungen für die Installation erfüllt sind und ob es überhaupt notwendig ist, die SQL Befehle auszuführen. Außerdem wird ggf. geprüft, ob sich die Datenbank im Upgrade Modus befindet. Das Ergebnis des „SQL Apply“ kann dann über die View [inlinecode]dba_registry_sqlpatch[/inlinecode] abgefragt werden, z.B. in folgender Form:
SQL> SELECT patch_id, version, status, bundle_id, bundle_series
FROM dba_registry_sqlpatch;
Wenn man sich datapatch etwas detaillierter anschaut, dann stellt man fest, dass es sich um einen Link auf das Skript sqlpatch im Verzeichnis[inlinecode]$ORACLE_HOME/sqlpatch[/inlinecode] handelt. Und dieses Skript ruft wiederum ein Perl skript mit dem Namen [inlinecode]sqlpatch.pl[/inlinecode] auf.
Im Verzeichnis [inlinecode]sqlpatch[/inlinecode] findet man Unterverzeichnisse mit den einzelnen Patchnummern und unter diesen (bzw. unter einem weiteren Unterverzeichnis) liegt dann das [inlinecode]apply[/inlinecode] und das [inlinecode]rollback[/inlinecode] SQL-Skript für den jeweiligen Patch.
- Datenbank stoppen
- [inlinecode]opatch apply[/inlinecode] aufrufen
- Datenbank starten
- [inlinecode]datapatch [-verbose][/inlinecode] aufrufen
- fertig
Alternativ kann man auch [inlinecode]opatchauto[/inlinecode] aufrufen, da dieses sowohl das [inlinecode]opatch[/inlinecode] als auch das [inlinecode]datapatch[/inlinecode] nacheinander ausführt.
Das sieht im ersten Moment ziemlich einfach und sehr durchdacht aus und funktioniert auch wirklich gut. Allerdings gibt es einen Haken: beim Upgrade einer Datenbank mit dem DBUA wird das [inlinecode]datapatch[/inlinecode] nicht automatisch ausgeführt. Mike Dietrich hat in seinem Blog bereits auf die Probleme hingewiesen (und ich habe das ebenfalls ein dem Blog Oracle 12c DBUA und Datapatch festgehalten).
Bislang hatte ich angenommen, dass dieses Problem nur beim DBUA auftritt, dem ist aber nicht so. Es ist einzusehen, dass, wenn man mit dem [inlinecode]DBCA[/inlinecode] eine Datenbank aus einem Template erstellt, es notwendig sein kann, [inlinecode]datapatch[/inlinecode] auszuführen, weil das Template ja die Patches noch nicht enthält. Nicht klar ist allerdings, warum dass auch beim Neuanlegen einer Datenbank mit einer „Custom Database“ notwendig ist. Ich war davon ausgegangen, dass die „falschen“ SQL Skripte nach dem Patchen durch neue ersetzt wurden. Dem ist aber nicht so!
Das Oracle Support sagt dazu: „It’s not a bug, it’s a feature”, nachzulesen im Bug 19920083: DBCA NOT RUNNING DATAPATCH AFTER DATABASE IS CREATED.
Überprüfen kann man die erfolgreiche Installation der Patches dann wieder über die View [inlinecode]dba_registry_sqlpatch[/inlinecode], z.B. in dieser Form:
SQL> SELECT patch_id, version, status, bundle_id, bundle_series
FROM dba_registry_sqlpatch;
PATCH_ID VERSION STATUS BUNDLE_ID BUNDLE_SERIES
---------- -------------------- --------------- ---------- ----------------
20831110 12.1.0.2 SUCCESS 4 PSU
Ich kann an dieser Stelle nur dazu raten, diesen [inlinecode]SELECT[/inlinecode] Befehl in jeder 12c Datenbank auszuführen, um sicherzustellen, dass Patches nicht nur installiert sondern auch in der Datenbank angewendet worden sind.
Bei einer Multitenant Datenbank wird datapatch automatisch für alle Pluggable Databases ausgeführt, die zum Schreiben geöffnet sind und auch für die PDB$SEED. Das bedeutet natürlich auch, dass Sie sicherstellen müssen, dass alle PDBs geöffnet sind. Aber Sie müssen für PDBs, die Sie im Weiteren aus dem Template anlegen, kein datapatch ausführen.
Nachtrag vom 25.04.2016
Mit dem PSU 5 vom Oktober 2015 wird der patch beim Neuanlegen einer Datenbank automatisch mit installiert, d.h. man muss datapatch jetzt nicht mehr explizit aufrufen! Merkwürdig ist es allerdings, dass mit dem Erscheinen von PSU 160119 vom Januar 2016 zwar der PSU 5 automatisch installiert wird, nicht jedoch der PSU 160119! Also kann die Empfehlung nur lauten:
auf jeden Fall nach einer Neuinstallation einer Datenbank bzw. nach einem Upgrade Datapatch ausführen!
Nachtrag vom 30.03.2020
Oracle hat mit der Version 18 (also nicht mit 12.2) die Spalten der View dba_registry_sqlpatch geändert. Die obige Abfrage wird daher nicht mehr funktionieren. Statt dessen kann man folgende Abfrage benutzen:
SQL> SELECT patch_id, patch_type, status, description
FROM dba_registry_sqlpatch;
PATCH_ID PATCH_TYPE STATUS DESCRIPTION
---------- ---------- ----------- --------------------------------------------------------
29834717 RU SUCCESS Database Release Update : 19.4.0.0.190716 (29834717)
30557433 RU SUCCESS Database Release Update : 19.6.0.0.200114 (30557433)