Multitenant versus nonCDB Architektur

Nachdem ab Oracle 21c/23ai/26ai der Umstieg auf die Multitenant Architektur nicht zu vermeiden ist, bekomme ich immer wieder die Frage: „Stimmt es, dass man sich mit der Multitenant Architektur viele Resourcen erspart?“. Dieser Artikel stellt eine Analyse (aus der Praxis) dar.

Beim Einsatz einer Multitenant Datenbank (ohne den Einsatz von vielen PDBs wofür die kostenpflichtige Multitenant Option notwendig wäre), gibt es folgende Unterschiede gegenüber der non-CDB. In dem Vergleichen wird angenommen, dass man eine CDB mit bis zu drei PDBs mit einer Lösung in der bis zu 3 nonCDBs auf einem Host (einer VM) laufen, verglichen. Der Vergleich von einer CDB mit 3 PDBs und 3 nonCDBs in 3 VMs wäre Äpfel mit Birnen zu vergleichen.

Resourcenbedarf im Vergleich

• Eine CDB Datenbank (belegt mehrere GB) und hat als einzige Online Logfiles (und somit Architelogfiles) sowie die Controlfiles. PDBs nutzen diese der CDB mit. Alle anderen Tablespaces (SYSTEM, SYSAUX, UNDO, TEMP,….) haben auch PDBs.
  • Man erspart sich somit ab der 2. PDB theoretisch den Platz für die Online Logfiles  und Controlfiles (einige MB). In der Praxis stimmt das aber nicht, weil man – damit man zwischen 24 und 100 Logswitches pro Tag erreicht – die Online Logfiles entsprechend der Änderungsvolumina der PDBs anpassen muss.
  • In einer CDB Datenbank gibt es auch verpflichtend eine PDB$SEED Datenbank, die ebenfalls ca ein GB Platz belegt.
    
• Da die SGA/PGA der CDB zugeschrieben wird, klingt das nach einer Platzersparnis. Das stimmt aber nicht, da auch eineleere CDB zumindest 2GB Memory benötigt (Basisoverhead). Dafür erspart man sich für jeden PDB ca. 1GB vom BasisOverhead (ja, nicht die 2GB, weil ja auch Objekte der CDB im Buffer Cache liegen….).
  • Nutzt man viele Oracle DBMS Packages – diese sharen über die Architektur etwas Platz im Library Cache – so kann man sich theoretisch einige 100MB Library Cache pro PDB ersparen. Ich kennen KEINEN Applikation, die mehr wie vielleicht ein Duzend Oracle DBMS-Packages nutzt —> die Platzersparnis ist somit eher im Bereich von einigen 10MB Library Cache pro PDB.
  • Mit jeder zusätzlichen PDB muss man die SGA/PGA entsprechend vergrößern, damit die Performance nicht abfällt.Das wird gerne „übersehen/übergangen“ und wirklich sich zumindest temporär negativ auf die Anwender aus.
  • Die – zumindest theoretische – Hauptspeicherreduktion liegt somit bei rund 1GB pro PDB ab der DRITTEN (und letzten PDB, wenn man keine Multitenant Lizenz hat). Selbst ist 1GB pro PDB eine überschaubare Ersparnis.
    
• Da die Hintergrundprozesse der CDB zugeordnet werden, ist eine Argumentation für die Resourcenersparnis, dass es die Hintergrundprozesse nur einmal gibt. Bei einer Oracle 19c Datenbank sind das schon einmal 50-100 Prozesse, die zur Instanz gehören. Wenn man bei einer neuen CDB prüft, wie viel UGA Memory diese Prozesse benötigen, stellt man fest, dass es ca. 100MB UGA plus maximal 100 mal den Betriebssystem-Prozess Stack – somit um die 200MB – sind.
  • Im Vergleich zu einer nonCDB erspart man sich somit pro PDB ca. 200MB ab der zweiten PDB. Da man maximal 3 PDBs ohne Lizenz haben darf, reden wir somit von maximal 400MB, wenn man die erlaubten 3 PDBs nutzt.
    
• Die Ersparnis der CPU-Resourcen wird auch oft als Argument verwendet (weil es ja weniger Hintergrundprozesse gibt). Erzeugt man einen Datenbank (egal ob nonCDB oder Multitenant) auf einem Server auf dem sonst nichts läuft, wird man feststellen, dass die meiste Zeit die CPU Auslastung im Bereich von maximal 2-3% liegt. Ein Teil davon wird durch das Betriebssystem-Prozessen sein, die man sich nicht sparen kann. Sind wir großzügig und sagen 2% (was definitiv zu viel ist, selbst bei VMs mit nur 2 vCores), dann kommt man auf:
  • Keine Ersparnis für die erste PDB, maximal 4% (einer Core) bei den erlaubten maximal 3 PDBs.
  • Diese Rechnung ist aber insofern falsch, da die Hintergrundprozesse ja auch für die einzelnen PDBs tätig werden!In der Praxis wird die Ersparnis maximal bei 1-2% (einer Core) für 3 PDBs sein.
  • Auch das Argument, dass man im Betriebssystem CPU Resourcen spart, ist fragwürdig. Bei einer VM in der eine Multitenant Datenbank (ohne Aktivität) läuft, wurden in 5 Tage gerade einmal 100 Sekunden vom CPU-Scheduler verwendet – also ca. 20 CPU-Sekunden pro Tag, die man sich pro PDB (ab der 2. PDB) ersparen könnte.
    
• Für die CPU und Memory Resource, die die Benutzer Server Prozesse benötigen, gibt es keinen Unterscheid bei den beiden Architekturen!
  
• Das Argument, dass Monitoring effizienter (resourcensparender) ist bis zu einem gewissen Punkt korrekt. Wenn man bei nonCDB das Monitoring damit macht, dass sich der Monitoring Prozess permanent anmeldet, ein Statement absetzen und sich wieder abmelden, wird reduziert sich die Anzahl dieser Connects ab der 2. PDB entsprechend.
  • Aber die Queries laufen potentiell länger – abhängig davon wie gut oder schlecht diese optimiert sind. 
  • Einige Monitoringlösungen melden sich sowohl an der CDB als auch an jeder PDB einzeln an! In diesem Fall werden durch die Existenz der CDB noch mehr Resourcen benötigt / Monitoring Targets erzeugt (zb: Oracle Enterprise Manager)!
    
• Für ein RMAN Backup gibt es im Vergleich zwischen Multitenant und entsprehend vielen nonCDB Datenbanken praktisch keinen Unterschied. Die wenigen GB durch die CDB und PDB$SEED spielen in der Praxis keine Rolle.
  
• Wenn man jedoch ein Restore benötigt, sieht die Sache gleich wieder anders aus. Muss man eine CDB mit mehrere PDBs vollständig restoren, läuft dies auf Grund der größeren Backup-Files natürlich länger als beim Restore einer einzelnen nonCDB Datenbank. Vergleicht man einen CDB mit 3 PDBs versus 3 nonCDB (die man in 3 Sessions parallel restored) wird das Restore und Recovery der 3 nonCDB Datenbank voraussichtlich schneller fertig sein. Der Grund ist, dass es im Fall von RMAN Restores meisten ein IO Thema auf irgendeiner Ebene gibt. Wenn die Ebene das Betriebssystem ist, so sind 3 parallel laufende Restores normalerweise in Summe schneller.
  
• Oft wird das Argument, dass man sich Administration (also menschliche Resourcen) erspart, ins Rennen geführt. Doch wie schaut das in der Praxis aus? Oracle Datenbanken werde in der Regel viele Jahre betrieben. Somit sind die Aufwände für die Erstinstallation über die Laufzeit vernachlässigbar, wenn man eine CDB mit 3 PDB und 3 nonCDBs auf dem gleichen Rechner (gleiche VM) vergleicht. Das erzeugen einer CDB mit dem DBCA dauert ca. 2 Mal so lange wie das einer nonCDB. Somit erspart man sich einige Minuten. Die Installation des OS und der Oracle Software ist in beiden Fällen ident.
  • Im Fall von CDB kann man nur „alles auf einmal“ Patchen. Somit muss man beim Abstimmen der Downtime mit den 3 Applikationsowner einen Zeitpunkt finden. Bei nonCDB könnte man notfalls zu verschiedenen Zeiten patchen. Der Zeitaufwand für diese Koordination ist somit bei CDB potentiell höher
  • Das Patching einer CDB mit einer PDB dauert 3 Mal so lange, wie das Patching einer nonCDB Datenbank. Das liegt daran, dass Oracle zuerst die CDB Datenbank, dann die PDB$SEED Datenbank und erst dann (bis zu 8) PDBs patched. Wenn man drei nonCDBs auf einem Server hat, kann man in 3 Session diese gleichzeitig patchen, was die Dauer für das Patching nur um wenige Prozent verlängert —> Somit ist der Administrationsaufwand beim Patching von CDB Umgebungen erst mit 3 PDBs mit dem seriellen Patchen von 3 nonCDBs vergleichbar. In der Realität dauert es aber immer länger.
  • Das Instance- und Memorytuning in Multitenant Umgebungen macht man nur einmal, aber es ist insofern aufwändiger, weil in den PDBs unterschiedliche Applikationen mit unterschiedlichen Anforderungen laufen. Die Argumentation, dass man sich hier Zeit ersparen kann, ist in der Praxis ebenfalls vernachlässigbar.

Weitere Argumente

Es lassen sich noch weitere Argumente finden, beispielsweise:

• Man muss in der CDB alle Optionen konfiguriert haben, auch wenn lediglich eine PDB diese benötigt, wodurch Patching und Upgrades wieder länger laufen.
• Fällt eine CDB aus, sind gleich bis zu 3 Applikationen betroffen (sofern man nur 3 PDBs nutzt) und das wiederherstellen dauert im Vergleich zu einer nonCDB länger.
• Der negative Einfluss von Noisy Neighbours ist bei PDBs stärker als bei nonCDBs.

Zusammenfassung

• Die Multitenent Architektur
  • erspart keinen Diskspace (wenn man 3 PDBs nutzt, bei weniger PDBs braucht man mehr Diskspace)
  • erspart keinen nennenswerten CPU (wenn man mehr wie 2 PDBs nutzt, bei einer PDBs braucht man mehr CPU)
  • erspart keinen Hauptspeicher (wenn man nicht zumindest 3 PDBs nutzt, bei 1-2 PDBs ist der Verbrauch höher)
  • RMAN Restores (FULL RESTORE) dauert länger
  • die administrativen Aufwände sind (speziell durch Patching) höher und beim Instance-/Memorytuning braucht man mehr Erfahrung
• Der Einsatz der Multitenant Architektur mit nur eine PDB ist auf alle Fälle ein deutlicher Overhead, erst ab zumindest 2 PDBs ist es vergleichbar und ab der 3. PDB kann man sich minimal Resourcen sparen.

Natürlich kann es auch beim Einsatz von Multitenant Architektur (mit maximal 3 PDBs) Ersparnisse geben, diese sind aber eher organisatorischer Art, wie beispielsweise:

• Weniger Targets in Monitoring und Administrationstools.
• Weniger Aufwand für die Planung von Aktivitäten, wenn man diese dann automatisch ablaufen.
• etc

Das ist dann aber eher firmenspezifisch und kann nicht verallgemeinert werden.

Ab Oracle 21c/23ai/26ai hat man keine Wahl und muss die Multitenant Architecture nutzen. Sofern es keinen zwingenden Grund gibt schon mit Oracle 19c auf die Multitenant Architecture zu wechseln, ist das Upgrade ein idealer Zeitpunkt, weil man sich neben einer zusätzlichen Downtime (nonCDB auf CDB Migration) auch die längeren Patching Aufwände so lange wie möglich erspart.

Eine „merkbare“ Ersparnis würde nur die Nutzung von CDBs mit vielen PDBs bringen (das bringt aber auch neue Probleme) und benötigt die nicht gerade günstige Multitenant Option.