Datenbanken implementieren

Das Anlegen einer PDB erfordert zunächst einmal, dass die 12c-Datenbank als Container Database angelegt wurde. Hat der DBA dies bei der Erstellung nicht explizit ausgewählt beziehungsweise mit dem Schlüsselwort »ENABLE PLUGGABLE DATABASE« aktiviert, handelt es sich um eine normale Datenbank ohne Möglichkeit der Aufnahme weiterer Datenbanken. In diesem Fall muss die Datenbank neu angelegt werden. Die Erstellung einer PDB erfolgt immer als Kopie einer bereits vorhandenen PDB. Dies ist entweder die sogenannte Seed Database »PDB$SEED« , die beim Erstellen des Containers implizit mitangelegt wird und nicht verändert werden kann, oder eine beliebige andere PDB. Sie muss sich allerdings für den Zeitraum der Erstellung im »OPEN READ-ONLY« -Status befinden. Zusätzlich muss ein PDB-Administrator angegeben werden, der die Rolle »PDB_DBA« innehat. Diese Rolle ist aber per Default mit keinerlei Berechtigungen ausgestattet. Sofern gewünscht können aber bei Erstellung der PDB dieser Rolle weitere Rechte und Rollen zugewiesen werden. Bevor die PDB erstellt werden kann, muss noch für die Eindeutigkeit der resultierenden Dateinamen gesorgt werden. Dies geschieht entweder manuell über den Parameter »FILE_NAME_CONVERT« oder automatisch durch die Nutzung von OMF. Die Autoren raten hier der Einfachheit halber zur Nutzung von OMF und ASM ( Listing 1 ).

Wie in Listing 1 zu sehen ist, müssen PDBs vor der Nutzung und nach jedem Start der Instanz manuell geöffnet werden. Hierzu kann man einen Trigger schreiben oder aber die Grid-Infrastruktur benutzen. Über Oracle Restart lassen sich wie gehabt Ressourcen und ihre Abhängigkeiten registrieren, überwachen, gegebenenfalls automatisch neu starten beziehungsweise in der richtigen Reihenfolge starten und stoppen. Dies geht mit PDBs über Services. Sobald man einen Service anlegt und diesen mit einer PDB verknüpft, wird die verknüpfte Datenbank automatisch geöffnet, wenn der entsprechende Service startet.

Die verfügbaren Informationen auf Ebene der CDB und der PDB folgen dem Prinzip der Sichtbarkeit. So enthält ein AWR-Report – ausgeführt in einer PDB – nur Informationen über die bestreffende PDB. Ein AWR-Report auf Ebene der CDB enthält hingegen Informationen über alle Datenbanken. Ähnlich verhält es sich mit den zusätzlichen Views mit dem Präfix »CDB_« . Sie enthalten Informationen über alle PDBs.

Upgrade-Pfade

Der Weg von einer Non-PDB zu einer PDB erfolgt auf drei Arten: Export/Import mittels DataPump (ab 10g Release 1; ältere Versionen müssen gegebenenfalls einen Zwischenschritt machen), GoldenGate oder Umwandlung einer Non-CDB in eine PDB. Hierbei muss die 10g- oder 11g-Datenbank auf 12c aktualisiert werden ( Abbildung 3 ). Bei der Umwandlung kann die Datenbank nach dem Upgrade auf 12c mit dem Package DBMS_PDB in eine PDB konvertiert und in eine CDB eingestöpselt werden. Direkte Upgrades sind bisher von 10.2.0.5, 11.1.0.7 und 11.2.0.2 und höher möglich; das Resultat ist dann zunächst eine Non-CDB.

Abbildung 3: Etliche Neuerungen betreffen auch die erleichterte Installation und Upgrades von früheren Oracle-Versionen auf das neue Release.

Die Nutzung dieses neuen Konzepts setzt die Enterprise Edition voraus und benötigt darüber hinaus zusätzlich die Multitenancy-Lizenz. Sie kostet nach Listenpreis genauso viel wie die Enterprise Edition an sich. Die Standard Edition kann auch PDBs benutzen – allerdings ist da die Anzahl der möglichen Datenbanken auf eine begrenzt. Dies mag wie ein schlechter Scherz klingen, aber in der nächsten Version 12.2 wird es keine klassischen Non-CDB-Datenbanken mehr geben, sodass Non-PDB-Datenbanken konvertiert werden müssten – auch in der Standard Edition.