O'Reilly logo

Oracle 12c - Das umfassende Handbuch by Lutz Fröhlich

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Kapitel 3
Die Oracle-Datenbankarchitektur
102
Abb. 3.8: Umsetzung der Lesekonsistenz über UNDO-Segmente
Der Fehler tritt naturgemäß dann auf, wenn lang laufende SELECT-Anweisungen
auf ein hohes Transaktionsvolumen treffen.
3.3 Die Pluggable Database-Architektur
Vieles, was Sie in diesem Kapitel über die Architektur gelesen haben, lässt sich auf
die Pluggable Database übertragen. Allerdings war für die Umsetzung des Kon-
zepts ein tieferer Eingriff in die vorhandene Architektur erforderlich.
Wieso hat sich Oracle zu einer dermaßen signifikanten Änderung in der Architek-
tur entschlossen? Das traditionelle Konzept der Oracle-Datenbank ist so gestaltet,
dass die Datenbank der Container für mehrere Schemata ist. Die Isolation von
Sicherheit und Ressourcen bezieht sich dabei eher auf die Datenbank als auf die
Schemaebene. Das hat dazu geführt, dass eine Applikation eher eine Datenbank
als ein Schema verwendet. Obwohl Datenbanken immer größer werden, hat im
gleichen Umfang die Anzahl von kleinen und mittelgroßen Datenbanken zuge-
nommen. Für eine kleine Applikation (Datenbank) ist der Overhead der Daten-
bank beachtlich.
Tipp
Um den Fehler »Snaphot too old« zu vermeiden, sollte als erste Maßnahme der
UNDO-Tablespace vergrößert werden. Damit sinkt die Wahrscheinlichkeit, dass
UNDO-Segmente zu schnell überschrieben werden. Prüfen Sie auch, ob SQL-
Optimierung möglich ist und damit die Laufzeit der SQL-Anweisung verkürzt
werden kann.
3.3
Die Pluggable Database-Architektur
103
Die Verlagerung der Applikation auf die Schemaebene bringt für Datenbanken
bis zur Version 11 eine Reihe von Problemen mit sich. So ist beispielsweise eine
Isolation aus den Perspektiven Sicherheit und Ressourcen schwierig umzuset-
zen. Der gegenseitige Performance-Impact ist bei der Vielzahl von gemeinsa-
men Ressourcen nicht zu vermeiden. Das Benutzer- und Rollenkonzept ist auf
die Datenbank ausgelegt. Überschneidungen bei Benutzer- und Rollennamen
führen zwangsläufig zu Problemen. Die Rechte für ein Schema sind begrenzt.
So können Applikationen keine Benutzer anlegen. Auch die Wiederherstellung
einzelner Schemata einer mit RMAN gesicherten Datenbank ist aufwendig. Tab-
lespace Point-in-time Recovery ist die einzig mögliche Methode. Eine Flashback-
Database-Operation würde alle Applikationen zurückrollen, was in der Praxis
nicht als realistisch anzusehen ist.
Mit der Pluggable Database werden diese Nachteile weitgehend beseitigt und die
Möglichkeit der Kostenreduzierung eröffnet. Eine Pluggable Database bietet die
Umgebung und die Features, wie man sie von einer herkömmlichen Datenbank
kennt, und reduziert dabei den Overhead deutlich. Mit dem Konzept wurden die
folgenden Vorteile gegenüber der herkömmlichen Architektur erzielt:
Reduzierung von Betriebs- und Verwaltungskosten.
Einfache Portierbarkeit des Backends einer Applikation. Pluggable Databases
können von einer Container-Datenbank in eine andere umgezogen werden.
Verringerung des Aufwands für Administration und Überwachung.
Eine Rollentrennung zwischen Administrator der CDB sowie der PDB ist mög-
lich.
Isolation von Sicherheit und Ressourcen auf die Applikationsebene.
Weniger Patches und Upgrades.
Aus der Sicht des Oracle Client, der sich über Oracle*Net verbindet, ist eine PDB eine
vollständige Oracle-Datenbank und voll kompatibel zu einer herkömmlichen Nicht-
CDB-Datenbank. Die Installation von Schemata und Datenbankobjekten unterschei-
det sich nicht von der Installation in einer Nicht-CDB-Datenbank. Die Architektur
basiert auf der Annahme, dass eine PDB die Daten einer Applikation enthält.
Der Oracle Resource Manager wurde in der Version 12c wesentlich erweitert und
ermöglicht es, Pläne auf CDB-Niveau zu gestalten. Damit kann verhindert werden,
dass sich PDBs gegenseitig Ressourcen stehlen.
Eine PDB kann einfach, wie der Name bereits sagt, aus einer CDB herausgenom-
men und in eine andere eingesteckt werden. Das Herauslösen und Einstecken
(Unplug/Plug) kann sogar für unterschiedliche Versionen erfolgen. Weiterhin
kann für eine existierende PDB ein Clone angefertigt werden. Technisch basieren
diese Features auf der Technologie »Transportable Tablespace«.
Kapitel 3
Die Oracle-Datenbankarchitektur
104
In einer Nicht-PDB-Datenbank finden sich alle Objekte der Datenbank in einem
Datenbankkatalog.
Abb. 3.9: Die Architektur der Datenbank-Kataloge
Pluggable Databases laufen in einer Container-Datenbank. Die Container-Daten-
bank besteht aus den Komponenten »ROOT« und »SEED«. Die Komponente
ROOT (CDB$ROOT) ist eine Sammlung von Schemata, zu denen alle CDB gehö-
ren. Jede CDB besteht aus genau einer ROOT-Komponente. Jede PDB ist eine
Ableitung der Komponente ROOT. Im Data Dictionary von ROOT befinden sich
Informationen über die vorhandenen PDB. In der Komponente ROOT werden
keine Anwendungsdaten gespeichert. Es können jedoch allgemeiner Benutzer
und Rollen für die Datenbankadministration angelegt werden.
Die Komponente SEED (PDB$SEED) ist ein Template für das Erstellen neuer
PBD. Objekte in der SEED-Datenbank können nicht verändert werden.
Hinweis
Die Multitenant-Architektur ist für die Standard Edition One, die Standard Edi-
tion und die Enterprise Edition verfügbar. In jedem Fall muss die Multitenant-
Option lizenziert werden. Eine CDB mit nur einer PDB fällt nicht unter die Mul-
titenant-Option.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required