Blog 
Oracle 12c Datapatch

Mit Oracle 12c werden die zu einem Patch gehörenden SQL-Befehle nicht mehr mit catbundle.sql installiert sondern mit dem Tool „datapatch“, was sich ebenfalls im OPatch Verzeichnis befindet. Im Gegensatz zum catbundle.sql 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 dba_registry_sqlpatch 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$ORACLE_HOME/sqlpatch handelt. Und dieses Skript ruft wiederum ein Perl skript mit dem Namen sqlpatch.pl auf.

Im Verzeichnis sqlpatch findet man Unterverzeichnisse mit den einzelnen Patchnummern und unter diesen (bzw. unter einem weiteren Unterverzeichnis) liegt dann das apply und das rollback SQL-Skript für den jeweiligen Patch.

  1. Datenbank stoppen
  2. opatch apply aufrufen
  3. Datenbank starten
  4. datapatch [-verbose] aufrufen
  5. fertig

Alternativ kann man auch opatchauto aufrufen, da dieses sowohl das opatch als auch das datapatch 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 datapatch 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 DBCA eine Datenbank aus einem Template erstellt, es notwendig sein kann, datapatch 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 dba_registry_sqlpatch, 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 SELECT 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)

Keine Kommentare zu “Oracle 12c Datapatch

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Was kann CarajanDB für Sie tun?