Oracle Multitenant hat den Charme mehrere einzelne Pluggable Datenbanken mit einem einzigen Data Guard abzusichern, da Data Guard auf Container Datenbank Ebene funktioniert. Das erspart viel Verwaltungsaufwand und es muss nicht mehr wie früher für mehrere Datenbanken verschiedene Data Guard Umgebungen aufgebaut, überwacht und administriert werden. Weitere Vorteile und Grundlagen von Multitenant finden Sie auch in unserem Dojo #7: Oracle 12c Multitenant.

Dieser Vorteil, nur einige, wenige Data Guard Umgebungen pflegen zu müssen, birgt aber auch einige administrative Stolpersteine, derer man sich bewusst sein sollte. So sind mit der Version 12.1 noch einige Einschränkungen vorhanden: Das Flashback, gerne im Zusammenhang mit Data Guard Umgebungen gesehen, ist nicht für eine einzelne Pluggable Datenbank möglich, ebenso wenig das Umschalten einer einzelnen Pluggable Datenbank auf die Standby Seite. Auch dies funktioniert technisch, wie Data Guard selber, nur auf Container Datenbank Ebene.

Ein weiterer Knackpunkt ist das Verhalten beim Anlegen, Einstecken oder Duplizieren von PDBs. Erschwerend kommt hinzu, dass neben der unterschiedlichen Handhabung je nach PDB Erzeugung auch noch eine Unterscheidung gemacht wird, zwischen Standard Data Guard und Active Data Guard Umgebungen.

Die meisten Datenbanken werden heutzutage direkt auf ASM Basis betrieben. Damit einher geht, dass die sogenannten Oracle Managed Files eingesetzt werden, so dass die Datenbank sich selber um die Benennung und den Speicherort der einzelnen Datendateien kümmert. Aber auch auf generischen Dateisystemen oder dem ASM Cluster Filesystem, welches sich insbesondere für das schnelle Klonen von PDB Datenbanken auszeichnet, kommt das OMF Feature vermehrt zum Einsatz. Das Feature ACFS zum Klonen von PDBs einzusetzen, wurde in Community Tipp "Datenbank-Cloning - ACFS & 12c Multitenant" näher beleuchtet.

Im Umfeld von Multitenant wird jede einzelne PDB durch eine eindeutige ID gekennzeichnet, dem Generic Unique Identifier - kurz GUID. Diese GUID findet sich neben den Einträgen in V$CONTAINERS auch in der Verzeichnisstruktur und im ASM bei der Verwendung von OMF wieder.

SQL> select CON_ID, DBID, GUID, NAME from v$containers

    CON_ID       DBID GUID                             NAME
---------- ---------- -------------------------------- ------------------------------
         1 1427472112 169C2AD8F3D44879E05370F4A50AB460 CDB$ROOT
         2 3723424392 169C2AD8F3D34879E05370F4A50AB460 PDB$SEED
         3 2753064680 16A0C7F3EA950D21E05370F4A50A9346 SPDB

<DB_CREATE_FILE_DEST>/<DB_UNIQUE_NAME>/<GUID>/DATAFILE/<files>

• Anlegen einer neuen PDB vom SEED
• Duplizieren einer existierenden PDB in der gleichen CDB
• Plugin einer PDB
• Klonen einer PDB über Manifest oder von einer anderen CDB

SQL> create pluggable database doag from spdb STANDBYS=NONE;

Pluggable database created.

SQL> alter pluggable database disable recovery;

Pluggable database altered.

RMAN> configure archivelog deletion policy to none;

RMAN> connect target sys@stbycdb

RMAN> run {
      set newname for pluggable database spdb1 to new;
      restore pluggable database spdb1 from service spdb;
      switch datafile all;
      }

DGMGRL> edit database stbycdb set state='apply-off';

SQL> shutdown immediate;
SQL> startup mount;

SQL> alter session set container = spdb1;

SQL> alter pluggable database enable recovery;

DGMGRL> edit database stbycdb set state='apply-on';

Zurück zur Community-Seite