Oracle Multitenant: Der neue Standard ab 21c & 26ai im Vergleich
Schon mit dem Release von 21c war es nun soweit: Die klassische Single-Datenbank-Architektur – auch NonCDB-Architektur genannt – ist offiziell aus dem Support durch Oracle genommen worden. Damit ist die mit 12c eingeführte Container-Datenbankarchitektur – auch Multitenant-Architektur genannt – nun der Standard ab dem Einsatz von Oracle 21c bzw. 26ai:
"Starting in Oracle Database 21c, a multitenant container database is the only supported architecture. In previous releases, Oracle supported non-container databases (non-CDBs)." [1]
Auch in der Oracle-Datenbank-Dokumentation zum Oracle Release 21c und 26ai findet man einen entsprechenden Verweis: "Starting with Oracle Database 21c, installation of non-CDB Oracle Database architecture is no longer supported." [2] und [3]
Somit wird es nun Zeit, sich mit Multitenant und den Features der Architektur auseinanderzusetzen. Denn die neue Architektur bringt so einige Vorteile mit sich. Dieser Artikel zeigt anhand einzelner Szenarien, welche das sind und wie diese den DBA-Alltag erleichtern können.
- Szenario – Verwendung von Multitenant für Software as a Service (SaaS)-Produkte
- Szenario – Bereitstellung von Entwicklungs- und Testumgebungen
- Szenario – Konsolidierung von Legacy-Datenbanken
- Szenario – Konsolidierung von Datenbanken nach Geschäftsbereichen
- Szenario – Verwendung einer On-Premise Cloud Computing-Architektur im Unternehmen
1. Szenario – Verwendung von Multitenant für Software as a Service (SaaS)-Produkte
Dieses Szenario ist ideal für Unternehmen, die eine SaaS-Anwendung anbieten oder nutzen, bei der jeder Kunde eine eigene, logisch getrennte Datenbankinstanz benötigt.
Neue Kunden können durch das Klonen einer vorhandenen PDB schnell eine eigene Datenbank erhalten. Updates und Patches müssen nur einmal auf der CDB-Ebene angewendet werden und gelten dann für alle PDBs. Dies reduziert den Wartungsaufwand erheblich. Die Hardware-Ressourcen werden effizienter genutzt, da alle PDBs die gleiche SGA (System Global Area) und Hintergrundprozesse der CDB teilen.
2. Szenario – Bereitstellung von Entwicklungs- und Testumgebungen
Unternehmen mit Entwicklungs- und Testumgebungen können die Multitenant-Architektur nutzen, um die Komplexität zu reduzieren und die Bereitstellungszeit von Entwicklungs- und Testdatenbanken zu optimieren. Datenbanken können als eigene Mandanten für Entwicklungs- und Testzwecke aus Produktion oder einem anderen Datenstand gecloned und im Nachgang angepasst werden. Das Management mehrerer Testdatenbanken wird vereinfacht, da sie alle unter einer einzigen Instanz verwaltet werden können. Backups und Überwachung können zentralisiert werden und auch Patching kann zentralisiert werden. Des Weiteren können PDBs eine gemeinsame Master-Datenbank nutzen und nur die Änderungen speichern (Copy-on-Write), was den Speicherbedarf massiv reduziert.
3. Szenario – Konsolidierung von Legacy-Datenbanken
Unternehmen können ältere, separate Oracle-Datenbanken zu einer einzigen CDB migrieren, um die Infrastruktur zu straffen und Kosten zu senken. Dadurch können Hardware-, Lizenz- und Wartungskosten gesenkt werden. Anstatt mehrere Server und separate Instanzen zu betreiben, kann eine leistungsstarke Maschine ausreichen.
Die Administration von Patches, Backups und Überwachung ist zentralisiert, was den Aufwand für DBAs reduziert. Des Weiteren werden die Ressourcen der physischen Maschine, die vorher durch viele kleine, unterausgelastete Datenbanken fragmentiert waren, jetzt besser genutzt.
4. Szenario – Konsolidierung von Datenbanken nach Geschäftsbereichen
Dieses Szenario ist für große Unternehmen geeignet, die ihre Datenbanken nach Geschäftsbereichen oder Abteilungen trennen möchten, um die Verantwortlichkeiten klar zu definieren, ohne dabei die Vorteile der Konsolidierung zu verlieren. Jede Abteilung kann ihre eigene PDB verwalten, während die zentrale IT die übergeordnete CDB (Container Database) betreut. Das schafft eine saubere Trennung von Aufgaben. Wenn eine Abteilung vergrößert oder ausgelagert wird, kann ihre PDB einfach auf eine andere CDB oder auf einen neuen Server verschoben werden (Relocation), ohne dass die Anwendung umgeschrieben werden muss.
Abteilungen können bestimmte Parameter (wie z.B. eigene Benutzer, Schemata etc.) innerhalb ihrer PDB unabhängig konfigurieren, solange sie sich innerhalb der durch die CDB-Definition vorgegebenen Grenzen bewegen. Somit ist auch weiterhin eine gewisse Individualität gewährleistet.
5. Szenario – Verwendung einer On-Premise Cloud Computing-Architektur im Unternehmen
Unternehmen, die eine interne private Cloud-Infrastruktur für ihre Entwicklungs- und Fachabteilungen bereitstellen, können die Multitenant-Architektur als Kernstück ihrer Database as a Service (DBaaS)-Plattform nutzen.
PDBs lassen sich sehr gut automatisieren, was die Bereitstellung neuer Datenbanken für interne Kunden beschleunigt. Die Entwickler können eine Art "Self-Service"-Plattform nutzen, um schnell neue PDBs für ihre Projekte zu provisionieren, ohne auf die IT warten zu müssen.
Da die Lizenzen auf der CDB-Ebene verwaltet werden, kann das Unternehmen die Anzahl der benötigten Lizenzen besser kontrollieren und die Kosten pro PDB-Instanz senken.
- Oracle Corporation. (o. D.). Introduction to the Multitenant Architecture. Oracle Database 26c Multitenant Administrator's Guide. Abgerufen am 16. April 2026, von https://docs.oracle.com/en/database/oracle/oracle-database/26/multi/introduction-to-the-multitenant-architecture.html
- Oracle Corporation. (o. D.). Oracle Database Changes, Deprecations, and Desupports. Oracle Database 26c Upgrade Guide. Abgerufen am 16. April 2026, von https://docs.oracle.com/en/database/oracle/oracle-database/26/upgrd/oracle-database-changes-deprecations-desupports.html
- Oracle Corporation. (o. D.). Oracle Database Changes, Deprecations, and Desupports. Oracle Database 21c Upgrade Guide. Abgerufen am 16. April 2026, von https://docs.oracle.com/en/database/oracle/oracle-database/21/upgrd/oracle-database-changes-deprecations-desupports.html
