Blog 
Oracle 18 XE und Multitenant

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.