Blog Name
  • Januar 2019

Datenbanken in die Cloud bringen mit PDB Relocate

Nach der Entscheidung, Oracle Datenbanken in der Cloud zu betreiben und bereits laufende Datenbanken in die Cloud zu verschieben, stellt sich die Frage, wie die Daten möglichst reibungslos in die Cloud transportiert werden. Dieser Tipp zeigt einen Weg auf, der möglichst wenig Downtime für die betroffene Datenbank beinhaltet und dennoch einfach und reibungslos durchzuführen ist.

Eine Datenbank kann grundsätzlich verschiedenartig transportiert werden. So kann zum Beispiel im einfachen Fall die Datenbank in der Cloud aus einem Backup oder durch Zuhilfenahme von Data Pump Dumpfiles wiederhergestellt werden. Dabei ist natürlich eine größere Downtime zu beachten, denn während des Datentransports ist die Datenbank nicht verfügbar. Als Alternative bieten sich Standby-Lösungen an, die ihrerseits aufwändiger in der Handhabung sind.

Für alle Oracle Datenbankversionen ab der Version 12.2 gibt es aber noch eine weitere Alternative, die sowohl einfach in der Handhabung, als auch mit relativ wenig Downtime verbunden ist: PDB Relocate. Voraussetzung dafür ist, dass die zu transportierende Datenbank eine Pluggable Database (PDB) ist. Dabei spielt es keine Rolle, ob die kostenpflichtige Option "Multitenant" eingesetzt wird, oder die zu transportierende Datenbank im sogenannten "Single Tenant" Modell betrieben wird, bei dem eine PDB in einer Container Datenbank (CDB) läuft. Dementsprechend kann dieses Verfahren auch für die Standard Edition eingesetzt werden.

Vorweg eine kurze Beschreibung des Features PDB Relocate:

Es gibt zwei Container Datenbanken, eine Quell-CDB und eine Ziel-CDB. Eine in der Quell-CDB befindliche PDB soll von der Quell-CDB zur Ziel-CDB verschoben werden. Dazu wird zunächst ein Datenbanklink von der Ziel-CDB auf die Quell-CDB erstellt. Dann wird die PDB in der Ziel-CDB neu erstellt und alle Daten von der PDB in der Quell-CDB kopiert. Dieser Datentransport geschieht zwischen den Datenbanken mit den normalen Mitteln von SQL*Net, also auch verschlüsselt, sobald die entsprechenden Parameter eingestellt sind. Während des Kopiervorgangs ist die PDB in der Quell-CDB ganz normal benutzbar, also lesend UND schreibend. Dieses führt natürlich dazu, dass nach dem Kopiervorgang zunächst keine konsistente Kopie in der Ziel-CDB angefertigt wurde.

Deshalb wird nach dem Kopiervorgang ein Redo-Log-Apply (vergleichbar mit einem Recovery) durchgeführt. Das alles geschieht vollkommen automatisch und währenddessen ist die PDB in der Quell-CDB immer noch uneingeschränkt benutzbar, also ohne Downtime für die Anwendungen. Wenn die Daten der PDB (in der Ziel-CDB) fast konsistent aktualisiert sind, wird die neue PDB geöffnet. In diesem Moment wird für diese PDB der letzte Redo-Log-Apply durchgeführt und die PDB in der Quell-CDB trennt sich von allen Datenbanksitzungen.

Es wird sichergestellt, dass alle mit Commit festgeschriebenen Transaktionen auch in der neuen PDB Gültigkeit haben. Alle nicht festgeschriebenen Transaktionen werden zurückgerollt, wir haben aus der Sicht der Anwendung also die volle Oracle Transaktionskonsistenz. Sobald die neue PDB in der Ziel-CDB geöffnet ist, kann sie normal benutzt werden. Dazu verwendet man die neue Adresse (Connect String) oder nutzt die Tatsache, dass im Rahmen des PDB Relocates die alte PDB zur "Proxy-PDB" wird und ein Redirect zur neuen PDB durchführt. Dieses kann natürlich nur dann funktionieren, wenn die Netzwerke und Firewalleinstellungen dieses zulassen.

Da der ganze Vorgang auf der Nutzung der Redo-Log Daten basiert, sollten die beteiligten CDBs im ARCHIVELOG Modus betrieben werden, damit über die archivierten Redo Log Dateien alle Informationen zur Verfügung stehen.



Wenn man sich nun dieses Feature betrachtet, dann gibt es genau einmal eine relativ kleine Downtime, wenn die neue PDB geöffnet wird. Je größer die zu transportierende Datenbank ist, desto länger dauert zwar der Transport der Daten in die neue PDB, aber ohne dass die Anwendungen davon betroffen sind. Um die Downtime während des Öffnens der neuen PDB zu minimieren sollte einfach nur ein Zeitpunkt mit wenig Transaktionslast gewählt werden, damit die Menge der Transaktionsdaten für das abschließende Redo-Log-Apply möglichst klein ist.

Ich möchte an dieser Stelle auch darauf hinweisen, dass PDB Relocate auch sehr gut für das Patchen von PDBs geeignet ist, also die Quell-CDB "ungepatcht" (also ohne Patch oder alter Patchstand) und die Ziel-CDB gepatcht sein kann. In diesem Fall muß aber natürlich noch eine Anpassung des Data Dictionaries erfolgen und das Tool "datapatch" ausgeführt werden.

In diesem Tipp soll anhand eines Beispiels gezeigt werden, wie eine ungepatchte Oracle Datenbank (Enterprise Edition) in der Version 12.2 in die Oracle Cloud transportiert und dabei auf einen neuen Bundle-Patch Stand gebracht wird. Dazu müssen Sie in der Quell-CDB als Vorbereitung einen Datenbankbenutzer als Common User einrichten, der spezielle Rechte hat. Später wird die Ziel-CDB über diesen Datenbankbenutzer die Datenbank kopieren. Führen Sie also in der Quell-CDB folgendes aus:

# Create a common admin user in the Source-CDB
sqlplus sys/<password>@//<host>:<listener_port>/<cdb-service> as sysdba @prepare_relocate_create_common_user.sql

mit

prepare_relocate_create_common_user.sql = 
set echo on feedback on
CREATE USER c##admin IDENTIFIED BY <password>;
GRANT connect,resource,create pluggable database,sysoper TO c##admin CONTAINER=ALL;
exit

Die zu transportierende PDB und die darauf operierenden Anwendungen bekommen davon nichts mit.

Jetzt wird nur noch auf der Ziel-CDB Seite gearbeitet. Es wird davon ausgegangen, dass Sie in der Oracle Cloud einen Datenbankservice für die Datenbankversion ab 12.2 eingerichtet haben, und dass die gewählte Edition den Funktionsumfang enthält, den Sie auch in der PDB on Premise nutzen. Die Netzwerkeinstellungen müssen so gestaltet sein, dass der Datenbankservice per Datenbanklink auf Ihre heimische Datenbank zugreifen kann. Auf der anderen Seite muß Ihre heimische Datenbank (bzw. Rechner, VM, Firewall, Netzwerk) so eingestellt sein, dass der Listener Port für den Datenbank-Service in der Cloud offen ist. Für den Kopiervorgang der Daten wird nur dieser Port des Listeners gebraucht. Wenn dieses alles gegeben ist, legen Sie in der Ziel-CDB den gleichen Datenbankbenutzer wie eben an:

# Create a common admin user in the Destination-CDB
sqlplus sys/<password>@//<host>:<listener_port>/<cdb-service> as sysdba @prepare_relocate_create_common_user.sql

mit

prepare_relocate_create_common_user.sql = 
set echo on feedback on
CREATE USER c##admin IDENTIFIED BY <password>;
GRANT connect,resource,create pluggable database,sysoper TO c##admin CONTAINER=ALL;
exit

Jetzt wird ein Datenbanklink von der Ziel-CDB auf die Quell-PDB erstellt:

# Create a public database link to the unpatched CDB 
sqlplus sys/<password>@//<host>:<listener_port>/<cloud-cdb-service>  as sysdba @create_dblink_to_cdb12_2_from_cloud.sql

mit

create_dblink_to_cdb12_2_from_cloud.sql = 
ALTER SYSTEM SET global_names=false;
CREATE PUBLIC DATABASE LINK db_link_to_cdb12_2 CONNECT TO c##admin IDENTIFIED BY <password> 
USING '(DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=<Service name of Source_CDB>))(ADDRESS=(PROTOCOL=TCP)(HOST=<Hostname of Source CDB>)(PORT=<Listener Port of Source CDB>)))';
SELECT 'DB Link does work' from dual@db_link_to_cdb12_2;
exit

Da in meinem Beispiel in der Oracle Cloud die Netzwerkeinstellungen so getroffen wurden, dass die Netzwerkdomains in der Cloud und in meinem Rechenzentrum nicht übereinstimmten, musste der Parameter "global_names" auf FALSE gesetzt werden, um den Datenbanklink erstellen zu können. Sobald die PDB abschließend in der Oracle Cloud läuft, kann dieser Parameter wieder zurück auf den Standardwert TRUE gesetzt werden. Beachten Sie, dass die PDB in der Quell-CDB immer noch normal läuft und die Anwendungen von unseren Aktionen nichts mitbekommen.

Im nächsten Schritt wird das PDB Relocate gestartet:

# Relocate PDB
sqlplus sys/<password>@//<host>:<listener_port>/<cloud-cdb-service> as sysdba @relocate_pdb_1_cloud.sql

mit relocate_pdb_1_cloud.sql

CREATE PLUGGABLE DATABASE pdb1 FROM pdb1@db_link_to_cdb12_2  RELOCATE AVAILABILITY MAX;
SELECT pdb_name,status FROM cdb_pdbs;
exit

Jetzt beginnt der Kopiervorgang, bei dem die PDB in der Quell-CDB weiter normal benutzt werden kann. Die Anwendungen bekommen immer noch nichts von unserer Aktion mit. Das Skript sollte mit folgender Ausgabe enden (hier für den Tipp formatiert):

PDB_NAME          STATUS
----------------- ----------
PDB$SEED          NORMAL
:
PDB1              RELOCATING

Wir sind nun in einem Zustand, der mit einer Standby-Datenbank vergleichbar ist. Eine Kopie der PDB wird nun stetig auf den aktuellen Stand gebracht. Unsere Anwendungen laufen ganz normal auf der PDB in der Quell-CDB in unserem Rechenzentrum weiter. Der eigentliche Schwenk erfolgt mit dem Öffnen der neuen PDB:

s# Open relocated PDB
sqlplus sys/<password>@//<host>:<listener_port>/<cloud-cdb-service> as sysdba @open_relocated_pdb.sql

mit

open_relocated_pdb.sql = 
ALTER PLUGGABLE DATABASE pdb1 OPEN;
SELECT pdb_name,status FROM cdb_pdbs;
SELECT name,open_mode from v$pdbs; 
exit

Dieser Vorgang dauert einige Minuten. Die genaue Dauer hängt davon ab, wieviele Transaktionsdaten noch eingespielt werden müssen. Währenddessen werden die Datenbanksitzungen getrennt, die für die PDB in der Quell-CDB bestehen. Aus der Sicht der Anwendungen gibt es jetzt also eine Downtime. Die Ausgabe des Skripts sollte wie folgt aussehen (für den Fall, dass auch gepatcht werden soll):

PDB_NAME          STATUS
----------------- ----------
PDB$SEED          NORMAL
:
PDB1              RELOCATING


Warning: PDB altered with errors.

PDB_NAME          STATUS
----------------- ----------
PDB$SEED          NORMAL
:
PDB1              NORMAL


NAME        OPEN_MODE
----------- ----------
PDB$SEED    READ ONLY
:
PDB1        READ WRITE
exit

Die Meldung "Warning: PDB altered with errors." erfolgt aufgrund der Tatsache, dass der Patchstand der ungepatchten PDB (also deren Data Dictionary Inhalt) nicht zum Patchstand der Ziel-CDB passt. Bei gleichem Patchstand muß nichts mehr gemacht werden und die PDB ist geöffnet.

Prüfen Sie den Status der PDB mit:

# Get Patch Status for PDB
sqlplus sys/<password>@//<host>:<listener_port>/<cloud-cdb-service> as sysdba @get_pdb_patch_info.sql

mit

get_pdb_patch_info.sql =
set echo on feedback on linesize 200 
col name format a10  
col type format a10  
col message format a30  
col status format a10  
col action format a30 
SELECT name,type,message,status,action FROM pdb_plug_in_violations; 
exit 

Ausgabe:
NAME	   TYPE       MESSAGE			     STATUS	ACTION
---------- ---------- ------------------------------ ---------- ------------------------------
PDB1	   WARNING    CDB parameter processes mismat PENDING	Please check the parameter in
		      ch: Previous 320 Current 200		the current CDB

PDB1	   WARNING    CDB parameter memory_target mi PENDING	Please check the parameter in
		      smatch: Previous 692M Current		the current CDB
		      0

PDB1	   WARNING    CDB parameter compatible misma PENDING	Please check the parameter in
		      tch: Previous '12.2.0' Current		the current CDB
		       '12.2.0.0'
 
PDB1	   WARNING    CDB parameter open_cursors mis PENDING	Please check the parameter in
		      match: Previous 300 Current 10		the current CDB
		      00

PDB1	   WARNING    There are common XDB schema ty PENDING	Please execute xdb.DBMS_XMLSTO
		      pes missing from ROOT.			RAGE_MANAGE.GetTypeDDL

PDB1	   ERROR      DBRU bundle patch 180417 (DATA PENDING	Call datapatch to install in t
		      BASE APR 2018 RELEASE UPDATE 1		he PDB or the CDB
		      2.2.0.1.180417): Installed in
		      the CDB but not in the PDB.

PDB1	   ERROR      SQL patch ID/UID 27475613/2202 PENDING	Call datapatch to install in t
		      8200 (OJVM RELEASE UPDATE: 12.		he PDB or the CDB
		      2.0.1.180417 (27475613)): Inst
		      alled in the CDB but not in th
		      e PDB.

PDB1	   WARNING    Tablespace SYSTEM is not encry PENDING	Encrypt the tablespace.
		      pted. Oracle Cloud mandates al
		      l tablespaces should be encryp
		      ted.

PDB1	   WARNING    Tablespace SYSAUX is not encry PENDING	Encrypt the tablespace.
		      pted. Oracle Cloud mandates al
		      l tablespaces should be encryp
		      ted.

PDB1	   WARNING    Tablespace USERS is not encryp PENDING	Encrypt the tablespace.
		      ted. Oracle Cloud mandates all
		       tablespaces should be encrypt
		      ed.

Wenn Sie solche Fehler finden, führen Sie das Tool "datapatch" aus:

# Perform datapatch
$ORACLE_HOME/OPatch/datapatch -verbose

Nach der Ausführung von "datapatch" (nur nur dann erforderlich) sollte die PDB noch einmal neu durchgestartet werden:

# Reboot PDB
sqlplus sys/<password>@//<host>:<listener_port>/<cloud-cdb-service> as sysdba @reboot_pdb.sql

mit reboot_pdb.sql = 

ALTER PLUGGABLE DATABASE pdb1 CLOSE;
ALTER PLUGGABLE DATABASE pdb1 OPEN READ WRITE;
exit

Prüfen Sie den Status der PDB mit:

# Get Patch Status for PDB
sqlplus sys/<password>@//<host>:<listener_port>/<cloud-cdb-service> as sysdba @get_pdb_patch_info.sql

mit

get_pdb_patch_info.sql =
set echo on feedback on linesize 200 
col name format a10  
col type format a10  
col message format a30  
col status format a10  
col action format a30 
SELECT name,type,message,status,action FROM pdb_plug_in_violations; 
exit 

Ausgabe:
NAME	   TYPE       MESSAGE			     STATUS	ACTION
---------- ---------- ------------------------------ ---------- ------------------------------
PDB1	   WARNING    CDB parameter processes mismat RESOLVED	Please check the parameter in
		      ch: Previous 320 Current 200		the current CDB

PDB1	   WARNING    CDB parameter memory_target mi RESOLVED	Please check the parameter in
		      smatch: Previous 692M Current		the current CDB
		      0

PDB1	   WARNING    CDB parameter compatible misma RESOLVED	Please check the parameter in
		      tch: Previous '12.2.0' Current		the current CDB
		       '12.2.0.0'
 
PDB1	   WARNING    CDB parameter open_cursors mis RESOLVED	Please check the parameter in
		      match: Previous 300 Current 10		the current CDB
		      00

PDB1	   WARNING    There are common XDB schema ty RESOLVED	Please execute xdb.DBMS_XMLSTO
		      pes missing from ROOT.			RAGE_MANAGE.GetTypeDDL

PDB1	   ERROR      DBRU bundle patch 180417 (DATA RESOLVED	Call datapatch to install in t
		      BASE APR 2018 RELEASE UPDATE 1		he PDB or the CDB
		      2.2.0.1.180417): Installed in
		      the CDB but not in the PDB.

PDB1	   ERROR      SQL patch ID/UID 27475613/2202 RESOLVED	Call datapatch to install in t
		      8200 (OJVM RELEASE UPDATE: 12.		he PDB or the CDB
		      2.0.1.180417 (27475613)): Inst
		      alled in the CDB but not in th
		      e PDB.

PDB1	   WARNING    Tablespace SYSTEM is not encry PENDING	Encrypt the tablespace.
		      pted. Oracle Cloud mandates al
		      l tablespaces should be encryp
		      ted.

PDB1	   WARNING    Tablespace SYSAUX is not encry PENDING	Encrypt the tablespace.
		      pted. Oracle Cloud mandates al
		      l tablespaces should be encryp
		      ted.

PDB1	   WARNING    Tablespace USERS is not encryp PENDING	Encrypt the tablespace.
		      ted. Oracle Cloud mandates all
		       tablespaces should be encrypt
		      ed.

Was jetzt noch fehlt, ist das Verschlüsseln der Tablespaces, falls dieses gewünscht wird.

Hinweis 1: Wenn Ihr Datenbankservice in der Oracle Cloud und Ihre Datenbank on premise beide vom Typ "Enterprise Edition" sind, werden sie oben die folgenden Hinweise bekommen:

PDB1 ERROR Database option APS mismatch: PENDING Fix the database option in the
PDB installed version 12.2.0.1 PDB or the CDB
.0. CDB installed version NULL
.

PDB1 ERROR Database option XOQ mismatch: PENDING Fix the database option in the
PDB installed version 12.2.0.1 PDB or the CDB
.0. CDB installed version NULL

Das liegt daran, dass in Ihrer PDB zwei OLAP Funktionsbereiche (deren Nutzung separat über die OLAP Option zu lizenzieren sind) installiert sind, die in dem Cloud Service aber nicht installiert sind. Wenn Sie diese Funktionen nutzen möchten, und dafür eine Lizenz haben, müssen Sie mindestens den Datenbankservice "High Performance" erstellen, in dem diese Funktionen auch enthalten sind. Nutzen Sie diese Funktionen nicht, können Sie diese entfernen. Das Vorgehen wird in diesem Blog von Mike Dietrich oder dieser MOS Note beschrieben.

Hinweis 2: Die Verschlüsselung des Datentransports ist dadurch gesichert, dass auf der Seite des Cloud Services die entsprechenden Parameter für SQL*Net so gesetzt sind, dass ohne Verschlüsselung kein Datentransfer zustande kommt:

SQLNET.ENCRYPTION_SERVER=REQUIRED
SQLNET.CRYPTO_CHECKSUM_SERVER=REQUIRED
SQLNET.ENCRYPTION_TYPES_SERVER=(AES256,AES192,AES128)
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER=(SHA1)
SQLNET.ENCRYPTION_CLIENT=REQUIRED
SQLNET.CRYPTO_CHECKSUM_CLIENT=REQUIRED
SQLNET.ENCRYPTION_TYPES_CLIENT=(AES256,AES192,AES128)
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT=(SHA1)

Wenn Sie auf der Seite der Quell-CDB keine Veränderungen dieser Parameter vorgenommen haben (der Default ist der Wert ACCEPTED), steht dem verschlüsselten Datentransfer nichts im Wege. Sollten Sie hier die Verschlüsselung explizit abgeschaltet haben, wird der Datentransport nicht durchgeführt.

 
Fazit

Mit PDB Relocate kann eine Oracle Datenbank leicht und mit wenig Downtime in die Cloud verlagert werden. Auch an diesem Beispiel zeigt sich, dass selbst im "Single Tenant" Modell die Nutzung von Pluggable Datenbanken von Vorteil ist.

 
Lizenzhinweis

PDB Relocate ist auch verwendbar für Single Tenant Umgebungen.

Weitere Informationen


 

Zurück zum Anfang des Artikels

Zurück zur Community-Seite
 

Visit the Oracle Blog

 

Contact Us

Oracle

Integrated Cloud Applications & Platform Services