von Sebastian Solbach ORACLE Deutschland B.V. & Co.KG
Mit der neuen Multitenant Datenbankarchitektur mit Container Datenbank (CDB) und den dazugehörigen Pluggable Datenbanken (PDB) kommen
auf CDB Ebene einige neue Funktionalitäten hinzu. Zwar ändert sich für den Administrator einer einzelnen PDB kaum etwas,
aber einige Spezialitäten sollte der Datenbank Administrator auf Ebene der PDB bzw. CDB doch kennen.
Eine dieser Auswirkungen ist der Umgang mit Datendateien. Denn entgegen der Annahme, dass der CDB Administrator auf alle Datendateien
Zugriff hat, ist dem nicht so - zumindest nicht direkt. Wie man trotzdem einfach damit umgehen kann wird im folgenden kurz beschrieben.
Auswirkung "verlorener" Datendateien
Im Normalfall werden Datendateien der einzelnen PDBs nur dann benötigt, wenn versucht wird die einzelnen PDBs zu öffnen.
Fehlen die Datendateien einer PDB, können diese auch bei laufender CDB aus einem Backup wiederhergestellt werden.
Alternativ kann aber auch entschieden werden, diese zur Laufzeit mit dem Befehl "DROP PLUGGABLE DATABASE" einfach zu löschen.
Es gibt aber ein Szenario, welches gesondert betrachtet werden sollte:
- Die PDB war geöffnet
- Datendateien der PDB gehen verloren
- Es liegt kein Backup der Datendateien vor oder die CDB läuft im NOARCHIVELOG Modus
- Die CDB fällt aus oder wird mit "SHUTDOWN ABORT" heruntergefahren.
In diesem Fall kann die CDB nicht sofort wieder gestartet werden, da ein Mediarecovery für die Datendateien der betroffenen
PDB erwartet wird. Wenn ein Recovery der PDB aber nicht möglich ist, zum Beispiel bei Fehlen eines Backups, stellt sich die Frage,
wie die CDB mit den restlichen, intakten PDBs geöffnet werden kann.
So geschehen bei unserer Testdatenbank, in der wir mit vielen PDBs experimentierten: Die Datendateien
einer PDB (pdb02), die zum Löschen anstand, wurden einfach und schnell mit Hilfe des Betriebssystems gelöscht.
(rm -rf des kompletten Verzeichnisses). Das Löschen der PDB mit "DROP PLUGGABLE DATABASE" wurde aber versäumt und
geriet in Vergessenheit.
Später kam es in unserer Umgebung nach einigen Logfile-Switches zu einem Datenbank Crash:
Ob Instance Crash oder "SHUTDOWN ABORT": der Versuch, die CDB wieder zu starten, wird mit folgender Fehlermeldung verhindert:
In diesen Momenten lernt man den Vorteil eines guten Backup und Recovery schätzen, da das vorliegende Szenario
nun mit einem RMAN Restore schnell behoben wäre.
Allerdings braucht auch dies Zeit und wenn die betroffene PDB zum Löschen anstand, ist es nicht gerade effizient, diese
erst einmal aus dem Backup wiederherzustellen, um sie dann korrekt zu löschen.
In Testumgebungen wird gelegentlich auf Backup & Recovery und auf die Verwendung des ARCHIVELOG Modus verzichtet.
Stellt sich also die Frage nach einer Alternativlösung.
Offline nehmen von Datendateien in PDBs
In der Multitenant Architektur ist zu beachten, dass die Verbindung als SYSDBA zum Starten der Instanz der CDB gilt
und nicht der PDB. Demnach kann aus dieser Verbindung heraus auch keine Datendatei einer PDB auf "OFFLINE FOR DROP"
gesetzt werden. Erschwerend kommt in diesem Augenblick hinzu, dass ein PDB Administrator noch keinen Zugriff auf die PDB hat, solange die
CDB sich nur im MOUNT-Stadium befindet, da der Service der PDB noch nicht gestartet wurde.
Wie kann man diesen Teufelskreis nun durchbrechen?
Eigentlich ist die Lösung des Problems recht einfach, dennoch denkt man nicht direkt daran:
Der SYSDBA hat die Möglichkeit in jeden Container mit Hilfe von "ALTER SESSION SET CONTAINER" zu wechseln,
auch wenn die Datenbank sich noch im Mount Status befindet, bzw. die PDBs noch gar nicht geöffnet sind.
Bevor nun wieder in den Root Container gewechselt wird um die CDB zu öffnen, sollten auch die anderen gelöschten
Datendateien auf "OFFLINE FOR DROP" gesetzt werden. Damit man nicht iterativ zwischen den Containern CDB$ROOT und
dem PDB Container hin und her springen muss, ermittelt man die zu kennzeichnenden Datendateien über folgendes SQL:
Nachdem alle entsprechenden Datendateien "OFFLINE FOR DROP" markiert sind, kann in die CDB zurück gewechselt werden und die Datenbank
mit allen restlichen PDBs gestartet werden:
Als Letztes sollte man dann noch daran denken die PDB richtig zu löschen, denn die Datendateien fehlen ja immer noch:
Sollte, wie es sich eigentlich für jede halbwegs produktive Datenbank gehört, der ARCHIVELOG Modus aktiviert sein und ein Backup verwendet werden,
kann man im RMAN eine Besonderheit erkennen. Dieser kann nämlich die PDB eigentlich auch bei einer geöffneten
CDB wiederherstellen (es sei denn man hat einen "SHUTDOWN ABORT" durchgeführt und kann die Datenbank im Moment nicht öffnen).
RMAN besitzt in 12c nämlich die "ALTER SESSION SET CONTAINER" Funktionalität implizit, indem beim Befehl "SQL" die PDB mitgegeben wird,
wie hier am Recovery Script erkennbar. Dieses wurde im Übrigen über die beiden Befehle "LIST FAILURE" und "ADVISE FAILURE" erstellt:
D.h. der Befehl in RMAN für eine Datenbank im NOARCHIVE Modus hätte auch so aussehen können:
Fazit
Auch hier zeigt sich, dass die neue Multitenant Architektur zumindest für den DBA doch einige Neuerungen mitbringt.
Umso wichtiger sich frühzeitig mit der künftigen Technologie auseinander zu setzen.
Ebenfalls wird deutlich, dass im Umfeld von CDBs, die eindeutig Vorteile bei der Konsolidierung bieten, genau
hierfür ein entsprechendes Backup und Recovery Konzept vorhanden sein muss. Definitiv gilt:
eine konsolidierte Umgebung ohne RMAN Backup zu betreiben ist fast schon grob fahrlässig.
Nützliche Links und Referenzen
DBA Community - Dezember 2013