• Entwicklung/Architektur
  • Methoden
  • Programmiersprachen
• Betrieb
  • Datenbanken
  • Server
  • IT-Security
  • Speicher
  • Netzwerke
  • Virtualisierung
  • Verfügbarkeit
  • Künstliche Intelligenz
• Management und Recht
  • Projektmanagement
  • Digitalisierung
  • IT-Recht
  • IT-Selbständige
• Aktuelles
• Termine
• IT-Jobs

☰

• Entwicklung
• Betrieb
• Management und Recht
• News
• IT-Jobs
• Newsletter

David Pasternak 03. Mai 2022

Oracle: Clonen von PDBs auch aus NONCDBs als Feature-Beispiel für Multitenant

Mit Multitenant können angelegte Pluggable Databases, kurz PDBs, zu neuen PDBs geclont werden. Aber auch NonCDBs, also Datenbanken im Aufbau der klassischen Datenbankarchitektur, können mittels der Clonefunktion von einer NonCDB zu einer neuen PDB geclont werden. Und das sogar sehr einfach. Wie das geht, zeigt dieser Artikel.

Multitenant als die neue Datenbankarchitektur

Aber erstmal ein paar Grundlagen: Mit der Multitenant-Architektur ändert sich der Aufbau einer Oracle-Datenbank. Wichtig sind hierbei drei Begriffe:

CDB – Container Database

PDB – Pluggable Database

Gibt es in einer CDB nur eine PDB, spricht man auch von Singletenant. PDBs können aus einer CDB "unplugged" – also ausgehängt – und in eine andere CDB "plugged" – also eingehängt – werden. Oftmals stellt man daher PDBs mit kleinen USB-Sticks oder USB-Schnittstellen in schematischen Darstellungen dar.

NonCDB

Als NonCDB werden alle Datenbanken bei Oracle bezeichnet, die seit der Einführung der Multitenant-Architektur nicht nach dem Multitenant-Konzept aufgebaut sind. Klassischerweise sind dies Single-Datenbanken. RAC-Datenbanken können ebenfalls mit der Multitenant-Architektur aufgebaut werden, da RAC keine Datenbank-Architektur, sondern eine Hochverfügbarkeitsfunktion ist.

Für den Einsatz der Multitenant-Architektur sprechen 4 klare Vorteile

Mobilität

PDBs können aus einer CDB ausgehängt und in einer anderen CDB eingehängt, werden. Ebenfalls ist dadurch möglich, eine PDB recht einfach und schnell zu patchen. Ist die CDB, in die eingehängt werden soll, mit einem höheren Release-Upgrade oder Patch versehen, kann durch das Umhängen der PDB diese recht schnell auf das neue Release-Upgrade oder den Patch hochgezogen werden.

Aber auch das Clonen von PDBs, welches hier im Beitrag genauer erörtert werden soll, kann hier die Mobilität einer Infrastruktur erhöhen.

Lastverteilung

Durch das "Unpluggen" aus einer CDB und das "Pluggen" in eine andere, kann eine Lastverteilung zwischen Systemen durchgeführt werden. Ist eine CDB unter Last und beinhaltet nicht-systemkritische PDBs, können diese PDBs in eine andere CDB verschoben werden, die ggf. sogar auf einem anderen Server oder Cluster liegt.

Flexibilität

Durch das Verschieben und das Clonen von PDBs ist man in seiner Datenbanklandschaft flexibler aufgestellt als mit NonCDBs.

Aufgaben- und Zugriffstrennung

Da eine PDB standardmäßig nicht über die CDB auf andere PDBs zugreifen kann, erfolgt hier eine Mandanten- bzw. Anwendungstrennung. So sind nicht nur Zugriffe gesichert. Auch Wartungen können einfacher vonstatten gehen, da man nicht mehr die eine riesige NonCDB, auf die mehrere Anwendungen mit eigenen Schemata Zugriff haben, in Wartung nehmen muss, sondern gezielt einzelne PDBs warten kann.

Das Clonen von PDBs ist eine der effektivsten Funktionen der Multitenant-Architektur

Mit der Einführung der Multitenant-Architektur ist es möglich, die PDBs durch Clonen zu duplizieren oder sogar NonCDBs in PDBs zu konvertieren. Dadurch ergeben sich neue Möglichkeiten im Betrieb und in der Wartung von Datenbanken:

• Schnelle Bereitstellung von Test- und Entwicklungsstages aus dem Produktionsstand: Benötigt man für den aktuell geplanten Sprint oder zur Analyse eines Bugs eine separate Umgebung, wird der Stand der produktiv genutzten PDB schnell und einfach geclont und die Tests mit dem geclonten Stand durchgeführt.
• Testen eines neuen Applikationsstandes: Ist die genutzte Applikation als Testinstallation mit neuem Release zusätzlich aufgesetzt, lohnt es sich auch hier, dafür einen Clone aus der produktiven PDB bereitzustellen. Damit kann das neue Release separat getestet und abgenommen werden. Das Gleiche gilt für Oracle-Patches, die getestet werden müssen. Funktioniert alles, kann die geclonte PDB gleich als neue produktive PDB genutzt werden.
• Analyse von Performance-Problemen: Auch dafür baut man schnell und einfach mittels eines Clones der genutzten PDB ein Analysesystem auf.
• Rollback auf alten Stand: Ist etwas mit dem Patch der Anwendung oder dem Oracle-Release-Upgrade zusammen mit der Anwendung nicht in Ordnung, wechselt man einfach auf die QuellPDB zurück.
• Minimaler Wartungsaufwand: Das Clonen von PDBs ist live möglich, weshalb eine Downtime der zu clonenden PDB ist  nicht notwendig ist.
• Migrationswechsel der Architektur und des Major Release möglich: Durch das Clonen von PDBs kann auch ein Releasewechsel des Major Releases der Oracle-Datenbank unkompliziert durchgeführt werden. Der Migrationsvorgang der Architektur kann sogar mehrfach durchgeführt und damit verprobt werden.
• Replizieren von Datenbanken über RMAN Backups oder Datapump Exports entfällt: Im Vergleich zum Clonen von PDBs ist das Replizieren eines Datenstandes mittels RMAN Backup oder Datapump Export komplizierter und aufwändiger.

Damit erfolgreich geclont werden kann, müssen folgende Voraussetzungen erfüllt sein

Einige Voraussetzungen bringen das Clonen von PDBs und die Konvertierung von NonCDBs zu PDBs durch Clonen mit sich:

• Die Ziel-CDB muss vorab angelegt werden, wenn in eine neue CDB geclont werden soll.
• Die Quell-CDB oder NonCDB und die Ziel-CDB müssen mindestens auf Release 12.1.0.2 laufen.
• Die Quell-CDB oder NonCDB und die Ziel-CDB benötigen die gleiche Blockgröße.
• Für das Clonen im Livebetrieb muss die Quell-CDB oder NonCDB und die Ziel-CDB im Archivelogmode und mindestens auf Release 12.2.0.1 laufen.
• Datenbanken auf Release 12.1.x bzw. Datenbanken, die im Noarchivelogmode laufen, müssen in den Read-Only-Modus wechseln. Damit fällt eine Downtime an.
• Die genutzten Datenbankoptionen, wie Oracle Text oder Multimedia, müssen zwischen der Quell-CDB oder NonCDB und der Ziel-CDB die gleichen sein.
• Die Limitierung der Lizensierung der Multitenant-Option muss beachtet werden. Wurde Multitenant nicht zusätzlich mit der Enterprise-Edition-Lizenz eingekauft, so darf es maximal 3 PDBs in einer CDB geben (Template PDBs ausgeschlossen). Die Standard-Edition ist auf 3 PDBs pro CDB begrenzt, hier kann Multitenant nicht lizensiert werden. In bis zu 4 Schritten wird eine vorhandene PDB geclont.

Nachfolgend werden drei Szenarien dargestellt, wie PDBs geclont werden können. Zusätzlich zu den drei Szenarien werden zwei Upgradeszenarien gezeigt, die das Clonen von PDBs nutzen.

In bis zu 4 Schritten wird eine vorhandene PDB in der gleichen CDB geclont

Der Clonevorgang einer vorhandenen PDB in die gleiche CDB ist in maximal 4 Schritten erledigt: Läuft die zu clonende PDB in einer CDB mit Release ab 12.2 und im Archivelogmode, kann Schritt 1 und 4 weggelassen werden.

Die Quell-PDB wird erst, wenn es durch das Release oder den Noarchivelogmode notwendig ist, in den Read-Only-Modus gewechselt.

ALTER PLUGGABLE DATABASE srcpdb CLOSE;
ALTER PLUGGABLE DATABASE srcpdb OPEN READ ONLY;

Danach wird der Clonevorgang mit einem Kommando gestartet.

CREATE PLUGGABLE DATABASE tgtpdb FROM srcpdb;

Wenn der Vorgang abgeschlossen ist, muss die geclonte PDB nur noch geöffnet werden.

ALTER PLUGGABLE DATABASE tgtpdb OPEN;
ALTER PLUGGABLE DATABASE tgtpdb SAVE STATE;

Zum Schluss wird die Quell-PDB in den normalen Modus zurückgewechselt, wenn sie vor dem Vorgang in den Read-Only-Modus gewechselt wurde. 

ALTER PLUGGABLE DATABASE srcpdb CLOSE;
ALTER PLUGGABLE DATABASE srcpdb OPEN;
ALTER PLUGGABLE DATABASE srcpdb SAVE STATE;

Das Speichern des aktuellen Status beider PDBs ist hier empfehlenswert.

In bis zu 7 Schritten wird eine vorhandene PDB in eine neue CDB geclont

Der zuvor beschriebene Cloneprozess muss nur um 2 bis 3 Schritte erweitert werden, wenn das Clonen in eine neue CDB geschehen soll. Es kommen ein User für das Clonen auf der Quell-PDB

CREATE USER clone_user IDENTIFIED BY "Secr3t01!";
GRANT CREATE SESSION, CREATE PLUGGABLE DATABASE TO clone_user;

und ein Datenbanklink auf der Ziel-PDB hinzu.

CREATE DATABASE LINK clonepdb CONNECT TO clone_user IDENTIFIED BY "Secr3t01!" USING 'srcpdb';

Ein tnsnames.ora-Eintrag erleichtert dann noch die Nutzung im Datenbanklink.

SRCPDB=
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = srchost)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = SRCPDB)
    )
  )

Der eigentliche Clone-Befehl wird nur um den Datenbanklink erweitert.

CREATE PLUGGABLE DATABASE tgtpdb FROM srcpdb@clonepdb;

Ansonsten ähnelt der Prozess stark dem Clonen einer PDB innerhalb einer CDB.

In bis zu 8 Schritten wird eine PDB aus einer NonCDB erstellt

Auch das Clonen einer NonCDB in eine neue PDB ist sehr einfach. Hier kommen nochmal 2 Schritte im Vergleich zu den vorherigen Prozessen hinzu, die aber ebenfalls bereits effizient aufgebaut sind.

Der Clonevorgang selbst wird etwas angepasst. Anstelle der Angabe der QuellPDB wird der Begriff "NONCDB" angegeben.

CREATE PLUGGABLE DATABASE mypdb FROM NON$CDB@clonepdb;

Nach dem eigentlichen Cloneprozess kann die neue PDB noch nicht sofort geöffnet werden. Es wird ein von Oracle mitgeliefertes Script auf der neuen PDB ausgeführt, das die letzten Schritte im Konvertierungsprozess von NonCDB zu PDB durchführt (z. B. Lösen der eigenen Systemtablespaces).

ALTER SESSION SET CONTAINER=mypdb;
@$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql

Die nachfolgenden Schritte sind dann wieder die gleichen wie bei den vorherigen Vorgängen.

Für ein gleichzeitiges Upgrade des Releases auf 19c sind nur 2 zusätzliche Schritte notwendig

Auch das Upgrade der Datenbank mit dem Cloneprozess ist kein Problem, allerdings hier nur bis einschließlich 19c und in eine neue CDB, die die Version des Releases hat. Ist die entsprechende NonCDB oder PDB erfolgreich geclont, wird beim Öffnen der neuen PDB eine Warnung geworfen und die PDB wechselt in den MIGRATE-Status. Dies sieht man nach dem Absetzen des Befehls show pdbs in der neuen CDB:

ALTER PLUGGABLE DATABASE mypdb OPEN;

Warning: PDB altered with errors.

SQL> show pdbs
CON_ID	CON_NAME        OPEN MODE	RESTRICTED
-------	---------------	----------	----------
2		PDB$SEED		READ ONLY	NO
3		MYPDB			MIGRATE		YES

In dem MIGRATE-Status kann die PDB nun upgegradet werden.

dbupgrade -l /u01/oracle/logs -c "mypdb"

Nach erfolgtem Upgrade werden die Objekte der PDB noch rekompiliert.

?rdbms/admin/utlrp.sql

Nach der erfolgten Rekompilierung wird bei einem Clonen aus einer NonCDB mit dem Abschlussscript noncdb_to_pdb.sql weitergemacht. Hat man aus einer PDB geclont, ist der Prozess mit dem Rekompilieren der Objekte abgeschlossen.

Auch das Upgrade auf 21c funktioniert – allerdings mit angepasstem Prozess

Möchte man seine NonCDB oder PDB gleich auf das Release 21c heben, ist dies ebenfalls möglich. Allerdings wird dazu ein sogenanntes Manifest-File benötigt, für das der Read-Only-Modus zwingend erforderlich ist.

Die NonCDB oder PDB wird als erstes in den Read-Only-Modus gewechselt.

-- PDB
ALTER PLUGGABLE DATABASE srcpdb CLOSE;
ALTER PLUGGABLE DATABASE srcpdb OPEN READ ONLY;
-- NONCDB
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE OPEN READ ONLY;

Mittels der Prozedur DBMS_PDB.DESCRIBE wird dann ein Manifest-File im xml-Format erstellt und mittels DBMS_PDB.CHECK_PLUG_COMPATIBILITY geprüft.

EXEC DBMS_PDB.DESCRIBE('/PATH/TO/FILE.XML’);
EXEC DBMS_PDB.CHECK_PLUG_COMPATTIBILITY('/PATH/TO/FILE.XML’);

Das Manifest-File wird dann auf den Zielserver übertragen und dort dann in der neuen CDB die neue PDB aus dem Manifest-File erstellt.

CREATE PLUGGABLE DATABASE mypdb USING '/PATH/TO/FILE.XML' COPY;

Die Quell-NonCDB oder PDB kann bereits nach dem Erstellen des Manifest-Files wieder in den normalen Modus gewechselt werden.

3 Hauptargumente für das Nutzen der Clone-Funktion der Multitenant-Architektur

Die Clone-Funktion ist ein starkes Feature der Multitenant-Architektur. Nicht nur, da sie einfach zu bedienen ist, sondern auch, weil sie übersichtlich ist und einfach funktioniert. Denkt man an Cloneprozesse über RMAN-Backups oder Datapump-Exporte, wird einem schnell die Einfachheit der Funktionalität klar. Es sprechen drei klare Hauptargumente für die Clone-Funktion:

1. Übersichtlichkeit – Die Funktion ist im Verhältnis zu anderen Clone-Prozessen einfach zu bedienen und in wenigen Kommandos durchgeführt.
2. Automatisierbarkeit – Cloneprozesse lassen sich relativ einfach automatisieren. So kann auch unter anderem ein recht einfacher Migrationsprozess auf ein neues Release oder der Wechsel auf die MultitenantArchitektur aus einer NonCDB getestet und verprobt werden.
3. Verfügbarkeit – In den meisten Fällen ist die Quelldatenbank während und nach dem Cloneprozess weiterhin verfügbar. Eine Downtime ist nicht notwendig.

7 Tipps für eine erfolgreiche Umsetzung

Aus dem Alltag im Projekt beim Clonen von PDBs kann ich 7 klare Tipps mitgeben:

1. Ein Eintrag in der eigenen tnsnames.ora für den Datenbanklink erspart einem Schreibfehler in der Syntax und mehrfaches Löschen und das erneute Anlegen des Links
2. Das Clonen von Datenbanken egal welcher Form fällt beim Einsatz von Oracle Managed Files um einiges leichter, da Oracle sich dann um das Umbenennen und Ändern von Datenpfaden kümmert.
3. Die Ziel-PDB immer erst öffnen, wenn auch wirklich alles fertig ist, um Fehler im Cloneprozess zu vermeiden.
4. Die Verwendung von Release 12.2 und des Archivelogmodes ist mindestens empfohlen, aus Supportgründen am besten gleich 19c einsetzen.
5. Nach dem Anlegen einer neuen CDB immer an den Parameter max_pdbs denken und diesen gleich setzen.
6. Das Clonen einer CDB macht wenig Sinn, da das statische Data Dictionary in der CDB steckt
7. Beim geplanten Upgrade nach 21c lieber gleich das Autoupgrade-Tool nutzen, da das Upgrade über ein Manifest-File eine Downtime benötigt

Autor

Das könnte Sie auch interessieren