Zum Inhalt springen
  • Von: DOAG Online
  • Datenbank Themen
  • 03.10.2014

Multitenant wird in der Version 12.1.0.2 feingranular

Die In-Memory-Option war das Highlight des aktuellen Patch Set 12.1.0.2. Doch abseits dieser Funktionalität bringt die Datenbank-Version eine Reihe von interessanten Features im Bereich Multitenant, die der Multitenant-Verantwortliche bei Oracle Patrick Wheeler auf der Oracle Open World vorgestellt hat.

Die In-Memory-Option war das Highlight des aktuellen Patch Set 12.1.0.2. Doch abseits dieser Funktionalität bringt die Datenbank-Version eine Reihe von interessanten Features im Bereich Multitenant, die der Multitenant-Verantwortliche bei Oracle Patrick Wheeler auf der Oracle Open World vorgestellt hat.

Zunächst einmal wurde die Oracle Database Cloud aktualisiert. Anwender verfügen nun über eine identische Software, unabhängig davon, ob sie die Datenbank on-premise oder on-demand nutzen. Wie CTO Larry Ellison in seinen beiden Keynotes mehrfach betonte, bestehe nun die Möglichkeit, relativ einfach zwischen beiden Infrastrukturen zu wechseln.

Doch es geht auch darüber hinaus: Wenn eine Datenbank in die Cloud umgezogen wird, wird sie zeitgleich modernisiert. Sie nutzt nicht nur die aktuellste Datenbank-Version, sondern basiert auf der neuersten Cloud-Plattform und erbt ihre Fähigkeiten. Wheeler machte auch auf eine weitere Möglichkeit der Konsolidierung aufmerksam: Über "Oracle Conversion Utilities" sei es möglich, MySQL- und "SQL Server"-Datenbanken nach 12c zu migrieren und in einer Multitenant-Architektur zu nutzen. 

Die neue In-Memory-Option funktioniert besser mit Multitenant. Der Grund für den Performance-Unterschied liegt in der Architektur von 12c begründet: Diese nutzt weniger Memory-Ressourcen. Demnach können die nicht-genutzten Memory-Ressourcen wieder von der In-Memory-Option in Anspruch genommen werden.

Auf Multitenant-Ebene kommen neue Funktionen, die Administratoren das Leben möglicherweise noch einfacher machen. Zunächst einmal führt Oracle eine Klausel ein, mit der feigranular festgelegt werden kann, welche PDBs (Pluggable Database) einer CDB (Container Database) bei einem Restart mitgestartet oder eventuell ausgeschlossen werden sollen. Muss die CDB neugestartet werden, so weiß die PDB, wie sie sich zu verhalten hat. Bei Ausfällen kann somit die Downtime reduziert werden.

Mit dem Parameter CREATE_FILE_DEST können Administratoren PDBs viel einfacher über die Container-Grenze hinweg bewegen: Das Zielverzeichnis einer PDB kann mit dem Parameter unabhängig vom Container definiert werden. Wenn kein Zielverzeichnis definiert wird, erbt die PDB dieses von der CDB.

Die CONTAINERS-Klausel aggregiert Anwender-Daten mehrerer PDBs innerhalb einer CDB. Ihre Anwendung findet die Klausel zum Beispiel im Reporting-Bereich, wenn Informationen in unterschiedlichen PDBs vorgehalten werden. So können Daten einer Tabelle bzw. View, die unter dem gleichen Namen in mehreren PDBs existiert, auf einmal abgefragt werden.

Für Entwicklungsumgebungen ist nun auch über "Metadata Clone" ein schnelleres Provisioning möglich. Damit kann ein Administrator einen Klon von der Datenmodel-Definition erstellen. Die Anwender- und Index-Daten werden dabei nicht berücksichtigt. Lediglich die "Dictionary Daten" werden kopiert.  

Wird der Initialisierungsparameter CLONEDB auf "True" gesetzt, so können speichersparende "Snapshot Clones" auf lokalen, NFS sowie auf Clustered File Systems (dNFS) realisiert werden.  Die Quelle muss allerdings Read-only sein. 

Mit der "PDB STANDBYS"-Klausel kann die Konsolidierung verdichtet werden, indem sich unterschiedliche Service Level Agreements (SLAs) in der gleichen CDB befinden können. Mit anderen Worten können sich und Standby- und Nicht-Standby-PDBs im selben Container befinden.