Desaster Recovery für die Standard Edition Two
Eine immer wieder kontrovers geführte Diskussion ist die über Hochverfügbarkeit und Desaster Recovery mit der Standard Edition Two (SE2). Sicherlich gibt es RAC für SE2 aber in Bezug auf Desaster Recovery is von Oracle kaum eine Hilfe zu erwarten und somit ist dbvisit Standby die in meinen Augen einzig ernstzunehmende Alternative.
… und dann kam Multitenant!
Refreshable Pluggable Database
Mit der Version 12.2 gibt es einige interessante Erweiterungen für die Multitenant Database Architektur. Unter anderem das lokale Undo Management. Wir werden sicherlich noch einen Blog darüber schreiben. Auf der DOAG Datenbank Konferenz im Mai 2017 habe ich mich mit einigen Kollegen von unterschiedlichen Unternehmen unterhalten und dann kam die Bemerkung „du bist doch ein SE2 Fan und beschäftigst dich außerdem intensiv mit Multitenant. Probier doch mal aus, ob man mit Refreshable Pluggable Database nicht eine Standby Lösung für SE2 aufbauen kann“.
Während meiner Tests las ich dann einen Tweet über einen Blog von Franck Pachot, in dem er das „poor-man standby“ erklärte. Danke an Franck für diese sehr hilfreiche Information.
Die Refreshable Pluggable Database ist eine Kopie einer Pluggable Database, die entweder automatisch zu bestimmten Zeiten oder manuell, per SQL Befehl, aktualisiert wird. Während der Aktualisierung muss die PDB geschlossen sein (genau so wie bei Data Guard), aber ansonsten kann sie auch zum Lesen genutzt werden. Wenn die PDB allerdings zum Schreiben geöffnet wird, besteht keine Beziehung mehr zur Quell-PDB und die Konfiguration muss anschließend neu aufgebaut werden.
Aber so ähnlich war es bis vor einigen Jahren bei der Standby Datenbank auch und somit ist das für mich, verglichen mit dem, was ich bekomme, keine große Einschränkung.
Automatic Pluggable Database Refresh
Wie man eine leere CDB oder auch eine PDB angelegt, setze ich an dieser Stelle voraus, d.h. meine Konfiguration besteht aus der CDB UDO“ mit der PDB „CELLO“ auf dem Server „lindenberg“ als Quelle und der CDB „HERBERT“ auf dem Server „groenemeyer“ (ohne PDB) als Ziel.
Das Anlegen einer PDB aus einer existierenden (Cloning) erfolgt, so es sich nicht um die gleiche CDB handelt, über einen Datenbank Link. Also müssen wir zunächst einen Common User anlegen und unter diesem dann einen Datenbank Link. Um später auch eine „umgekehrte Standby Datenbank aufzubauen, empfehle ich, den Benutzer und Datenbank Link auf beiden Datenbanken anzulegen.
SQL> CREATE USER c##johannes IDENTIFIED BY manager CONTAINER=ALL; SQL> GRANT connect, sysoper, dba TO c##johannes CONTAINER=ALL;
Quelle (UDO)
SQL> CREATE DATABASE LINK herbert CONNECT TO c##johannes IDENTIFIED BY manager USING 'HERBERT';
Ziel (HERBERT)
SQL> CREATE DATABASE LINK udo CONNECT TO c##johannes IDENTIFIED BY manager USING 'UDO';
Mit diesen Vorarbeiten kann jetzt eine neue PDB, die wir in diesem Falle ebenfalls „CELLO“ nennen, in der CDB „HERBERT“ angelegt werden:
SQL> CREATE PLUGGABLE DATABASE cello FROM cello@UDO
file_name_convert=('UDO','HERBERT')
REFRESH MODE EVERY 1 MINUTE;
Das ist schon alles!
Mit dem Befehl wird eine neue PDB in der Datenbank HERBERT angelegt und, solange die PDB nicht geöffnet wird, regelmäßig aktualisiert. Wenn man die PDB zum Lesen öffnet, wird das „Apply“ angehalten und nach dem Schließen wieder fortgeführt.
Sicherlich fehlt noch die Erfahrung über den tatsächlichen „Gap“ im Falle eines Failovers und auch der Overhead auf der Quell-PDB muss noch ermittelt werden. Trotzdem halte ich diese Methode für eine sehr interessante Standby Alternative. Über Feedback zu diesem Thema (und natürlich auch allen anderen Blogs) würden wir uns sehr freuen.
Wichtiger Hinweis
Bitte beachten Sie, dass Sie auf der Ziel-CDB keine weitere PDB erstellen oder öffnen dürfen, weil Sie damit die Lizenzbedingungen für den Einsatz der Standard Edition Two verletzten.