DOAG Datenbank Kolumne: Multitenant versus nonCDB-Architektur

Besonders eine Aussage: „Stimmt es, dass man sich mit der Multitenant-Architektur viele Ressourcen erspart?“ geistert immer öfter durch diverse Foren, Social Media und andere Kanäle. 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 den 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, vergleicht. 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) hat als einzige Online-Logfiles (und somit Archive Logfiles) 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 Größe der Online Logfiles entsprechend der Änderungsvolumina der PDBs anpassen muss.
• Am Platzbedarf für die Archive Logfiles ändert sich (fast) nichts, da ja Änderungen in allen PDBs in den Archive Logs landen.
• In einer CDB-Datenbank gibt es auch verpflichtend eine PDB$SEED-Datenbank, die ebenfalls knapp ein GB Platz belegt.

Da die SGA/PGA (Memory) der CDB zugeschrieben wird, klingt das nach einer Platzersparnis. Das stimmt aber nicht, da auch eine leere CDB zumindest 2GB Memory benötigt (Basisoverhead). Dafür erspart man sich für jeden PDB ca. 1GB vom Basisoverhead (ja, nicht die ganzen 2GB, weil ja auch Objekte der CDB im Buffer Cache liegen).

• Nutzt man viele Oracle DBMS Packages – diese teilen sich 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. Änderungen an der SGA bedeuten einen Restart der Instanz und somit eine kurze Downtime für alle Applikationen.
• 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 Ressourcenersparnis, 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 Stacks (1MB) – 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-Ressourcen wird auch oft als Argument verwendet (weil es ja weniger Hintergrundprozesse gibt). Erzeugt man eine 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 Betriebssystem-Prozessen verursacht, 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 folgende Ergebnisse:

• Keine Ersparnis für die erste PDB, maximal 4% (ein 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% (ein Core) für 3 PDBs sein.
  • Auch das Argument, dass man im Betriebssystem CPU Ressourcen spart, ist fragwürdig. Bei einer VM, in der eine Multitenant-Datenbank (ohne Aktivität) läuft, wurden in 5 Tagen 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-Ressource, die die Benutzer-Server-Prozesse benötigen, gibt es keinen Unterschied bei den beiden Architekturen! Das Argument, dass Monitoring effizienter (ressourcensparender) ist, ist bis zu einem gewissen Punkt korrekt. Wenn man bei nonCDB das Monitoring damit macht, dass sich der Monitoring-Prozess permanent anmeldet, ein Statement absetzt und sich wieder abmeldet, wird sich die Anzahl dieser Connects ab der 2. PDB entsprechend reduzieren.

• Aber die Queries laufen potenziell länger – abhängig davon wie gut oder schlecht diese optimiert sind.
• Einige Monitoring-Lö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 Ressourcen benötigt / Monitoring Targets erzeugt. Ein Beispiel dafür ist der Oracle Enterprise Manager, der sich sowohl in der CDB als auch den PDBs connected.

Für ein RMAN-Backup gibt es im Vergleich zwischen Multitenant und entsprechend 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 Restore meistens ein I/O-Thema auf irgendeiner Ebene gibt. Wenn die Ebene das Betriebssystem ist, so sind 3 parallellaufende Restore-Jobs normalerweise in Summe schneller.

Oft wird das Argument, dass man sich Administration (also menschliche Ressourcen) erspart, ins Rennen geführt. Doch wie schaut das in der Praxis aus? Oracle-Datenbanken werden 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 identisch.

• Im Fall von CDB kann man nur „alles auf einmal“ patchen. Somit muss man beim Abstimmen der Downtime mit den 3 Applikations-Ownern einen Zeitpunkt finden. Bei nonCDB könnte man notfalls zu verschiedenen Zeiten patchen. Der Zeitaufwand für diese Koordination ist somit bei CDB potenziell 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 Sessions 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 Multitenant-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 Restore (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 einer 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 Ressourcen 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 „merkliche“ 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.

Christian Pfundtner