Mit der Release 2 der Oracle Datenbank 12c bekommt der DBA eine Vielfalt neuer Funktionalitäten, die dem Datenbankadministrator die Arbeit in Zukunft um einiges erleichtern werden. Eines dieser neuen Features ist das Hot Cloning und Relocate von Pluggable Databases, das in diesem Artikel kurz näher vorgestellt wird.
Die Oracle Datenbank 12c Release 2 bringt mit der Multitenant-Architektur viele tolle Features, die man vorher nicht benutzen konnte. Zuallererst sollten wir aber die Aussage des Artikeltitels ein wenig einschränken und erläutern, welcher Themenkreis in diesem Artikel beleuchtet wird.
Eine Migration ohne Downtime ist mehr ein Wunsch als Wirklichkeit, aber mit der Version 12.2 kommen wir dem Ziel näher. Im gegenständlichen Artikel werden wir über die Möglichkeit Pluggable Databases online zu kopieren/migrieren beschreiben.
Ein Blick in die Vergangenheit
In der Version 11.2 hatte der Datenbankadministrator folgende Möglichkeiten, um eine Datenbank von einem System auf ein anderes System zu migrieren:
- Duplicate
- Datapump
- Restore/Recover via RMAN
- GoldenGate
Welchen Weg man letztendlich wählen wird, hängt ganz von der Situation und den Voraussetzungen ab. Es geht hier nicht um Cross-Platform-Migrationen oder um Migrationen zwischen Systemen mit unterschiedlicher Endianness. Jede Option verlangt gewisse Vorbereitungen und birgt auch mögliche, verborgene Gefahren mit sich, die dann erst im Zuge der Migration sichtbar werden.
Variante „Duplicate“
Bei einem Duplicate hat der Benutzer die Möglichkeit entweder direkt über SQL*Net, oder aus einem vorhandenen Backup, eine Kopie der Datenbank zu erstellen. Die Duplicate Methode ist eigentlich die einfachste, weil man hier entweder nur Firewall Freischaltungen zwischen den Servern benötigt oder man alternativ auf ein Backup, meistens von einem NFS Share oder einer Bandsicherung, zugreift. Wenn zwischen den Servern ein leistungsstarkes Netzwerk zur Verfügung steht, dann führt man am besten den Befehl DUPLICATE TARGET DATABASE TO … FROM ACTIVE DATABASE aus oder benutzt Backups die entweder in einer BACKUP LOCATION gespeichert oder aus Bandsicherungen gezogen werden. Oracle automatisiert dabei einige Tätigkeiten die man bei Restores sonst manuell machen muss. Grundsätzlich ist es ein automatischer Restore/Recover der Quelldatenbank mit Veränderungen der Datafile Pfade und der DBID.
Variate „Datapump“
Die Variante Datapump ermöglicht dem Datenbankadministrator logische Datenbankbackups zu erstellen, auf ein neues Ziel zu übertragen und dort wieder zu importieren. Datapump bietet auch Features wie Transportable Tablespace oder Full Transportable Export. Dabei werden nur Metadaten exportiert und diese dann mit allen Datafiles kopiert und am Ziel importiert.
Variante „klassische Migration“
Bei der klassischen Migration einer Datenbank mittels RMAN Restore/Recover wird eine Datenbank auf Basis eines Backups neu aufgebaut.
Variante „GoldenGate“
Als letzte Option bleibt GoldenGate. Bei GoldenGate handelt es sich um eine kostenpflichtige Replikationssoftware, die es erlaubt nahezu Zero Downtime Migrationen durchzuführen. GoldenGate unterstützt zudem auch noch andere Datenbankanbieter wie MySQL, MS SQL und Hadoop.
Multitenant Architektur
Mit der Version 12.1 hat Oracle eine neue Datenbankarchitektur eingeführt – die Multitenant Architektur (CDB Architektur). Die Multitenant Architektur wird in Zukunft die derzeitige Non-CDB Architektur ersetzen. In der 12.1 Dokumentation findet man bereits den entsprechenden Hinweis auf die „Deprecation of Non-CDB Architecture“ für kommende Oracle Releases nach 12.2. Oracle empfiehlt hier auf die CDB Architektur zu schwenken. Multitenant ist prinzipiell eine kostenpflichtige Option zur Enterprise Edition, jedoch als Single tenant in allen Oracle Editionen enthalten.
Container Datenbank
Während es vor 12.1 nur eine 1:1-Beziehung zwischen Instanz und Datenbank gab (beim RAC ist es eine n:1-Beziehung), verändert sich das jetzt mit der Multitenant Architektur. In der Multitenant Architektur werden alle gemeinsamen Systemobjekte in eine neue, zentrale, Datenbank – die Container Datenbank (CDB) – gepackt, die alle notwendigen Funktionalitäten bereits vorinstalliert hat. Die eigentlichen Benutzerdaten befinden sich in sogenannten Pluggable Databases (PDB), die in die Containerdatenbank eingehängt werden.
In der Version 12.1 konnte man Datenbanken, die bereits als Pluggable Database definiert waren wesentlich einfacher kopieren, als noch in älteren Versionen ohne Multitenant Architektur. Man musste die Quelldatenbank lediglich in den Read Only Modus setzen und anschließend ein CREATE PLUGGABLE DATABASE Statement ausführen. Im einfachsten Fall bekommt man mit dem Kommando CREATE PLUGGABLE DATABASE ORCL2 FROM ORCL1 bereits eine lokale Kopie der Datenbank.
Mit der Multitenant Architektur bringt Oracle dem Benutzer eine Vielfalt von Features die das Provisionieren von Datenbanken leichter machen. Man bekommt eine Konsolidierungsplattform für Datenbanken in der man mit dem Ressource Manager Systemressourcen optimal zuteilen kann um wichtigeren Datenbanken mehr Performance zuzusichern. Weiters eine Automationsplattform in der man Datenbank Templates vordefinieren kann um im Anlassfall schnell PDBs zu erstellen oder klonen zu können. Das Kopieren von PDBs geht in 12.1 nicht ganz ohne Downtime ab. Im Internet findet man Artikel die ohne den Read Only Modus eine Kopie der PDBs ermöglichen, in 12.1 ist es jedoch nicht möglich PDBs online zu kopieren. Die Quelldatenbank geht hier in den Quiesce Modus, was mit einer Downtime vergleichbar ist.
Die Gegenwart – Hot Cloning und Relocate
Mit der Version 12.2 wird der Traum des DBAs jedoch endlich wahr: Die von vielen erwartete Lösung für das online kopieren von PDBs. Dieses Feature kommt in Begleitung mit einem anderen neuen Feature, den Local Undo Tablespaces. Um Datenbanken wirklich online kopieren zu können, braucht man die Container Datenbank im Local Undo Mode (und natürlich im Archivelog Mode).
Das Aktivieren des Local Undo Modes in der CDB erstellt automatisch in jeder PDB einen eigenen Undo Tablespace, welcher wiederum Voraussetzung für Flashback, PDBPITR und Hot Cloning in der PDB ist.
Um den Leser nicht weiter auf die Folter zu spannen, schauen wir uns das RELOCATE-Feature in Aktion an. Hier wird die Datenbank automatisch auf eine andere Instanz transferiert und alle DMLs und DDLs bis zum Öffnen der Pluggable Datenbank werden automatisch im Hintergrund verarbeitet, um die Datenbank konsistent zu halten.
In unserem Szenario haben wir 2 virtuelle Maschinen, ora01 und ora02 mit Version 12.2.0.1 Enterprise Edition installiert, die ora01 verwaltet die cdb1 und ora02 die cdb2.
Beide Datenbanken sind im gleichen Netz, als Storage benutzen wir ASM, das erleichtert auch die Namenskonvention für die Datafiles. Diese Funktionalität (mit und ohne RELOCATE) funktioniert auch in der 12.2 SE2.
Um keine Lizenzverletzung zu begehen, denken Sie daran, dass in einer CDB nur eine Benutzer PDB existieren darf. Mehrere Benutzer PDBs verlangen die Multitenant Option und damit Enterprise Edition.
sys@cdb1 SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 ORCL MOUNTED
sys@cdb1 SQL> alter pluggable database orcl open ;
Pluggable database altered.
sys@cdb2 SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
Um die Datenbank auf die neue Maschine zu transferieren, sind ein paar Vorbereitungen nötig. Zuerst ist ein Common User anzulegen, der die notwendigen Privilegien bekommt. Ein in der Dokumentation offensichtlich entdeckter Fehler wird am Ende des Beispiels beschrieben.
sys@cdb1 SQL> create user c##dba identified by oracle container=all ;
User created.
sys@cdb1 SQL> grant create session, create pluggable database to c##dba container=all ;
Grant succeeded.
sys@cdb1 SQL> grant sysoper to c##dba container=all ;
Grant succeeded.
Um die PDB zu erreichen, brauchen wir einen Connect-Descriptor, der die Datenbank identifiziert. In unserem Beispiel werden wir den Alias CDB1 in der tnsnames.ora der CDB2 anlegen.
CDB1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = ora01)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = cdb1)
)
)
Als vorletzte Voraussetzung brauchen wir einen Public Database Link von der CDB2 in die CDB1.
sys@cdb2 SQL> create public database link cdb1
connect to c##dba identified by oracle using 'cdb1' ;
Database link created.
Nachdem wir alle Voraussetzungen erfüllt haben, können wir die Datenbank auf die CDB2 migrieren. Diese Tätigkeit erledigt man mit einem Kommando auf der CDB2:
sys@cdb2 SQL> create pluggable database orcl from orcl@cdb1 relocate ;
Pluggable database created.
Nach dem Erstellen der PDB bleibt die neue PDB in der CDB2 im Zustand MOUNTED. Ohne den Zusatz RELOCATE würden wir einen Hot Clone der PDB „orcl“ erstellen. Um die Near Zero Downtime Migration zu zeigen, erstellen wir in der PDB „orcl“ auf CDB1, die immer noch im Read Write Modus ist, einen neuen Benutzer und eine Tabelle.
sys@cdb1 SQL> alter session set container=orcl ;
Session altered.
sys@cdb1 SQL> create tablespace data ;
Tablespace created.
sys@cdb1 SQL> create user psorger identified by oracle default tablespace data quota unlimited on data;
User created.
sys@cdb1 SQL> grant connect, resource to psorger ;
Grant succeeded.
sys@cdb1 SQL> create table PSORGER.EMP as select level id from dual connect by level<=10 ;
Table created.
Nachdem wir die Tabelle erstellt haben, können wir die neue PDB in der CDB2 öffnen.
Mit dem folgenden Kommando wird die PDB auf CDB1 gelöscht und die PDB auf CDB2 im Read Write Modus geöffnet.
sys@cdb2 SQL> alter pluggable database orcl open ;
Pluggable database altered.
sys@cdb2 SQL> alter session set container=orcl ;
Session altered.
sys@cdb2 SQL> select count(*) from psorger.emp ;
COUNT(*)
----------
10
Nach dem Öffnen der neuen PDB sehen wir, dass alle DML/DDL Statements erfolgreich übertragen wurden.
Um den Fehler in der Dokumentation zu beschreiben werden wir dem C##DBA die Rolle SYSOPER entziehen und SYSDBA vergeben. Mit dieser Rolle vergibt man eigentlich Superprivilegien und logischerweise erwarten wir, dass das funktioniert.
sys@cdb1 SQL> revoke sysoper from C##DBA container=all ;
Revoke succeeded.
sys@cdb1 SQL> grant sysdba to C##DBA container=all ;
Grant succeeded.
sys@cdb2 SQL> select sysdate from dual@cdb1 ;
SYSDATE
---------
09-MAY-17
sys@cdb2 SQL> create pluggable database orcl from orcl@cdb1 ;
Pluggable database created.
sys@cdb2 SQL> create pluggable database orcl1 from orcl@cdb1 relocate ;
create pluggable database orcl1 from orcl@cdb1 relocate
*
ERROR at line 1:
ORA-17628: Oracle error 1031 returned by remote Oracle server
ORA-01031: insufficient privileges
Wie wir hier sehen ist ein Online Clone der Datenbank möglich, aber beim Relocate bekommt der C##DBA mit SYSDBA Privilegien dennoch einen insufficient Privileges Fehler.
Es scheint, dass man dieses Verhalten als einen Bug entweder in der Dokumentation oder in der Software bezeichnen kann.
In der Zukunft werden wir es bestimmt erfahren. 🙂
Um diesen Artikel abzurunden, möchte ich noch die neuen Features der Oracle Public Cloud erwähnen.
Ein neues Feature, der direkte SQL*Net Zugang in die Cloud, erleichtert ab 12.2 die Migration von On-Premise Datenbanken in die Cloud und zurück. Mit diesen zwei neuen Features bekommt der Benutzer die Möglichkeit sehr einfach in die Cloud zu wechseln, dort etwa Performance-Tests durchzuführen und dann die Datenbank wieder zurück ins eigene Rechenzentrum zu verschieben.
Gerade das ist ein Feature, das bei anderen Cloud-Anbietern aktuell kaum zu finden ist!
Durch das neue SMF Goal Service kann eine kritische Applikation als Ziel definiert und überwacht werden, um schnell den Zustand des Systems zu erkennen.
