Oracle Datenbank 12c: Vorteil Single-Tenant

Mit der Version 12c der Datenbank hat Oracle vor knapp fünf Jahren die Container-Datenbank-Architektur, auch Multitenant-Architektur genannt, eingeführt. Sie ist die Grundlage für Multitenant-Datenbanken. Zukünftig soll diese Architektur in der "Single-Tenant"-Variante die "klassische Architektur" – jetzt "Non-CDB-Architektur" genannt – als Standard-Architektur ablösen. Welche Vor- und Nachteile hat diese neue Single-Tenant-Architektur? Und wie kommt man von einer Non-CDB-Datenbank zu einer Container-Datenbank?
Die Container-Datenbank-Architektur (CDB-Architektur) wurde im Release 1 der Oracle-Datenbank 12c kritisch und skeptisch beäugt. Als typisches Release 1 eines neuen Features ist sie mit Oracle 12.2 deutlich besser für die Praxis geeignet. Viele für den Alltagsbetrieb hilfreiche und wichtige Funktionen wurden mit Oracle 12.2 nachgeliefert. Daher steigen meiner Beobachtung nach auch immer mehr Kunden mit Oracle 12.2 auf die CDB-Architektur um oder ziehen es zumindest ernsthaft in Erwägung. Einstiegspunkt ist dabei meist die Single-Tenant-Variante, denn sie ist in allen Datenbank-Editionen verfügbar und erfordert keine zusätzlichen Lizenzen.
Architektur-Varianten in Oracle 12c
Mit der Version 12c bietet Oracle die in Abb. 1 gezeigten Datenbank-Varianten an. Die Multitenant-Variante mit effektiv bis zu 252 Pluggable Databases (PDBs) bzw. bis zu 4094 (Oracle 12.2 in der Oracle Cloud bzw. mit Exadata) ist hier nicht das Thema. Aber welche Vorteile hat die Single-Tenant-Datenbank, d. h. die Container-Datenbank mit einer PDB, gegenüber der klassischen Datenbank? Lohnt sich der Wechsel?
Vorteile von "Single-Tenant" gegenüber "Non-CDB"
Zukunftssichere Architektur
Die Single-Tenant-Variante ist sicher die zukunftssichere Architektur, denn die Non-CDB-Architektur ist abgekündigt. Lt. Oracle 12.2 Upgrade Guide gilt: "The non-CDB architecture is deprecated in Oracle Database 12c release 1 (12.1) and may be desupported and unavailable in a release after Oracle Database 12c Release 2 (12.2)." Wenn man das geänderte Nummerierungschema der Oracle-Versionen berücksichtigt, dann können wir erwarten, dass die Non-CDB-Architektur bis Oracle 19c (früher Oracle 12.2.0.3 genannt) unterstützt wird. Darüber hinaus besteht das Risiko, dass die Architektur in den Status "desupported" wechselt.
Darüberhinaus bietet die Single-Tenant-Datenbank einen Einstieg in die Container-Datenbank-Architektur, der keine zusätzlichen Lizenzen erfordert.
Wichtig: Wie bei den meisten Oracle-Optionen muss auch die Multitenant-Option nicht gesondert aktiviert werden. Wenn man – auch nur versehentlich – zusätzlich zu einer vorhandenen PDB eine weitere PDB anlegt, nutzt man die Multitenant-Option. Um dies zu verhindern, bietet Oracle 12.2 den Parameter MAX_PDBS. Dieser sollte, wenn man einen derartigen Lizenzverstoß verhindern möchte, auf 1 gesetzt werden. Dies gilt auch für die SE2!
SQL> ALTER SYSTEM SET MAX_PDBS=1 SCOPE=BOTH;
Cloning-Möglichkeiten & Provisioning
Die Cloning-Möglichkeiten der Container-Datenbanken (Remote-Cloning, Subset-Cloning, Metadata-Cloning) bieten viele Möglichkeiten für die Bereitstellung von Datenbanken als Kopie vorhandener Datenbanken. PDBs können, nachdem sie konfiguriert wurden und die Anwendungsobjekte angelegt wurden, aus einer CDB ausgehängt werden und als Vorlage abgelegt werden. Diese Vorlagen können dann einfach und schnell in neue CDBs eingehängt werden.
Ressource-Management
Ein sehr wichtiger Punkt bei den Multitenant-Datenbanken ist die Zuordnung der Ressourcen wie CPU (bereits ab 12.1), SGA und I/O auf die einzelnen PDBs. Dies kann auch bei Single-Tenant genutzt werden. So kann man z. B. die Anzahl der I/O-Operationen (IOPS) oder den Durchsatz (MBPS) begrenzen. Wenn man mehrere Single-Tenant-Datenbanken auf einem System hat, dann kann man darüber eine I/O-Zuteilung machen.
Aufteilung der Zuständigkeiten
Die Zweiteilung der Datenbank in Root-Container (CDB$ROOT) und die PDB als Anwendungsdatenbank erlaubt die Aufteilung der Zuständigkeiten: der CDB-Administrator betreut die CDB-Infrastruktur und der PDB-Administrator ist der "Applikations-DBA" mit eingeschränkten Rechten und kleinerem Aufgabenbereich.
Lockdown Profiles (12.2)
Bei der Aufteilung der Zuständigkeiten helfen PDB Lockdown Profiles. Sie erlauben die Beschränkung von Funktionen, Befehlen oder Datenbank-Features in einer PDB.
Folgende Optionen können deaktiviert werden:
- Database Queueing
- Partitioning
Befehle, deren Nutzung eingeschränkt werden kann:
- ALTER DATABASE
- ALTER PLUGGABLE DATABASE
- ALTER SESSION
- ALTER SYSTEM
Funktionen (Auszug):
- AWR-Zugriff
- Netzwerk-Zugriffe (UTL_TCP, UTL_HTTP, UTL_MAIL, UTL_SNMP, UTL_INADDR und DBMS_DEBUG_JDWP, XDB-Protokolle)
- JAVA
- Zugriff auf Dateien (UTL_FILE oder DBMS_FILE_TRANSFER)
Diese Liste ist nicht vollständig; die "Oracle 12.2 SQL Reference" enthält eine komplette Liste. Beim Einschränken von Befehlen können einzelne Klauseln oder Parameter festgelegt werden. So kann z. B. "ALTER SYSTEM SET .." auf bestimmte Parameter reduziert werden.
Im Single-Tenant-Umfeld können derartige Einschränkungen die Betriebssicherheit des Systems verbessern.
Datenbank online verschieben (Relocate/12.2)
Eine Pluggable Database kann (fast) online in eine andere CDB auf einem anderen Rechner verschoben werden. Dies kann sogar so erfolgen, dass Client-Verbindungen automatisch auf den anderen Server umgeleitet werden. Dabei ist darauf zu achten, dass in der Ziel-CDB keine PDB vorhanden ist, denn ansonsten erzeugt man durch den Relocate eine Multitenant-Datenbank, die mit zusätzlichen Lizenzkosten verbunden ist [1].
Flashback
Oracle 12.2 erlaubt den Flashback einer Pluggable Database, ohne dass dazu die Datenbankinstanz neu gestartet werden muss. Dies ist eine deutliche Erleichterung gegenüber dem Flashback einer Non-CDB, der immer mit einem Restart der Instanz einhergeht. Voraussetzung für dieses Feature ist die Verwendung von "local Undo", d. h. von Undo-Tablespaces in den PDBs.
Refreshable PDB als einfache Hochverfügbarkeitslösung
Mit Oracle 12.2 gibt es das neue Feature der "Refreshable PDBs". Dabei werden automatisch in regelmäßigen Abständen die Änderungen in der Quell-PDB in eine Ziel-PDB übertragen. Letztere muss dafür im Read-Only-Modus geöffnet sein. Dieses Feature ist auch in der Standard-Edition verfügbar und kann für die SE2 eine einfache Hochverfügbarkeitslösung sein: der Refresh der Ziel-PDB erfolgt im kürzestmöglichen Intervall von einer Minute. Im Fehlerfall wird einfach die Ziel-PDB im Read-Write-Modus geöffnet.
Nachteile
Natürlich hat eine neue Datenbank-Architektur auch immer Nachteile gegenüber einer bewährten Architektur und ein Architekturwechsel birgt immer Risiken. Da aber ein Wechsel ohnehin mittelfristig erfolgen muss – denn die Non-CDB-Variante der Datenbank wird es nicht ewig geben – sollte man nach dem Motto "je früher, desto besser" frühzeitig Erfahrungen mit der CDB-Architektur sammeln.
Eingewöhnung, "change of mindset"
Mit der neuen Architektur muss sicher ein Umdenken erfolgen, denn die Frage "wo bin ich?" wird sehr wichtig. Der gleiche Befehl kann im Root-Container CDB$ROOT zu anderen Ergebnissen führen als in einer PDB. So zeigen z. B. die DBA-Views immer nur die Objekte aus dem aktuellen Container (CDB$ROOT oder PDB) an. Eine Gesamtsicht erhält man nur über die CDB-Views im Root-Container.
Daher kann es hilfreich sein, sich im SQL*Plus-Prompt anzeigen zu lassen, in welchem Container man sich gerade befindet. Es gibt einfache Beispiele, wie man dies über das glogin.sql-Skript realisieren kann [2].
Sicher sind im Rahmen eines derartigen Wechsels auch Administrationsskripte etc. anzupassen.
Overhead
Ein wesentliches Merkmal der Container-Datenbanken ist die Aufteilung des Data Dictionaries: die Definition der Data-Dictionary-Objekte liegt im SYSTEM-Tablespace des Root-Containers CDB$ROOT. Von den PDBs aus gibt es Pointer zu diesen Definitionen, so dass die PDBs auf die Definitionen zugreifen können. Die Definitionen der Applikationsobjekte (User, Tabellen, PL/SQL-Code etc.) werden dann im SYSTEM-Tablespace der Pluggable Datenbank abgelegt. D. h. es gibt zwei SYSTEM-Tablespaces (je einmal im Root-Container und einmal in der PDB). Dies gilt genauso für den SYSAUX-Tablespace, den UNDO-Tablespace (ab 12.2) und den TEMP-Tablespace. Somit steigt die Anzahl der Datenbank-Dateien und der effektive Platzbedarf ist auch etwas größer. Bei den heutzutage üblichen Datenbankgrößen fällt der Mehrbedarf allerdings nicht groß ins Gewicht.
Weiterhin benötigt eine CDB im Vergleich zu einer Non-CDB etwas mehr Hauptspeicher für die SGA; allerdings ist auch dieser Overhead bei den heutigen Servergrößen zu vernachlässigen.
Verfügbarkeit der Features
Leider sind immer noch nicht alle Features der Oracle-Datenbank in Container-Datenbanken verfügbar. Gemäß der Oracle-Dokumentation (Oracle Database 12c Release 2 – Database Readme) sind dies:
- Flashback Transaction Query
- Database Recovery Advisor
- Oracle Sharding
Im Vergleich zu Oracle 12c Release 1 wurde die Liste der nicht unterstützten Features deutlich reduziert und ist in den meisten Fällen nicht relevant.
Wichtig in dem Zusammenhang ist aber auch, dass Oracle Streams bei Container-Datenbanken nicht verfügbar ist. Wenn Streams als Replikationstechnologie genutzt wird, dann ist der Wechsel zu Single-Tenant daher keine Option. Bevor in so einem Fall zu Container-Datenbanken gewechselt wird, muss also erst einmal eine neue Replikation implementiert werden. Dies muss allerdings mittelfristig ohnehin geschehen, denn Oracle 18c ist die letzte Datenbank-Version, die Oracle Streams unterstützt [3].
Ausführungspläne
Abfragen auf das Data-Dictionary können in Container-Datenbanken zweigeteilt sein: eine Teil-Abfrage in der PDB und dazu ein weiterer Teil im Root-Container (CDB$ROOT). Diese Zweiteilung kann in Einzelfällen zu – im Vergleich zu Non-CDB-Datenbanken – schlechteren Ausführungsplänen führen.
CDB-spezifische Bugs
Natürlich gibt es auch Bugs, die in der CDB-Architektur, nicht aber in der Non-CDB-Architektur auftreten, z. B. Bug 26169004: PL/SCOPE DOES NOT DETECT USAGES OF CDB OBJECTS SUCH AS SYS.DBMS_SQL.
Wechsel von Non-CDB nach Single-Tenant
Für den Wechsel von einer Non-CDB-Datenbank hin zur CDB-Architektur bieten sich natürlich auch klassische Wege wie Datapump, Export/Import oder Transportable Tablespaces an. Darüberhinaus bietet Oracle aber zwei neue Methoden, die speziell für die Migration in die Container-Datenbank-Architektur gedacht sind. Diese Methoden beruhen auf Verfahren, die in den Container-Datenbanken für Pluggable-Datenbanken angewendet werden können.
Einhängen (Plug-In) einer Non-CDB als PDB in eine CDB
Die Container-Datenbanken erlauben es, dass eine PDB aus einer CDB ausgehängt wird (Unplug) und dann in eine andere CDB eingehängt wird (Plug). Diese Methode kann auch für die Migration einer Non-CDB in eine PDB genutzt werden.
Grob-Ablauf:
- Anlegen einer leeren CDB (d.h. ohne PDB)
- Öffnen der Non-CDB im Read-Only-Modus
- Erzeugen einer sog. Manifest-Datei
- Schließen der Non-CDB
- Einhängen der Non-CDB als PDB
- Konvertieren des Data-Dictionaries mit dem Skript noncdb_to_pdb.sql
Detailliertere Informationen gibt es in den folgenden Support-Notes:
- How to plugin 12c NON CDB using OLS in to CDB as Pluggable database (Doc ID 2323575.1)
- How to Convert Non-CDB to PDB Database in 12c - Testcase (Doc ID 2012448.1)
Anlegen einer PDB als Kopie (Clone) einer Non-CDB
Ein Feature der Container-Datenbanken ist das "Remote-Cloning", d. h. das Kopieren einer PDB von einer CDB in einer andere. Ausgangsdatenbank für eine derartige Kopieraktion kann auch eine Non-CDB sein, d. h. wir können mit diesem Verfahren eine Non-CDB in eine PDB konvertieren.
Grob-Ablauf:
- Anlegen eines Datenbank-Links von der CDB in die Non-CDB
- Öffnen der Non-CDB im Read-Only-Modus
- Anlegen der PDB als Kopie der Non-CDB. Dabei werden die Datenbank-Dateien via Datenbank-Link kopiert
- Konvertieren des Data-Dictionaries mit dem Skript noncdb_to_pdb.sql
MOS-Note zu diesem Thema:
- Example for Cloning PDB from NONCDB via Dblink (Doc ID 1928653.1)
Fazit
Single-Tenant-Datenbanken ermöglichen den kostengünstigen Einstieg in die Container-Datenbank-Architektur. Viele Funktionen, die für die Verwaltung von großen Multitenant-Datenbanken erforderlich sind, helfen auch beim Betrieb von Single-Tenant-Datenbanken. Da "Single-Tenant" zukünftig die Standard-Architektur für Oracle-Datenbanken wird, lohnt es sich schon jetzt, sich mit dem Thema genauer zu beschäftigen und den Wechsel auf Single-Tenant zu prüfen. Dies gilt umso mehr, weil neben dem technologischen Paradigmenwechsel auch die notwendigen betriebsunterstützenden Hilfsmittel und Konzepte (Skripte, Backup/Recovery- und Security-Konzepte und mehr) geprüft und ggf. überarbeitet werden müssen.
Neuen Kommentar schreiben