Evaluierung der Möglichkeiten des Oracle Resource Managers

Um die Kontrolle und Steuerung der Kapazitäten einer Oracle-Datenbank zu evaluieren, wurde das Studentenprojekt Oracle Resource Manager ins Leben gerufen. Das Projektziel ist die Erstellung von realitätsnahen Demos zur Darstellung der Funktionsweise des Resource Managers. Die Demonstration dient am Ende des Projektes dazu, die Funktionen des Resource Managers präzise und leicht verständlich in einer produktiven Umgebung darzustellen, um den praktischen Einsatz zu veranschaulichen. In diesem Artikel werden die grundlegenden Aspekte des Projektes erläutert und die Ergebnisse dieser Praxisphase zusammengefasst dargestellt. 

Die Oracle-Container-Architektur

Mit der Oracle-Version 12c wurde die Container-Architektur für die Oracle-Datenbank eingeführt. Diese neue Container-Architektur besteht aus einer CDB und einer oder mehreren PDBs. Eine Pluggable Database (PDB) ist im Wesentlichen eine isolierte, abgeschottete Datenbank innerhalb eines Datenbanksystems, die als "Multitenant-Datenbank“ bezeichnet wird. Die übergeordnete Container Database (CDB) enthält Metadaten über alle PDBs innerhalb des Datenbanksystems. Dies umfasst unter anderem Informationen über die Struktur der Datenbank, wie Tabellen, Indizes, Views oder Constraints. Die Anwendungsdaten werden wiederum in den Pluggable Databases gespeichert.

Die neue Architektur ermöglicht es in der On-Premise Enterprise Version bis zu 252 PDBs pro CDB zu verwenden. Bei Engineered Systemen (Oracle Exadata) sind bis zu 4096 PDBs pro CDB möglich. Die folgende Tabelle des Oracle-Lizenzmodells zeigt, welche Möglichkeiten Oracle bietet.

Mit der Einführung der Multi-Tenant-Architektur wurde die bisherige Architektur (non-CDB) als veraltet deklariert und mit dem Hinweis versehen, dass sie ab der Version 19c möglicherweise nicht mehr unterstützt wird. 

Evaluierung der Lastsimulation

Lastsimulationen dienen dazu, die Leistung, Skalierbarkeit und Zuverlässigkeit eines Systems zu bewerten, um eine optimale Nutzung der Ressourcen zu ermöglichen und potenzielle Probleme frühzeitig zu identifizieren und zu beheben. Um Problemen vorzubeugen, kann der Resource Manager die Kapazitäten von Anwendern priorisieren oder begrenzen.

Innerhalb des Projektes wurden zwei mögliche Arten der Last-Simulation vorgestellt. Das Tool, welches als erstes betrachtet wurde, ist Swingbench. Swingbench ist eine Software, welche sowohl zum Monitoring als auch zur Lastsimulation genutzt werden kann.

Als weitere Möglichkeit der Lastsimulation wurde die Erstellung von NULL-Loops untersucht. Nach einer kurzen Recherche stellte sich heraus, dass ein einzelner NULL-Loop nicht ausreichend Last für einen aussagekräftigen Lasttest erzeugt. Als Lösung wurde daraufhin folgende Vorgehensweise entwickelt: Die gespeicherte Datei mit mehreren NULL-Loops wird wiederholt ausgeführt, bis eine angemessene Last erreicht wird.

Evaluierung und Entwicklung der Resourcepläne

Damit der Resource Manager funktioniert, müssen sogenannte Resource-Pläne entwickelt werden. Um die Kapazitäten des Datenbanksystems verteilen zu können, können unterschiedliche Methoden verwendet werden. Der grundlegende Baustein für jeden Plan sind Consumer Groups. Diese Gruppen können passend für jedes System eingerichtet werden und repräsentieren Benutzer oder Anwendungen, welche unterschiedliche Prioritäten oder Ressourcenanforderungen haben. Den Consumer Groups wurden hier die Sessions, wie zum Beispiel die Ausführung eines NULL-Loops, zugewiesen. Das Zuweisen von Sessions kann auf verschiedene Arten durchgeführt werden. Im Anwendungsfall der NULL-Loops aus den erstellten Demo-Skripten wird der MODULE_NAME zur Zuweisung der Consumer Group verwendet. Wenn die Sessions den Consumer Groups zugewiesen wurden, müssen die Kapazitäten den Gruppen zugewiesen werden. Anhand des Schaubilds wird die Methode der prozentualen Verteilung dargestellt, bei der in diesem Beispiel drei Resource-Pläne erstellt wurden. 

Im gegebenen Beispiel werden die Ressourcengruppen auf der PDB-Ebene erstellt. 

In der vergrößerten Ansicht wird sichtbar, wie die Kapazität, in diesem Falle die CPU, auf der PDB-Ebene verteilt wird. Die Gruppe „OTHER_GROUPS“ erhält die Zuweisung aller Sessions, die keiner spezifischen Consumer Group zugeordnet sind. Dieser Gruppe wird ein Anteil von 5 % der Ressourcen zugewiesen. Die Sessions, die der Gruppe „ADHOC“ zugewiesen sind, erhalten 20 % der maximalen Leistung, werden jedoch nach einer gewissen Zeit, in der diese nicht verwendet werden, in die Gruppe „Kill_Session“ verschoben, in der sie beendet werden. Der Gruppe „Batch“ werden ebenfalls nur 5% zugewiesen. Die Gruppe „App“ repräsentiert die Sessions des normalen Applikations-Betriebs und erhält daher 70 % der CPU-Leistung.

Weitere Möglichkeiten für die Begrenzung der Leistung wären die Zuweisung von CPU-Cores für einzelne Consumer Groups oder die Nutzung von Shares, welche ähnlich funktioniert wie die prozentuale Verteilung. Hierbei werden die prozentualen Beträge anhand der insgesamt vergebenen Shares errechnet. Bei 10 Shares wäre demnach beispielsweise 1 Share 10 %.

Fazit

Der Oracle Resource Manager ist ein mächtiges Tool, welches dazu dient, die Auslastung der Ressourcen bei Systemen mit vielen PDBs durch eine übergeordnete Ebene steuern zu können.

Innerhalb der Praxisphase wurden neben der theoretischen Erarbeitung und praktischen Erprobung des Tools auch Skripte zur Veranschaulichung der Möglichkeiten sowie eine Abschlusspräsentation erarbeitet. Die Abschlusspräsentation wurde gemäß unserem Motto: „Wissen vermehrt sich, indem man es teil.“ in unterschiedlichen Teams gehalten. Darunter fielen Fachteams sowie das Montagsmeeting, welches allen Studierenden und Interessierten offen steht.

Seminarempfehlungen