Multitenant im Dataguard Umfeld

Derzeit arbeite ich in einem Projekt, in dem wir eine neue Infrastruktur mit RAC und Dataguard aufbauen. Aufgrund der Anforderungen einiger Anwendungen, z.B. die, die Anwendung zurücksetzen zu können, haben wir uns für die Multitenant Database Option und gegen eine Schemakonsolidierung entschieden.

Obwohl derzeit ein Zurücksetzen einer einzelnen PDB noch nicht unterstützt wird, können wir mit der Snapshot Standby Funktion ein Flashback auf der Standby Datenbank durchführen und aus dieser dann per Unplug / Create eine PDB auf einen bestimmten Zeitpunkt zurücksetzen.

Architektur

Wir haben zwei Rechenzentren die identisch ausgestattet sind. In jedem RZ haben wir einen zwei Knoten RAC. Als Storage benutzen wir NetApp mit den Snapshot Funktionen (SnapVault, SnapMirror). Aus diesem Grunde haben wir uns gegen ASM und für Direct NFS entschieden. Diese Konfiguration ist bereits in einem anderen Projekt bei diesem Kunden produktiv und ich muss sagen, es funktioniert extrem gut. Durch die NetApp Snapshots sind wir in der Lage Datenbanken in wenigen Minuten zu klonen. Das eröffnet uns eine zweite Option für das Zurücksetzen einer Pluggable Database.

Da der Kunde seit vielen Jahren auf Oracle Managed Files (OMF) setzt, gab es für uns keinen Grund, diese Konfiguration in Frage zu stellen. D.h. wir benutzen bei der CDB und den PDBs ebenfalls ausschließlich OMF. Allerdings sollten einige PDBs in einem separaten Filesystem angelegt werden – kein großes Problem …

Oracle Managed Files und Multitenant

Für eine klassiche (NON-CDB) Datenbank bestimmt der Parameter db_create_file_dest die Lage der Datenbank-Dateien in der Form [inlinecode]<db_create_file_dest>/<db_unique_name>/datafiles[/inlinecode]. Und das gilt zunächst auch genau so für eine CDB. Da wir es hier mit einer Dataguard Umgebung zu tun haben, verwenden ist zwar der Datenbankname identisch (db_name) aber die Unterscheidung erfolgt aufgrund des db_unique_names.
Damit kommen wir zu folgender Verzeichnisstruktur:

RAC_DC1: 
db_create_file_dest=/u03/oradata/RAC 
Datafile-Location=> /u03/oradata/RAC/RAC_DC1/datafile 
RAC_DC2: 
db_create_file_dest=/u03/oradata RAC Datafile-Location=> 
/u03/oradata/RAC/RAC_DC1/datafile

Wichtig ist, dass man nicht den gesamten Verzeichnisbaum angeben kann, sondern der [inlinecode]db_unique_name[/inlinecode] automatisch hinzugefügt wird. Soweit funktioniert das sehr gut.

Aber was ist mit Pluggable Databases?

Standardmäßig wird, wenn der Parameter db_create_file_dest auf CDB Ebene gesetzt wird, folgende Verzeichnisstruktur gewählt

db_create_file_dest>/<db_unique_name>/<GUID>/datafile

Am Beispiel von RAC_DC1 sieht das so aus:

Datafile-Location => /u03/oradata/RAC/RAC_DC1/3DA40035937B0B1DE0530200007F3158/datafile

Zugegebenermaßen ist das durch die GUID der PDB eine etwas sperrige Verzeichnisstruktur, aber bei „Cut & Paste“ durchaus zu handhaben.

Seit 12.1.0.2 gibt es einen zusätzlichen PDB Parameter ([inlinecode]create_file_dest[/inlinecode]). Dieser Parameter kann beim Anlegen einer PDB als Basis für die Verzeichnisstruktur bei OMF verwendet werden. Nachdem die PDB erstellt wurde, wird die Variable als Serverparameter db_create_file_dest für die PDB gespeichert. Also sollte uns das doch beim Anlegen einer PDB in einem eigenen Filesystem helfen. Tatsächlich sieht das dann folgendermaßen aus:

RAC_DC1: 
CREATE PLUGGABLE DATABASE pdb_test1 ADMIN USER pdb_admin IDENTIFIED BY password 
       CREATE_FILE_DEST='/u03/pdb_shared/RAC'; 
Datafile-Location => /u03/pdbshared/RAC/RAC_DC1/3DA40035937B0B1DE0530200007F3158/datafile

Wie man sieht, sind wir der Lösung einen Schritt näher gekommen. Die PDB liegt in einem eigenen Filesystem (hier [inlinecode]/u03/pdbshared[/inlinecode]), allerdings bleibt der Rest, d.h. db_unique_name und GUID weiterhin bestehen.

Lieder gibt es hier zwei Einschränkungen (ich würde behaupten, dass es sich um Bugs handelt):

1. Wenn Sie eine CDB mit dem RMAN duplizieren, in der bereits eine PDB erstellt wurde (z.B. [inlinecode]DUPLICATE DATABASE FOR STANDBY FROM ACTIVE DATABASE[/inlinecode]), dann wird der Parameter „[inlinecode]CREATE_FILE_DEST[/inlinecode]“ für die PDB einfach ignoriert und die PDB wird auf der Zielseite im Verzeichnis angelegt, der von der CDB vorgegeben wird. Damit hat man eine Diskrepanz zwischen primärer und kopierter Seite. Doch damit nicht genug: Aufgrund des Layouts kann es Ihnen passieren, dass die PDB nicht angelegt werden kann, weil das Filesystem der CDB voll ist!
2. Wenn Sie die PDB erst anlegen, nachdem Sie die CDB mit dem Duplicate erstellt haben und Ihre Dataguard Umgebung bereits in Betriebb ist, funktioniert das [inlinecode]create_file_dest[/inlinecode] zwar zunächst, allerdings wird auf beiden Seiten der gleiche [inlinecode]db_unique_name[/inlinecode] verwendet. D.h. es wird bei der Erstellung der PDB zwar erkannt, dass es eine Standby-Datenbank gibt aber nicht, dass diese einen anderen db_unique_name hat. Anstelle von RAC_DC2 wird die PDB auf der Standby Seite in RAC_DC1 erstellt – so es dieses Verzeichnis gibt. In der Regel wird dieses Problem dazu führen, dass Ihre Dataguard-Umgebung einen Fehler bringt und somit out-of-sync ist bzw. der Apply Prozess gestoppt wird.

Als Umgebungslösung habe ich in dem Projekt zunächst einmal symbolische Links auf beiden Seiten anlegt. Nichtsdestotrotz bleiben aber die unschönen Unterschiede zwichen Primary und Standby Datenbank.

Hoffen wir, dass dieses Problem mit dem nächsten Oracle Release behoben werden.

Wenn Sie mehr über Multitenant Database erfahren wollen kommen Sie zu meinem Vortrag am 17. November anlässlich der DOAG Konferenz und Ausstellung in Nürnberg vom 15. bis 17. November oder besser Sie melden sich zu meiner Schulung „Einführung in die Multitenant Database Architektur“ am 18. November an. Weitere Informationen dazu finden Sie unter http://2016.doag.org/home.