Ressourcen-Management

Die Verteilung der Ressourcen zwischen den einzelnen Datenbanken erfolgt mit dem per Default aktivierten Ressource Manager von Oracle. Jede Datenbank erhält standardmäßig einen gleichmäßigen Anteil an den Ressourcen. Bei zwei Datenbanken bekommt jede die Hälfte, bei drei ein Drittel der Ressourcen, bei vier ein Viertel und so weiter. Die Verteilung kann aber bei Bedarf auch angepasst werden. Diese Anpassungen können auch innerhalb der PDBs erfolgen. So sind zum Beispiel garantierte Anteile an der CPU- beziehungsweise Begrenzungen der CPU-Last einstellbar. Eine Begrenzung der I/O-Last ist jedoch nur auf Oracles eigener Exadata-Hardware möglich.

Die physikalischen Speicherstrukturen der Datenbanken im Storage sind dagegen kaum verändert. So befinden sich die Control Files, Redo Logs, die Flashback Logs und der UNDO-Tablespace nach wie vor auf der Ebene des Containers. Der SYSTEM- und SYSAUX-Tablespace in der Container Database bildet das globale Data Dictionary; die gleichnamigen Tablespaces in den einzelnen PDBs speichern hingegen nur die eigentlichen Nutzdaten des Data Dictionary. Der temporäre Tablespace – der vergleichbar dem Swapspace auf Betriebssystemebene ist – kann global für alle Datenbanken und/oder lokal angelegt werden. Für die Ablage von Daten kann man auf allen Ebenen User-Tablespaces anlegen. Da der Namensraum für jede Datenbank individuell ist, ist ein Zugriff über PDB-Grenzen hinaus außer über Datenbank-Links nicht möglich – auch wenn die Daten sich in derselben CDB befinden. Generell ist es beim Einsatz dieser Technologie nicht empfehlenswert, Benutzerobjekte in der Containerdatenbank abzulegen, da diese bei einer Migration manuell übertragen werden müssten. Perspektivisch plant Oracle, diese Möglichkeit ganz abzuschalten.

Für das Management des Speicherplatzes gibt es die Möglichkeit, den pro Datenbank maximal belegbaren Speicherplatz zu beschränken, sodass innerhalb dieser Grenzen ein Management durch weniger erfahrene DBAs möglich wird.

Rechte und Rollen

Der Verwaltung von Benutzern und Rollen kommt in einer hochgradig konsolidierten Umgebung natürlich eine Schlüsselfunktion zu. Beim Einsatz der Pluggable Database ist zwischen sogenannten Common- und Local-Benutzern und -Rollen zu unterscheiden. Common – oder besser global – sind Benutzer und Rollen dann, wenn sie auf Ebene der CDB angelegt sind und sich damit in alle vorhandenen und zukünftigen PDBs vererben. Man erkennt solche Benutzer am Präfix »C##« . Diese globalen User können sich in jede PDB konnektieren, zu der sie über die entsprechenden Grants Zugang haben. Auf Ebene der PDB lassen sich die Rechte über die durch die Common-Rollen erteilten Berechtigungen hinaus noch erweitern. So ist es möglich, einem globalen Benutzer in einer Datenbank DBA-Rechte zu geben, während sich derselbe Benutzer zur selben Zeit mit einer anderen Datenbank erst gar nicht verbinden darf.

Die Verbindung der Benutzer zu einer Datenbank erfolgt genau wie in älteren Releases über den Listener_Prozess beziehungsweise über den Scan-Listener. Pro Pluggable Database gibt es per Default genau einen gleichnamigen Service, der aber noch um zusätzliche Services ergänzt werden kann.