Von Non-CDB zur PDB innerhalb eines Releases - mit dem Autoupgrade-Tool
Wat mutt, dat mutt
Datenbankreleases nach 19c und ihre Folgen
Inzwischen ist so ziemlich jedem bekannt, dass die Releases nach 19c nicht mehr mit einer klassischen, also Non-CDB-Datenbankarchitektur supported sind. Sie lassen sich übrigens auch als solche nicht mehr erstellen. Wer dazu ein offizielles Statement möchte, findet dieses in der Dokumentation zu 21c. Die Version 21c ist das Folgerelease zur 19c, eine Version 20c wird es nicht geben (siehe Release Schedule in MOS).
Damit ist es nun höchste Eisenbahn, sich mit der CDB-Architektur zu beschäftigen und die Datenbanken aus einer Non-CDB Architektur in eine Containerdatenbankarchitektur zu überführen. Zumindest testweise, damit dann bei einer Migration zu einem Release nach 19c kein zusätzlicher Aufwand entsteht und man für die Migration entsprechend vorbereitet ist.
Wege, wie man zu einer PDB kommt, gibt es diverse. Der für mich persönlich einfachste ist es, das Autoupgrade-Tool dafür zu verwenden.
Vorteil des Autoupgrade-Tools
Einfach einfach.
Der größte Vorteil des Autoupgrade-Tools ist, es ist einfach. Einfach einfach. So wirklich einfach.
Selbst - oder gerade - wenn man es nicht für einen Upgrade von Release X nach Release Y verwenden möchte, sondern nur, um eine Non-CDB Datenbank in eine PDB zu verwandeln. Es benötigt dazu, im Vergleich zur manuellen Vorgehensweise weniger manuelle Schritte und, was für mich noch wichtiger ist, ich muss mich nicht durch die PDB_PLUG_IN_VIOLATIONS view durcharbeiten, sondern bekomme alles im sehr guten Log des Autoupgrade-Tools aufgeschlüsselt.
Die Vorbereitung
Was benötigt man also, um das Autoupgrade-Tool für eine Konvertierung der Datenbank zu nutzen?
- Eine aktuelle Version des Autoupgrade-Tools selbst, das aus der MOS Note 2485457.1 herunterladbar ist.
- Eine Non-CDB, die man in eine PDB umwandeln möchte.
- Des weiteren benötigt man auch eine (leere) CDB, in die man die Non-CDB dann "ein-pluggen" kann.
- Die Dokumentation des Autoupgrade-Tools, die zur jeweiligen Version passt. Wobei die Dokumentation zum Teil noch verbesserungswürdig ist.
- Grundsätzlich würde ich auch einen Blick in den Blog von Mike Dietrich empfehlen. Aber auch hier können Dinge beschrieben sein, die noch nicht offiziell supported sind. Im Zweifel also wirklich die Dokumentation zurate ziehen, denn oftmals funktionieren Dinge schon/anders, die so nicht offiziell supported sind.
- Unter MS Windows unbedingt die Rechte in den Foldern beachten - insbesondere bei Virtual Accounts kommt es hier zu Problemen beim Lesen der xml-Datei, die für die Erstellung der PDB notwendig ist. Unter Linux sind die Datenbanken normalerweise immer als Benutzer "oracle" installiert, deshalb tritt das Problem nicht auf.
Zu guter Letzt benötigt es noch eine Konfigurationsdatei. Die folgenden Inhalte sind wichtig (bzw. non-default, wenn man das Sample erstellt):
- sid: Die SID der Non-CDB Datenbank
- source_home und target_home: Da das Plugin ja innerhalb der gleichen DB-Version stattfinden soll, wird hier sinnvollerweise auch das Home gleich gesetzt sein.
- log_dir: Beschreibt den Ort, an dem das Autoupgrade-Tool die Logs ablegen soll.
- target_cdb: die SID der CDB, in die die Non-CDB hineingeplugt werden soll
- (target_pdb_name): Wie soll die Non-CDB dann als PDB heissen - Vorsicht ist hier angebracht, laut Dokumentation des Autoupgrade-Tools in Version 21 soll das nicht unterstützt sein. Ich habe das getestet, mehr im Verlaufe des Posts.
- target_pdb_copy_option: Sollen die Dateien der Non-CDB kopiert werden und wenn ja, wie soll die Dateinamenskonvertierung aussehen.
Hier mal ein Beispiel meiner Konfigurationsdatei, mit der ich getestet habe.
Die Non-CDB to PDB Konvertierung
Job starten - dann warten
Wenn man nun die Non-CDB Konvertierung startet (mit Aufruf des Autoupgrade-Tools mit der angelegten Konfigurationsdatei und dem Schalter "deploy"), überspringt das Tool die sonstigen Phasen (also Check, Pre-Fix, Upgrade, Post-Fix) und geht direkt in die Konvertierungsphase NONCDBTOPDB über. Sollte ein Problem (unter MS Windows) mit dem Lesen der XML-Datei (befindet sich in den Log Ordnern, siehe "Zusätzliche Informationen" im Screenshot) auftreten, so liegt sicherlich eine fehlerhafte Berechtigung auf Dateiebene vor - wenn beide Datenbanken als "Lokales System" als Dienst laufen, sind die Dateiberechtigungen in Ordnung. Wichtig ist es auch, die Logverzeichnisse bzw. Logs im Auge zu behalten, da hier der Fortschritt kontrolliert werden kann und sollte.
Das für mich wichtige Log ist in diesem Falle das "createpdb_edm_EDMPDB.log". In diesem findet man den aktuellen Fortschritt der Konvertierung und ggfs. auch Fehler.
Was man z. B. schön sieht, ist der Aufruf des "create pluggable database" statements. Obwohl in der Dokumentation zum Autoupgrade 21c steht, dass eine Namenskonvertierung nicht möglich sei, hat diese trotzdem funktioniert. Es kann allerdings sein, dass dies nicht in allen Fällen so ist und hier ggfs. ein Fehler geworfen wird. Sinnvoll ist es, hier ein tail -f (unter MS Windows z.B. mit dem Notepad++ möglich) mitlaufen zu lassen.
An dieser Stelle sei noch ein weiterer Hinweis gegeben. Bei einer Konvertierung wird der compatible Parameter >= 12.2 erwartet. In meinem Fall ist dieser noch auf 12.1.0.2 gesetzt, obwohl die Datenbank schon die 19c Binaries benutzt. Dies bedeutet dann, dass dieser für die Konvertierung im Hintergrund durch das Tool hoch gesetzt wird.
Der folgende Screenshot (aus dem Log) zeigt übrigens die Build Version, welche Target Versionen unterstützt sind (supported_target_versions), die Deploy-Option "SameVerPDB" und den Stand der compatible Parameter sowie der dbname, die Edition und die Version der Binaries (dbVersion).
Interessant ist übrigens auch, dass das Autoupgrade-Tool weitere Parameter in den Logs dokumentiert, z.B. ob das System ein Cluster ist oder ob TNS-Admin-Verzeichnisse gesetzt sind.
Wenn es mal länger dauert...
Während meiner doch inzwischen sehr zahlreichen Tests habe ich schon einige Konstellationen erlebt, die mit der Größe der Fast Recovery Area zu tun haben. Bei den Tests mit der Konvertierung ist nun ein zusätzliches "Problem" aufgetreten. Nach einiger Zeit gab es keine CPU-Last mehr durch das Oracle Executable auf dem Windows Server. Es gab dann auch keinen Log-Fortschritt mehr in den Autoupgrade-Logs. Das gesamte System hing irgendwo in der Plugin-Phase beim Ausführen von SQL-Skripten fest. Nach einiger Zeit habe ich dann herausgefunden, dass die FRA von der Konfiguration her zwar nicht belegt war, aber schlichtweg die Disk voll. Dies führte dazu, dass kein Log Switch mehr möglich war, denn zum Kopieren der Archive Logs war eben kein Platz vorhanden. Nachdem dieses Problem bereinigt war, ging das Plugin aber von selbst weiter. Ein kleiner Tipp am Rande ist deshalb, prüfen Sie immer, ob in der FRA und für die Archive Logs genug Platz vorhanden ist.
Die CPU sollte während der Plugin-Phase eine deutliche Last zeigen.
Job Completed
Nach einiger Zeit (in meinem Fall waren das aufgrund der Probleme mit den Archive Logs etwa 1,5h) sollte der Job dann erfolgreich beendet sein. Wird er nicht erfolgreich beendet, sind die ausgezeichneten Logs die erste Anlaufstelle. Hier ist sehr detailliert erkennbar, wo der Fehler aufgetreten ist. Wie bei den manuellen Plugins sind diese hauptsächlich in Fehlern in den installierten Datenbankoptionen oder z.B. bei APEX zu suchen.
Ein letzter Check über die v$container-View zeigt dann, die Datenbank ist nun mit neuem Namen als PDB konvertiert und geöffnet. Hier können ggfs. Nacharbeiten anstehen (z.B. oratab pflegen, Service-Namen setzen, TNSNames anpassen, MS Windows Dienste zurücksetzen auf (virtuellen) Account, alten DB Dienst aus MS Windows löschen, etc.).
Zusammenfassung
Mit relativ wenigen Handgriffen und ohne viele SQL Abfragen lässt sich eine Non-CDB Datenbank in eine PDB konvertieren. Dazu genügt es, neben dem aktuellen autoupgrade.jar eine Konfigurationsdatei zu erstellen und mit dieser autoupgrade.jar zu starten. Die dabei auftretenden Fehler sind bei mir bisher allesamt nicht auf das autoupgrade-Tool zurückzuführen gewesen, sondern wären bei manueller Vorgehensweise auch aufgetreten. Mit einer Suche in Google oder bei My Oracle Support sind diese im Normalfall schnell behoben.
Wer also auf einer Testumgebung mit der Konfiguration eine erfolgreiche Non-CDB nach PDB Konvertierung durchführen konnte, kann sich auch überlegen, diese Konvertierung dann auf anderen Systemen zeitgesteuert und parallel durchzuführen. Die mir immer recht mühsam empfundene, manuelle Tätigkeit der Erstellung des XMLs, des Plugins und der Checks nimmt einem das Autoupgrade-Tool also gekonnt ab. Mit ensprechender Vorbereitung (Prüfung auf die installierten Komponenten und Patchstände) lässt sich eine Konvertierung damit in 10 Minuten manuellem Aufwand und 45 Minuten Warten erledigen. Genau die richtige Länge, um sich die Wiederholung eines Webcasts anschauen zu können.
Kommentare
|
Sehr schöner Beitrag Jörg! Das macht mir gerade mehr Mut, auch mal das Autoupgrade Tool weiter auszuprobieren. Besten Dank und gesundes neues Jahr!