Oracle 12c: Multitenant Database

Architektur der Oracle Database 12c mit Multitenant

Container Datenbank (CDB)

Zunächst einmal besteht eine Multitenant Database aus einer Container Datenbank, der so genannten CDB, und ein oder mehreren Pluggable Databases. Die Container Datenbank ist dabei in etwa unserer bisherigen Datenbank gleichzusetzen. D.h. sie besteht aus dem SYSTEM, SYSAUX, TEMP und UNDO-Tablespace, hat Redolog-Dateien, Controlfiles und eine Parameterdatei (spfile). Der einzige Unterschied zur „klassischen“ Datenbank besteht darin, dass wir hier keine Benutzer- bzw. Anwendungsdaten sehen wollen (obwohl die CDB merkwürdigerweise einen USERS Tablespace hat). Wie bisher üblich wird die Container Datenbank über den Datenbanknamen (db_name) identifiziert und ist idealerweise mit einer gleichnamigen Instanz (ORACLE_SID) verknüpft. Bei RAC oder RON dürfen es auch gerne ein paar mehr Instanzen sein.

Pluggable Database

In diese Container Datenbank werden jetzt ein oder mehrere so genannte Pluggable Databases eingehängt. Auch wenn in der Oracle Dokumentation teilweise von „Starten“ und „Stoppen“ einer Pluggable Database die Rede ist, trifft es eher zu, dass die Pluggable Databases geöffnet und geschlossen werden.

Das bedeutet, dass die Pluggable Database keine Instanz hat (denn diese Starten und Stoppen wir ja bei einer „normalen“ Datenbank) und dem entsprechend auch keine eigenen Prozesse. Hinzu kommt, dass auch das Redo- und Undo-Management nur über die CDB erfolgen kann, d.h. sowohl den UNDO-Tablespace als auch Redolog-Dateien sucht man in der PDB vergeblich.

Im Schaubild sieht das dann so aus:

Wie aus dem Bild ersichtlich, hat jede Pluggable Database (PDB$SEED, PDB1, PDB3, PDB4) einen eigenen SYSTEM und SYSAUX Tablespace, nicht aber einen UNDO-Tablespace. Das bedeutet, dass jede Pluggable Database ein eigenes Data Dictionary hat und damit alle Objekte, wie Benutzer (USER$), Tabellen (tab$) oder Tablespaces (TS$) selbst verwaltet. Damit kann in der gesamten Multitenant Database das Schema „DEMO“ oder der Tablespace „USERS“ in jeder PDB angelegt werden, ohne andere Datenbanken zu kompromittieren. Damit haben wir tatsächlich eine Mandantenfähigkeit erreicht.

Arbeiten mit Pluggable Databases

Wie bereits erwähnt, hat eine Pluggable Database keine eigene Instanz, d.h. sie bedient sich der Ressourcen, die ihr über die Container Datenbank (CDB) zur Verfügung gestellt werden. Das klingt ganz einfach, bedeutet aber auch, dass der Lieblingsbefehl eines DBAs nicht mehr funktioniert:

Mit

% sqlplus / as sysdba

kann man sich zwar an eine CDB anmelden, nicht aber an eine PDB. Weil die Umgebungsvariable ($ORACLE_SID bzw. %ORACLE_SID%) nun einmal auf die CDB und nicht auf die PDB zeigt. Dies ist die erste  Hürde, die man bei der Verwendung von Pluggable Databases überwinden muss. An die PDB kommt man anschließend z.B. mit dem Befehl:

SQL> ALTER SESSION SET CONTAINER <pdbname>;

Allerdings können viele Aktionen auch direkt von der CDB aus ausgeführt werden, was das ganze Prozedere für den DBA allerdings erst einmal komplexer macht, denn auch mit unseren liebgewonnenen Views, wie DBA_TABLESPACES, DBA_DATA_FILES, DBA_USERS und den vielen anderen kommen wir nicht weit. In einer PDB können diese Views zwar noch genutzt werden, wenn ich aber wissen will, welche Tablespaces ich in der gesamten Multitenant Database habe, dann reicht diese Information nicht aus. Daher gibt es eine ganze Palette von neuen Views, die alle mit „CDB_“ beginnen. Zu DBA_TABLESPACES gesellt sich also CDB_TABLESPACES, die Benutzer zeige ich mir mit CDB_USERS an und die Datendateien statt mit DBA_DATA_FILES jetzt mit CDB_DATA_FILES. Das heißt, auch hier muss ich meine Skripte anpassen bzw. überlegen, aus welchem Kontext (CDB oder PDB) ich mir die Informationen anzeigen lassen möchte.

Erstellen einer PDB

Bevor wir eine PDB nutzen können, müssen wir erst einmal eine erstellen. In Abb.1 ist eine PDB$SEED zu erkennen. Dieses Template wird mit der Container Datenbank zusammen automatisch angelegt und im einfachsten Fall wird eine PDB einfach aus diesem Template heraus erstellt.

Hier muss man Oracle ein großes Lob aussprechen. Der Befehl hätte kaum einfacher sein können:

SQL> CREATE PLUGGABLE DATABASE <pdbname> 
      ADMIN USER <adminuser> IDENTIFIED BY <password>;

Der Admin User muss angegeben werden, damit jede PDB einen Administrator bekommt (Standardmäßig mit der neuen Rolle PDB_ADMIN). Dieser Befehl würde allerdings nur bei der Verwendung von Oracle Managed Files (OMF) funktionieren, bei herkömmlichen Dateinamen müsste der Parameter  FILE_NAME_CONVERT benutzt werden.

SQL> CREATE PLUGGABLE DATABASE <pdbname> 
      ADMIN USER <adminuser> IDENTIFIED BY <password>
      FILE_NAME_CONVERT ('pdbseed','<pdname>');

Anschließend kann die PDB geöffnet werden. Zwar kann hierfür der Befehl „STARTUP“ benutzt werden, ich würde jedoch den Befehl ALTER PLUGGABLE DATABASE bevorzugen. Zum einen „startet“ man eine PDB nicht, sondern man öffnet nur die Dateien. Zum anderen hat der ALTER PLUGGABLE DATABASE Befehl mehr Optionen.

SQL> ALTER PLUGGABLE DATABASE <pdbname> OPEN;

oder

SQL> ALTER DATABASE OPEN;

Der erste Befehl wird aus der CDB heraus ausgeführt, der zweite aus der PDB, d.h. man kann eine PDB öffnen und schließen, an der man angemeldet ist.

Damit kommen wir auch direkt zum Schließen einer PDB. Wie nicht anders zu erwarten, wird die PDB mit dem Befehl:

SQL> ALTER PLUGGABLE DATABASE <pdbname> CLOSE <IMMEDIATE>;

geschlossen. Auch hier gibt es diverse weitere Optionen, wie z.B. das Schließen für eine oder mehrere Instanzen.

Jede PDB erhält automatisch einen Servicenamen mit dem Namen der PDB. Daher können wir uns, sobald die PDB geöffnet ist, über Oracle Net mit der Datenbank verbinden und genauso arbeiten, wie wir es von einer „NON-CDB“ gewohnt sind.
Eine Kleinigkeit muss man allerdings noch beachten: Wenn die CDB Instanz heruntergefahren wird, werden alle PDBs geschlossen (okay, das hätten wir jetzt auch nicht anders erwartet). Beim Hochfahren der Instanz werden die PDBs aber standardmäßig nicht geöffnet. Mit 12.1.0.1 musste man hierfür einen ON STARTUP Trigger schreiben. Ab 12.1.0.2 gibt es jetzt die Möglichkeit, dass sich die PDB ihren Status merkt. Dies erreicht man mit dem Befehl:

SQL> ALTER PLUGGABLE DATABASE <pdbname> SAVE STATE;

PDB Cloning

Damit ist es jetzt auch möglich, PDBs nach einem Restart der Instanz in unterschiedlichen Open-Modi zu öffnen. Denn eine sehr interessante Eigenschaft von PDBs ist, dass man sich ein eigenes Template bauen kann und aus diesem heraus beliebig viele PDBs erstellt (Cloning). Leider ist es derzeit noch nicht möglich, die PDB$SEED anzupassen, aber jede andere PDB kann als Quelle für Kopien dienen, solange die PDB während der Kopieraktion Read-Only ist. Folgende Vorgehensweise könnte man sich daher überlegen:

Zunächst wird das eigene Template erstellt und entsprechend den Anforderungen (z.B. Schema, Tablespaces, etc.) angepasst. Das kann auch eine bereits existierende Datenbank sein, die für Test oder Entwicklung mehrfach zur Verfügung stehen soll.

SQL> CREATE PLUGGABLE DATABASE meintemplate ADMIN USER …

SQL> ALTER PLUGGABLE DATABASE OPEN;

SQL> ALTER SESSION SET CONTAINER=meintemplate;
SQL> <Änderungen, wie z.B. eigene Tablespaces, Users, etc.>
SQL> ALTER SESSION SET CONTAINER=CDB$ROOT;

SQL> ALTER PLUGGABLE DATABASE meintemplate OPEN READ ONLY FORCE; 

Aus dieser PDB (meintemplate) kann ich jetzt beliebig viele PDBs (max. 252 pro CDB) erstellen:

SQL> CREATE PLUGGABLE DATABASE pdbtest1 FROM meintemplate;

SQL> ALTER PLUGGABLE DATABASE pdbtest1 OPEN;

Übrigens, bei der Verwendung von Oracle 12.1.0.2 ist es nicht erforderlich, die Pluggable Database explizit mit „Read Only“ zu öffnen. Allerdings wird in diesem Fall die PDB beim ersten Kopieren auf Read-Only gesetzt und nach Beendigung automatisch wieder Read-Write.

Eine Besonderheit bieten hier einige Speicherlösungen, wie z.B. ZFS, ACFS oder auch Direct NFS. Wenn das Template auf einem solchen Storage angelegt würde, kann man einen Snapshot  erstellen. D.h. in diesem Fall wird eine PDB als „Copy On Write (C.O.W.)“ Kopie erstellt und belegt somit kaum Plattenkapazitäten. Nähere Informationen, wie man eine solche Konfiguration aufbaut, finden sich in dem Blog CarajanDB [1].

Upgrade einer PDB

Ursprünglich gab es Aussagen, dass ein Upgrade einer PDB ganz einfach so erfolgt, dass die PDB aus der „alten“ CDB herausgenommen wird (unplug) und dann in die „neue“ CDB eingehängt wird (plug in). Leider hat sich dies mit dem ersten Patchset (12.1.0.2) nicht bestätigt. Das Upgrade betrifft jede einzelne PDB.
Trotzdem soll an dieser Stelle das Verfahren des „UNPLUG“ und „PLUGIN“ näher beschrieben werden, denn wir hoffen, dass es in Zukunft tatsächlich so funktionieren wird, dass eine PDB gar nicht oder nur in geringem Maße von einem Upgrade betroffen ist.

Zunächst kann eine Pluggable Database jederzeit „Unplugged“ werden. Mit dem Unplug wird ein so genanntes Manifest geschrieben, d.h. es wird eine XML-Datei erstellt, die, ähnlich wie ein Controlfile, die wichtigsten Informationen der PDB enthält.

SQL> ALTER PLUGGABLE DATABASE <pdbname> CLOSE IMMEDIATE;

SQL> ALTER PLUGGABLE DATABASE <pdbname> UNPLUG INTO '<filename.xml>';

Die Datei muss zwingend die Endung “.xml” haben. Die Größe der Datei liegt im Bereich von wenigen Kilobyte und den Inhalt kann man sich natürlich mit einem Editor ansehen.

Auch nach dem „UNPLUG“ ist die PDB noch in der CDB sichtbar und wird z.B. bei einem Backup weiterhin mit gesichert. Leider gibt es keine Möglichkeit, die Pluggable Database nach dem Befehl „UNPLUG“ direkt wieder in die CDB einzuhängen, d.h. ein „PLUGIN“ gibt es nicht. Stattdessen muss die PDB zunächst endgültig aus der CDB gelöscht und kann erst danach wieder neu erstellt werden.

SQL> DROP PLUGGABLE DATABASE;

SQL> CREATE PLUGGABLE DATABASE <pdbname> NOCOPY;

Glücklicherweise werden beim Befehl “DROP PLUGGABLE DATABASE” die Datendateien nicht gelöscht (Default: KEEP DATAFILES), so dass beim anschließenden Erstellen der PDB, die jetzt auch durchaus einen anderen Namen bekommen darf, die gleichen Dateien wiederverwendet werden können (NOCOPY).

Erstellen einer PDB aus einer „NON-CDB“

Leider können wir in der Regel mit der Erstellung von Datenbanken nicht auf der „grünen Wiese“ beginnen, d.h. vorhandene Daten müssen übertragen werden. Der einfachste und sicherlich nicht der schlechteste Fall ist der Export und Import der Daten – natürlich mit Oracle Data Pump. Auch Transportable Tablespaces dürfen in diesem Umfeld gerne eingesetzt werden. Aber es ist auch möglich, eine NON-CDB in eine PDB zu konvertieren. Voraussetzung hierfür ist, dass es sich um eine Oracle 12c Datenbank handelt. Für vorhandene Datenbanken heißt das, dass zunächst eine Upgrade auf Oracle 12c erfolgen muss. 

Zum Einhängen dieser NON-CDB als PDB in eine CDB sind nur zwei Schritte nötig:

1. Es muss ein Manifest erstellt werden (genau wie beim UNPLUG einer PDB). Dafür meldet man sich zunächst bei der NON-CDB an:

    SQL> SHUTDOWN IMMEDIATE;

    SQL> STARTUP OPEN READ ONLY;

    SQL> execute dbms_pdb.describe('<filename>.xml');

    SQL> SHUTDOWN IMMEDIATE;

2. Die überflüssigen Data-Dictionary Informationen müssen gelöscht werden.

    SQL> CREATE PLUGGABLE DATABASE <pdbname>           USING '<filename>.xml' NOCOPY TEMPFILE REUSE;

    SQL> ALTER SESSION SET CONTAINER = <pdbname>;

    SQL> @?/rdbms/admin/noncdb_to_pdb

    SQL> ALTER DATABASE OPEN READ WRITE;

Anschließend sollte man dann noch die jetzt überflüssigen Dateien, wie z.B. Datafiles für UNDO, Redolog-Files und Controlfiles löschen.

Dieser Artikel kann sicherlich nur eine Übersicht über die Funktionen bzw. Möglichkeiten der Multitenant Database bieten. Wenn man allerdings die ersten Hürden überwunden hat, erschließen sich mit dieser Option ganz neue Möglichkeiten. Auch wenn diese Option sicherlich nicht zu den günstigsten gehört, kann sich der Einsatz der Multitenant Database Option schnell amortisieren. Für Test- und Entwicklungssysteme können durch die Verwendung von Direct NFS und Snapshot Kopie Storage Kosten drastisch reduziert werden. Kopien können über ein einfaches Self-Service Portal schnell (innerhalb von Minuten) und ohne Zutun des DBAs erstellt werden. Zudem können Administratoren entlastet werden, weil die PDB jetzt durch die Fachabteilung verwaltet werden kann. Da PDBs außerdem unabhängig von der Datenbank Architektur sind, d.h. keinen direkten Bezug zu RAC, RON oder DataGuard haben, können Service Level Agreements sehr flexibel aufgebaut werden.

Auch wenn heute die Möglichkeit besteht, zwischen einer „klassischen“ (NON-CDB) und der Multitenant Database zu wählen, denke ich, dass in absehbarer Zeit die Multitenant Database das Rennen machen wird. D.h. je früher man sich mit dieser Option beschäftigt, umso besser!

In diesem Sinne wünsche ich Ihnen viel  Erfolg beim Aufbau von Multitenant Databases.