Wie es in der Praxis aussehen wird, ist den meisten noch nicht bekannt. Doch in der Theorie klingt alles so einfach und handlich, dass es partout auf der Oracle OpenWorld Begeisterung auslöst: Eine Datenbank zum Ein- und Ausstöpseln und Hin- und Herschieben. Aber was bedeutet es wirklich?
In den bisherigen Datenbankversionen waren das Oracle Data Dictionary zusammen mit Tables, Packages und anderen Komponenten gespeichert. Dies ändert sich nun mit der Version 12c der Datenbank grundsätzlich. Die Datenbank kommt im neuen Gewand und wird nun mandantenfähig. Im Klartext ist es ein einfaches Prinzip: Das Root-Repository ist nun getrennt von dem Rest der Datenbank.
Man nehme einen Container, in dem sich ein Root-Repository für beliebig viele Datenbanken befindet. Das ist die Ausgangssituation. Neue Datenbanken können ganz einfach in demselben Container erstellt werden. Doch es geht weiter: Nehmen wir an, dass ein DBA eine bereits existierende Datenbank klonen möchte. Mit dem Kommando CREATEPDB wird eine XML-Datei erzeugt, die für die Erstellung der neuen Datenbank genutzt wird. Entsprechendes gilt in Zukunft dann auch für Upgrades: Zu diesem Zweck muss ein neuer Container erstellt werden, der das neue Root-Repository beinhaltet. Wenn dieser Schritt erledigt ist, können alle Datenbanken auf einmal aktualisiert werden, indem sie in den neuen Container geschoben werden. Diese Mandantenfähigkeit der Version 12c bringt große Ressourcen-Vorteile mit sich – und dies bei gleichbleibender Performance: Während 50 gewöhnliche Datenbanken 20 GB Speicherplatz benötigen, kommen 50 Pluggable Datenbanken mit 3 GB zurecht. Das gleiche gilt für die CPU-Leistung: 27 Prozent für die Pluggable Datenbanken gegen 36 Prozent für die ältere Generation. Immer mehr Intelligenz wandert in die Datenbank. Dies macht sich beispielsweise an Features wie Life Cycle Management bemerkbar, womit Statistiken über die Datennutzung geführt werden.
Je nach Nutzung werden die Daten automatisch unterschiedlich komprimiert und abgelegt. Werden Daten oft abgerufen oder aktualisiert, so werden sie möglicherweise mit einem niedrigen Kompressionsgrad im Flash gespeichert. Werden Daten im Gegenteil selten abgefragt, können sie mit höchstem Komprimierungsgrad archiviert werden. In puncto Hochverfügbarkeit erlebt man einen ähnlichen Trend: Bei einem Ausfall sorgt ein Transaction Guard sorgt dafür, dass Transaktionen nur einmal abgeschlossen werden. Zudem wird mit dem Feature Business Continuity die Ausfallsicherheit der Applikation gewährleistet.
Auch ein Blick auf Oracle Real Application Cluster (RAC) lohnt sich. Bisher gab es beispielsweise für jeden RAC-Knoten eine einzelne ASM (Automatic Storage Management)-Instanz. Mit der Einführung von Flex ASM hat dies nun ein Ende gefunden. Nun kann die ASM-Instanz für mehrere RAC-Knoten zur Verfügung gestellt werden. Weiter: Oracle ASM Disk Scrubbing erkennt automatisch korrupte Daten und repariert diese. Weitere Vorteile bringt Oracle Utility Cluster mit sich: Dieses Feature funktioniert ähnlich wie Grid Home Server und macht ein zentrales Management vom Patching möglich.
So können geplante sowie ungeplante Downtimes besser gesteuert werden. Mit Oracle Data Masking Pack ist es bereits mit der jetzigen Version möglich, sensitive Daten in der Datenbank zu maskieren. Im Grunde genommen macht das neue Feature Data Redaction genau das Gleiche. Aber Data Redaction macht es jetzt online. Viele nutzten bisher Large Objects (LOBs), als VARCHAR2 und NVARCHAR2 sich oftmals als zu kurz erwiesen. Nun spricht nichts mehr gegen ihre Anwendung, da diese Datentypen von 4 K auf 32K vergrößert wurden.Ein paar Neuerungen gibt es auch im Bereich Partitionierung. Nun wird einerseits eine Kombination von Reference und Interval-Partitioning ermöglicht. Andererseits lässt 12c mit Merge auch das Zusammenfügen von Partitionen zu. Der Global Index muss nicht automatisch neu erstellt werden. Jetzt kann er entweder weiterbenutzt werden und eine Wiedererstellung kann auch asynchrone angestoßen werden.
Zudem führt ein Hinzufügen von Columns mit Default-Werten nicht mehr zum sofortigen kompletten Update einer Tabelle, sondern der Default-Wert wird beim ersten Zugriff auf die Row eingefügt.
Bisher konnte ein schlechter Execution Plan, wenn er bereits angestoßen wurde, durchaus stundenlang laufen. Es gab keine Möglichkeit, ihn anzupassen. Mit dem neuen Feature Adaptive Execution Plan passt die Datenbank nun den Plan automatisch und je nach Bedarf an - dies selbst während der Ausführung.
