Wie bereits in meinem Blog „Oracle 18 XE ist da“ erwähnt, enthält die neue XE Version die Multitenant Database Option. Es ist möglich, bis zu drei Pluggable Databases zu erstellen. Allerdings ist es in diesem Fall egal, ob es sich um eine „normale“ PDB, eine Proxy PDB oder einen Application Root handelt.
Wenn Sie sich das erste Mal mit der Multitenant Database Option befassen, würde ich Ihnen raten, die Datendateien als Oracle Managed Files (OMF) anzulegen. Der Grund ist, dass sich dadurch die Syntax für den Befehl CREATE PLUGGABLE DATABASE sehr vereinfacht. Leider benutzt die standardmäßig installierte XE Version keine Oracle Managed Files.
Oracle Managed Files
Bevor Sie mit der Arbeit beginnen, sollten Sie die bereits angelegte Pluggable Database XEPDB1 löschen. Es ist sinnvoller, wenn Sie selbst die Erfahrung mit den PDBs sammeln und sich nicht auf etwas Vordefiniertes verlassen:
SQL> ALTER PLUGGABLE DATABASE xepdb1 CLOSE IMMEDIATE; SQL> DROP PLUGGABLE DATABASE xepdb1 INCLUDING DATAFILES;
Wenn Sie nicht unbedingt den Anspruch erheben, alle Dateien als OMF zu erstellen, würde ich die bereits erstellte CDB unverändert lassen. In diesem Fall reicht es, wenn Sie folgenden Parameter setzen:
SQL> ALTER SYSTEM SET db_create_file_dest='/u02/oradata';
Beachten Sie bitte, dass das Verzeichnis existiert (Sie haben dieses Verzeichnis vielleicht schon beim Anlegen der Datenbank angegeben). Außerdem sollte die Variable nicht den Namen der Datenbank enthalten, weil dieser automatisch hinzugefügt wird.
Jetzt kann die erste PDB angelegt werden:
SQL> CREATE PLUGGABLE DATABASE suzanne
ADMIN USER pdbadmin IDENTIFIED BY manager
DEFAULT TABLESPACE users;
SQL> ALTER PLUGGABLE DATABASE suzanne OPEN;
SQL> ALTER PLUGGABLE DATABASE suzanne SAVE STATE;
So einfach ist das!
Natürlich hat das auch einen Haken: Sie sollten nicht versuchen, OMF Dateien inklusive Pfad eintippen zu wollen, „Drag & Drop“ ist hier eher gefragt.
SQL> ALTER SESSION SET "_exclude_seed_cdb_view"=FALSE;
SQL> SELECT p.name, d.tablespace_name, file_name
FROM cdb_data_files d, v$containers p
WHERE p.con_id = d.con_id
ORDER BY p.con_id,2
NAME TABLESPACE FILE_NAME
---------- ---------- ------------------------------------------------------------------------------------------
CDB$ROOT SYSAUX /u02/oradata/XE/sysaux01.dbf
CDB$ROOT SYSTEM /u02/oradata/XE/system01.dbf
CDB$ROOT UNDOTBS1 /u02/oradata/XE/undotbs01.dbf
CDB$ROOT USERS /u02/oradata/XE/users01.dbf
PDB$SEED SYSAUX /u02/oradata/XE/pdbseed/sysaux01.dbf
PDB$SEED SYSTEM /u02/oradata/XE/pdbseed/system01.dbf
PDB$SEED UNDOTBS1 /u02/oradata/XE/pdbseed/undotbs01.dbf
SUZANNE SYSAUX /u02/oradata/XE/7B913842A2980993E0530100007F3756/datafile/o1_mf_sysaux_fzqrrx65_.dbf
SUZANNE SYSTEM /u02/oradata/XE/7B913842A2980993E0530100007F3756/datafile/o1_mf_system_fzqrrx5n_.dbf
SUZANNE UNDOTBS1 /u02/oradata/XE/7B913842A2980993E0530100007F3756/datafile/o1_mf_undotbs1_fzqrrx67_.dbf
Der Befehl ALTER SESSION SET "_exclude_seed_cdb_view"=FALSE; sorgt dafür, dass auch die Datendateien der PDB$SEED angezeigt werden. Oracle hat mit Version 12.1 entschieden, dass die zur PDB$SEED gehörenden Daten wohl nicht interessant sind und daher werden diese grundsätzlich nicht angezeigt. Man kann geteilter Meinung darüber sein.
PDBs und Services
Zu jeder PDB wird automatisch ein gleichnamiger Service erstellt. In diesem Fall sieht die Ausgabe von lsnrctl status so aus:
Services Summary... Service "7b913842a2980993e0530100007f3756" has 1 instance(s). Instance "XE", status READY, has 1 handler(s) for this service... Service "XE" has 2 instance(s). Instance "XE", status UNKNOWN, has 1 handler(s) for this service... Instance "XE", status READY, has 1 handler(s) for this service... Service "XEXDB" has 1 instance(s). Instance "XE", status READY, has 1 handler(s) for this service... Service "suzanne" has 1 instance(s). Instance "XE", status READY, has 1 handler(s) for this service... The command completed successfully
Dieser Service ist übrigens ein Grund, warum PDBs auf einem Server eindeutig benannt werden müssen. Das kann Ihnen bei XE zwar nicht passieren (zumindest noch nicht), aber bei der Verwendung der Multitenant Database Option und mehreren Datenbanken auf einem Server kann das schon einmal zu Problemen führen.
Generell gilt: Die Default Services sollten nicht verwendet werden!
Daher ist die Empfehlung, für jede Aufgabe einen zugehörigen Service anzulegen. In unserem Fall legen wir einen Service für die Anwendung an:
SQL> ALTER SESSION SET CONTAINER=suzanne;
SQL> execute dbms_service.create_service('appl_suzanne','appl_suzanne');
SQL> execute dbms_service.start_service('appl_suzanne');
SQL> ALTER PLUGGABLE DATABASE SAVE STATE;
Der abschließende Befehl ALTER PLUGGABLE DATABASE SAVE STATE sorgt dafür, dass der Service beim Starten der Datenbankinstanz automatisch mitgestartet wird. Leider funktioniert das nicht, wenn nur die Pluggable Database geschlossen und anschließend wieder geöffnet wird. Die Anwendung sollte von nun an ausschließlich mit dem Service appl_suzanne arbeiten.
PDB Cloning
Natürlich kann man eine PDB auch kopieren / Cloning. Der dafür notwendige Befehl ist sogar noch einfacher, als das Erstellen einer PDB:
SQL> CREATE PLUGGABLE DATABASE marianne FROM suzanne; Pluggable database created. SQL> ALTER PLUGGABLE DATABASE marianne OPEN; Pluggable database altered.
Zunächst sieht es so aus, als ob alles in Ordnung wäre. Allerdings gibt es tatsächlich ein Problem. Die View pdb_plug_in_violations hilft hier weiter:
SQL> SELECT name, cause, type message, status FROM pdb_plug_in_violations; NAME CAUSE MESSAGE STATUS --------------- ------------------------------ -------------------------------------------------- --------- MARIANNE Service Name Conflict WARNING PENDING
Der Grund für diesen Fehler bzw. diese Warnung ist, dass beim Kopieren einer PDB auch der Service mit kopiert wird. Die erforderliche Aktion finden wir auch in der View:
SQL> SELECT action FROM pdb_plug_in_violations; ACTION ------------------------------------------------------------ Drop the service and recreate it with an appropriate name.
Also machen wir das:
SQL> ALTER SESSION SET CONTAINER=marianne;
SQL> SELECT name FROM dba_services;
NAME
---------------
appl_suzanne
MARIANNE
SQL> execute dbms_service.delete_service('appl_suzanne');
SQL> execute dbms_service.create_service('appl_marianne','appl_marianne');
SQL> execute dbms_service.start_service('appl_marianne');
SQL> ALTER PLUGGABLE DATABASE SAVE STATE;
Limitierungen
Bei der XE Datenbank gibt es, wie bereits erwähnt, einige Limitierungen. So kann man beispielsweise nicht mehr als drei Pluggable Databases anlegen (egal ob geöffnet oder im Mount-Zustand).
CREATE PLUGGABLE DATABASE hallelujah
*
ERROR at line 1:
ORA-65010: maximum number of pluggable databases created
Außerdem liegt die Grenze für Anwenderdaten bei 12 GByte. Dabei ist es unerheblich, ob diese Daten in einer PDB liegen oder über mehrere PDBs verteilt sind. Interessanterweise werden auch hier PDBs gezählt, die nur gemounted sind.
SQL> ALTER PLUGGABLE DATABASE leonard OPEN; ALTER PLUGGABLE DATABASE leonard OPEN * ERROR at line 1: ORA-12954: The request exceeds the maximum allowed database size of 12 GB.
PDBs sichern
Was macht man, wenn eine PDB seine Grenze erreicht hat und man trotzdem eine weitere PDB anlegen möchte? Ganz einfach: die PDB wird geschlossen, ein sogenanntes Manifest (eine XML-Datei mit der Konfiguration der PDB) erstellt und dann kann die PDB gefahrlos gelöscht werden – keine Angst, sie kann zu einem späteren Zeitpunkt ohne großen Aufwand wieder erstellt werden.
SQL> ALTER PLUGGABLE DATABASE leonard CLOSE IMMEDIATE; SQL> ALTER PLUGGABLE DATABASE leonard UNPLUG INTO '/home/oracle/leonard.xml'; SQL> DROP PLUGGABLE DATABASE leonard;
Bei dem DROP PLUGGABLE DATABASE muss man nur beachten, dass man nicht die Option INCLUDING CONTENTS verwendet – dann ist die PDB tatsächlich weg. Aber Sie haben ja sicherlich ein Backup …
Jetzt kann die neue PDB angelegt und genutzt werden. Wenn ich hinterher wieder die „große“ PDB verwenden möchte, muss ich zunächst die neu entstandene löschen und dann aus dem Manifest die ursprüngliche PDB wieder herstellen:
SQL> CREATE PLUGGABLE DATABASE leonard USING '/home/oracle/leonard.xml' NOCOPY; SQL> ALTER PLUGGABLE DATABASE leonard OPEN; SQL> ALTER PLUGGABLE DATABASE leonard SAVE STATE;
Fazit
Das war ein erster Einblick in die Arbeit mit Pluggable Databases. Die hier vorgestellten Beispiele gelten genauso auch für die Enterprise Edition. Natürlich ohne die Limitierung auf 12 GByte oder 3 PDBs.
Wenn Sie Fragen oder Anregungen haben, schreiben Sie einfach einen Kommentar oder eine E-Mail an info@carajandb.com.