Aber aus Security- und Compliance-Gründen ist Patching auf ein aktuelles Release dringend angeraten. Das gilt insbesondere für Produktionsumgebungen, um diese beispielsweise vor destruktiven Hackerangriffen zu schützen.
In der Praxis migrieren viele Kunden auf das Oracle Release 19c. Oft spielt die Überlegung mit, dass gleich in eine Multitenant-Umgebung gewechselt wird. Nach 19c ist Multitenant die einzige von Oracle unterstützte Architektur, deshalb ist das eine gute Idee.
Kann und sollte man eine pluggable Database (PDB) patchen? Es gibt neue Features von Oracle 21c, die in einzelnen RUs (Release Update Patches) verfügbar gemacht werden (backported), zum Beispiel Macros oder SEHA.
Hier möchte ich ein wenig Hilfestellung geben. Die Installation einer leeren (empty) CDB in einem neuen ORACLE_HOME (hier für CDB2) und das anschließende Patchen mit dem aktuellen RU kann unabhängig von der Produktionsumgebung erfolgen.
Nun muss nur noch eine PDB aus dem alten ORACLE_HOME (CDB1) in das neue ORACLE_HOME (CDB2) übertragen werden. Dazu gibt es verschiedene Übertragungsmöglichkeiten, zum Beispiel:
- Unplug der PDB aus CDB1 in ein xml- oder pdb File und Plugin in CDB2. Vor Ausführung des unplug-Kommandos muss die Quell-PDB geschlossen werden.
- Cloning im Refreshable-Modus MANUAL: Quell-PDB muss nicht geschlossen werden. Das Cloning erfolgt über einen Datenbank-Link. Änderungen können nachgezogen werden, bis der Refresh-Modus beendet und die PDB in CDB2 geöffnet wird.
- Cloning im Refreshable-Modus AUTOMATIC: Quell-PDB muss nicht geschlossen werden. Das Cloning erfolgt über einen Datenbank-Link. Änderungen werden nach vorgegebener Zeit automatisch nachgezogen, bis der Refresh-Modus beendet wir und die PDB in CDB2 geöffnet wird.
Hinweis zum Refresh: Das Refresh erfolgt ausschließlich in der Mount-Phase, das heißt falls die PDB read-only geöffnet ist, so muss sie für das Refresh in die Mount-Phase gebracht werden.
4. Relocate PDB: Quell-PDB muss nicht geschlossen werden. Das Cloning erfolgt über einen Datenbank-Link. Die Quell-PDB in CDB1 bleibt solange geöffnet, bis diese PDB in CDB2 geöffnet wird. Dann wird die Quell-PDB in CDB1 automatisch gelöscht.
Nach dem Öffnen aller PDBs in CDB2 gibt es eine Fehlermeldung, weil die Patchlevel von CDB1 und CDB2 nicht identisch sind.
SYS@CDB2>alter pluggable DATABASE PDB open;
Warning: PDB altered with errors.
Nach der SQL-Abfrage nach den Fehlern, gibt es folgenden Hinweis (Auszug):
SYS@CDB2>select * from pdb_plug_in_violations;
PDB '19.12. ….is installed in the CDB but
'19.3. is installed in the PDB
PENDING Call datapatch to install in the PDB or the CDB
Jetzt muss nur noch das datapatach aus dem aktuellen RU angewendet werden. Dabei werden alle notwendigen Änderungen mit SQL angewendet.
Falls die PDBs bereits das richtige Patchlevel haben, so werden diese von datapatch ignoriert.
$ cd $ORACLE_HOME/OPatch/
$ OPatch]$ ./datapatch
Eventuell muss noch das Recompile von Objekten ausgeführt werden.
SYS/PDB>@ $ORACLE_HOME/rdbms/admin/utlrp.sql
Nach Beendigung wird die PDB geschlossen (sie ist RESTRICTED geöffnet) und wieder geöffnet. Innerhalb des gleichen Major Releases kann mit geringen Ausfallzeiten eine PDB auf ein höheres Patchlevel gehoben werden. Bei der Auswahl der Methode spielt es auch eine Rolle, ob die Datenbank im alten Patchlevel noch vorhanden sein soll. Für alle hier vorgestellten Methoden gilt aber, dass eine kurze Ausfallzeit auftritt, wenn die PDB vom Restricted Mode (Öffnen nach datapatch) in den Open Mode wechselt.
Cornelia Heyde
DOAG Stellv. Themenverantwortung Database Monitoring, Stellv. Themenverantwortung Sicherheit
--
Bild von Julius Silver auf Pixabay
