Minimal Downtime Migrationen mit „RMAN Backup As Copy“

By | 2. Juli 2020
0 Comment

Für das Verschieben und Kopieren von Oracle Datenbanken gibt es vielfältige Methoden. Duplicate Database mit dem Oracle Recovery Manager (RMAN) und Export/Import mit Datapump sind sicherlich die am häufigst verwendeten Verfahren, um Datenbanken auf einen anderen Server zu migrieren. Eine weiteres, welches ich kürzlich in einem Migrationsprojekt angewendet habe, ist das „RMAN Backup As Copy“-Verfahren.  Es ist relativ einfach umzusetzen und es ermöglicht auch große Datenbanken ohne allzugroße Unterbrechnung der Anwendung auf einen anderen Server zu migrieren. Wie der Name des Verfahrens schon vermuten lässt, wird eine RMAN-Feature genutzt, welches im Grunde für das bit-identische Sichern von Datenbankfiles entwickelt wurde, aber auch für das Kopieren von Datenbankfiles genutzt werden kann. Diese Verfahren möchte ich anhand eines Beispiels genauer erläutern und für die Durchführung einen kleinen Leitfaden zur Verfügung stellen.

Oracle Migration

Eigenschaften „RMAN Backup As Copy“ Migration

  • RMAN Image Copy Backups werden verwendet, um die Datenbankdateien online auf den Zielserver zu kopieren
  • Datafiles werden bis zum GoLive über inkrementelle RMAN Backups aktualisiert
  • Nur eine minimale Downtime für den Wechsel zur Zieldatenbank erforderlich
  • Datenbankname bleibt gleich
  • Datenbank-ID (DBID) bleibt gleich
  • Für Migrationen von ASM zu Filesystem und umgekehrt geeignet
  • Für Container-Datenbanken und Nicht-Multitenant gleichermaßen verwendbar
  • Die Quelldatenbank bleibt intakt
  • Eine Auxiliary-Datenbankinstanz muss auf dem Zielserver vorbereitet werden
  • Nicht geeignet, um einzelne Pluggable Databases (PDB) zu migrieren

Bedingungen

  • Die Quelldatenbank ist vom Zielserver aus über das Netzwerk erreichbar
  • Die Quelldatenbank muss im Archivelog-Modus sein
  • Quell- und Zielserver verwenden die gleiche Endianess
  • Die Zieldatenbank nutzt Oracle Managed Files (OMF) – Nicht zwingend, aber empfohlen, da dies die Migration stark vereinfacht!

Phase 1: Zielserver und Auxiliary-Instanz vorbereiten

Um eine Datenbank mit der “RMAN Backup As Copy”-Methode auf einen neuen Zielserver migrieren zu können, müssen auf dem Zielserver die Voraussetzungen für die Aufnahme der Kopie der Datenbank geschaffen werden und eine sogenannte Auxiliary-Instance gestartet sein. Eine Auxiliary-Instance ist nichts anderes als eine Hilfs-Instanz die für diesen Vorgang.

Die unten aufgeführte Liste enthält die zu erledigenden Migrations-Vorbereitungen, die bei einer Single Instance Datenbank unter Linux notwendig sind. Es wird angenommen, dass noch keine Datenbanksoftware auf dem Zielserver installiert ist und, dass die Zieldatenbank nicht schon zuvor einmal mit dem DBCA angelegt worden ist. Was übrigens auch eine gute Möglichkeit wäre, um die Voraussetzungen zu schaffen. Dann müste man allerdings vor der Migration die Datenbankfiles manuell löschen und ggf. Parameter und Passwörter analog dem Quellsystem anpassen. Bitte beachten, dass bei Verwendung von Oracle Restart oder der Oracle Clusterware hier ergänzende Schritte erforderlich wären, um z.B. Listener und Datenbank-Instanz dem Oracle Restart bzw. der Oracle Clusterware als Ressource hinzuzufügen. Um die Komplexität dieser Anleitung gering zu halten, verzichte ich an der Stelle darauf. Abweichende Szenarien oder der Betrieb unter Windows erfordert eine angepasste Vorgehensweise.

Auf dem Zielserver:

  • Datenbanksoftware in gleicher Version und Patchstand installieren
  • Oracle Listener erstellen und starten
  • Speicherungort der Datenbank anlegen
    • Bei ASM-Nutzung: Oracle Restart bzw. Oracle Cluster installieren und mindestens eine große ASM Diskgroup für die Datenbankfiles anlegen (z.B. DATA). Bei Bedarf noch eine ASM Diskgroup für die Fast Recovery Area erstellen (z.B. FRA)
    • Bei Filesystem-Nutzung: Ein ausreichend großes Verzeichnis für Aufnahme der Datenbank anlegen. Bei Bedarf noch weitere Verzeichnisse anlegen, falls die Redologs in separaten Verzeichnissen liegen sollen
  • Verzeichnis für die Audit-Files anlegen (Siehe Parameter audit_file_dest)
  • Server-Parameterfile (spfile) der Quell-Datenbankinstanz auf den Zielserver kopieren bzw. neu anlegen
  • Passwort-File der Quell-Datenbank auf den Zielserver kopieren ($ORACLE_HOME/dbs/pwfile<SID>.ora)
  • TNS-Eintrag in der tnsnames.ora für den Listener anlegen (Parameter LOCAL_LISTENER), damit sich die Datenbank bei diesem registrieren kann
  • TNS-Einträge in der tnsnames.ora für den Zugriff auf die Quelldatenbank hinzufügen (Details siehe unten)
  • Eintrag der Zieldatenbank in der/etc/oratabvornehmen

Beispiel-Szenario:

Die Container-Datenbank CDB01, die auf dem Server ora01srv.vbox.de läuft, soll auf den Server ora02srv.vbox.de umziehen. Quell- und Zielserver sind beides Linux-Systeme. Auf dem Quellsystem liegt die Datenbank im Filesystem. Auf dem Zielsystem soll diese in ASM liegen.

TNS-Vorbereitung für die Migration

Auf dem Quellserver einen TNS-Eintrag für die Verbindung mit der Zieldatenbank-Instanz hinzufügen.

$ORACLE_HOME/network/admin/tnsnames.ora

CDB01_DEST =
  (DESCRIPTION =
     (ADDRESS = (PROTOCOL = TCP)(HOST = ora02srv.vbox.de)(PORT = 1521))
     (CONNECT_DATA =
        (SERVER = DEDICATED)
        (SERVICE_NAME = CDB01)(UR = A)
     )
   )

Der Eintrag “(UR = A)” ist hier wichtig, damit man sich an die nicht gemountete Instanz auf dem Zielserver verbinden kann!

Auf dem Zielserver zwei TNS-Einträge für die Verbindung mit der Quell- und Zieldatenbank-Instanz hinzufügen.

$ORACLE_HOME/network/admin/tnsnames.ora

CDB01_SOURCE =
   (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ora01srv.vbox.de)(PORT = 1521))
      (CONNECT_DATA =
         (SERVER = DEDICATED)
         (SERVICE_NAME = CDB01)
      )
   )

CDB01_DEST =
  (DESCRIPTION =
     (ADDRESS = (PROTOCOL = TCP)(HOST = ora02srv.vbox.de)(PORT = 1521))
     (CONNECT_DATA =
        (SERVER = DEDICATED)
        (SERVICE_NAME = CDB01)(UR = A)
     )
  )

 

Phase 2: Zieldatenbank aus einer Image-Kopie der Quelldatenbank erstellen

1. Zieldatenbank-Instanz im Nomount-Modus starten

Wenn alle Vorbereitungen richtig getroffen worden sind, lässt sich die Zieldatenbank-Instanz mit dem Spfile im Nomount-Status starten.

Auf dem Zielserver

export ORACLE_SID=CDB01
export ORACLE_HOME=/u01/app/oracle/product/19/dbhome_1
sqlplus / sysdba
SQL> startup nomount
ORACLE instance started.

Total System Global Area 1073741824 bytes
Fixed Size 2932632 bytes
Variable Size 377487464 bytes
Database Buffers 687865856 bytes
Redo Buffers 5455872 bytes

2. Datenbankparameter ändern

Der Schritt ist NICHT notwendig, wenn alle Pfade der Datenbank im Quell- und Zielsystem gleich bleiben und bereits Oracle Managed Files genutzt werden!

Sollen oder müssen sich spezifische Datenbank-Instanzparameter auf dem Zielsystem ändern, hat man nun noch Gelegenheit diese anzupassen. Wenn sich z.B. die vorgesehenen Pfade für die Datenbankdateien, Controlfiles und der Auditdateien auf dem Zielsystem vom Quellsystem unterscheiden, müssten die entsprechenden Instanz-Parameter noch geändert werden, damit die Dateien an den richtigen Ort kopiert werden können. Ich empfehle auf jeden Fall Oracle Managed Files (OMF) für die Zieldatenbank zu verwenden, damit das nachfolgende Kopieren einfacher gelingt! Um OMF zu nutzen muss der Parameter DB_CREATE_FILE_DEST und optional der Parameter DB_CREATE_ONLINE_LOG_DEST_<n> gesetzt sein.

ParameterDB_CREATE_FILE_DESTauf den Speicherort der Datenbank setzen.

Beispiel, wenn die Datenbank im ASM liegen soll.

SQL> alter system set DB_CREATE_FILE_DEST='+DATA' scope=both;

Beispiel, wenn die Datenbank in einem Filesystem liegen soll.

SQL> alter system set DB_CREATE_FILE_DEST='/u02/oradata' scope=both;

Optional Parameter DB_CREATE_ONLINE_LOG_DEST_1 auf den geplanten Speicherort der Redologs setzen, falls sich der Pfad von der Quelldatenbank unterscheidet. Wenn der Parameter nicht gesetzt wird, wird als Standardpfad für die Redologs der Pfad des Parameters DB_CREATE_FILE_DEST genutzt und für die Redolo-Kopien, sofern genutzt, der Pfad zur Recovery Area.

Beispiel wenn die Redologs in einem Filesystem liegen sollen.

SQL> alter system set DB_CREATE_ONLINE_LOG_DEST_1='/u03/oraredo' scope=both;

Bestehenden Controlfile-Parameter löschen. Durch die Verwendung von OMF muss kein Pfad für die Controlfiles im Spfile spezifiziert werden.

SQL> alter system reset CONTROL_FILES scope=spfile;

Parameter für die Audit-Files auf das zuvor angelegte Verzeichnis setzen, falls sich der Pfad vom Quellsystem unterscheidet.

SQL> alter system set AUDIT_FILE_DEST='/u01/app/oracle/admin/cdb01/adump' scope=both;
SQL> exit
SQL> shutdown immediate
SQL> startup

 

3. Anmeldung an beide Datenbank-Instanzen mit RMAN

Die vorgestellte Methode erfordert es, dass auf dem Quell- sowie Zielsystem ein Oracle Listener gestartet ist, da eine Verbindung zu beiden Datenbanken über die Service Namen der jeweiligen Instanzen hergestellt werden muss. Eine Bequeath-Session unter Umgehung des Listeners kann man dafür nicht nutzen. In der Regel befindet sich die Quelldatenbank im geöffneten Zustand und wird von Datenbankanwendungen weiterhin genutzt.

Auf dem Zielserver

rman target sys@CDB01_SOURCE auxiliary sys@CDB01_DEST
Recovery Manager: Release 19.0.0.0.0 - Production on Mon Jun 29 16:07:37 2020
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.

target database Password:
connected to target database: CDB01 (DBID=3830024509)
auxiliary database Password:
connected to auxiliary database: CDB01 (not mounted)

4. Datenbank mittels “Backup as Copy” auf das Zielsystem kopieren

Mit folgendem Befehl werden anschließend die Datenbankdateien der Quelldatenbank online auf das Zielsystem kopiert. Der Format-Bezeichner NEW bewirkt, dass die Datenbankdateien als Oracle Managed Files (OMF) angelegt werden sollen und in den unter dem Instanz-Parameter DB_CREATE_FILE_DEST festgelegten Pfad kopiert werden.

RMAN> backup as copy database auxiliary format NEW;
Starting backup at 29-JUN-20
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=26 device type=DISK
channel ORA_DISK_1: starting datafile copy
input datafile file number=00001 name=/u02/oradata/DB12C01/datafile/o1_mf_system_hhjyz0sc_.dbf
output file name=+DATA/CDB01/DATAFILE/system.297.1044374931 tag=TAG20200629T160850
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting datafile copy
input datafile file number=00002 name=/u02/oradata/DB12C01/datafile/o1_mf_sysaux_hhjyzb21_.dbf
output file name=+DATA/CDB01/DATAFILE/sysaux.298.1044374947 tag=TAG20200629T160850
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:07
channel ORA_DISK_1: starting datafile copy
input datafile file number=00003 name=/u02/oradata/DB12C01/datafile/o1_mf_undotbs1_hhjyzhxf_.dbf
output file name=+DATA/CDB01/DATAFILE/undotbs1.299.1044374953 tag=TAG20200629T160850
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:07
channel ORA_DISK_1: starting datafile copy
input datafile file number=00004 name=/u02/oradata/DB12C01/datafile/o1_mf_users_hhjyzp4s_.dbf
output file name=+DATA/CDB01/DATAFILE/users.300.1044374961 tag=TAG20200629T160850
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
Finished backup at 29-JUN-20
RMAN> exit

5. Controlfile mittels “Restore Controlfile from Service” kopieren

Auf dem Zielserver

rman target sys@CDB01_DEST
RMAN> restore controlfile from service CDB01_SOURCE;
Starting restore at 29-JUN-20
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=12 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service CDB01_SOURCE
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
output file name=+DATA/CDB01/CONTROLFILE/current.301.1044375989
output file name=+FRA/CDB01/CONTROLFILE/current.272.1044375989
Finished restore at 29-JUN-20
RMAN> alter database mount;

6. Kopierte Datenbankfiles katalogisieren und aktivieren

Der Schritt ist NICHT notwendig, wenn die Pfade der Datenbankfiles im Quell- und Zielsystem identisch sich!

Wenn sich die Pfade der Datenbankfiles zwischen Quell- und Zieldatenbank unterscheiden, weil z.B. die Quelldatenbank in einem Filesystem und die Zieldatenbank im ASM liegt, dann müssen die neue Pfade der Datenbankfiles dem zuvor kopierten Controlfile mit “catalog start with <pfad>” bekannt gemacht werden.

Beispiel, wenn die Zieldatenbank nun im Filesystem liegt.

RMAN> catalog start with '/u02/oradata/CDB01/' noprompt;

Beispiel, wenn die Zieldatenbank nun in ASM liegt.

RMAN> catalog start with '+DATA/CDB01/' noprompt;
Starting implicit crosscheck backup at 30-JUN-20
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=261 device type=DISK
Crosschecked 1 objects
Finished implicit crosscheck backup at 30-JUN-20

Starting implicit crosscheck copy at 30-JUN-20
using channel ORA_DISK_1
Finished implicit crosscheck copy at 30-JUN-20

searching for all files in the recovery area
cataloging files...
no files cataloged

searching for all files that match the pattern +DATA/CDB01

List of Files Unknown to the Database
=====================================
File Name: +DATA/CDB01/spfilecdb19c02.ora
File Name: +DATA/CDB01/A925580233FC4409E053CA42A8C0CCE5/DATAFILE/undotbs1.312.1044433559
File Name: +DATA/CDB01/A925580233FC4409E053CA42A8C0CCE5/DATAFILE/system.314.1044433565
File Name: +DATA/CDB01/A925580233FC4409E053CA42A8C0CCE5/DATAFILE/sysaux.316.1044433571
File Name: +DATA/CDB01/A925580233FC4409E053CA42A8C0CCE5/DATAFILE/users.318.1044433577
File Name: +DATA/CDB01/A924CDCB20AF2791E053CA42A8C0A799/DATAFILE/undotbs1.311.1044433557
File Name: +DATA/CDB01/A924CDCB20AF2791E053CA42A8C0A799/DATAFILE/system.313.1044433563
File Name: +DATA/CDB01/A924CDCB20AF2791E053CA42A8C0A799/DATAFILE/sysaux.315.1044433569
File Name: +DATA/CDB01/DATAFILE/system.308.1044433521
File Name: +DATA/CDB01/DATAFILE/sysaux.309.1044433533
File Name: +DATA/CDB01/DATAFILE/undotbs1.310.1044433549
File Name: +DATA/CDB01/DATAFILE/users.317.1044433575
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: +DATA/CDB01/A925580233FC4409E053CA42A8C0CCE5/DATAFILE/undotbs1.312.1044433559
File Name: +DATA/CDB01/A925580233FC4409E053CA42A8C0CCE5/DATAFILE/system.314.1044433565
File Name: +DATA/CDB01/A925580233FC4409E053CA42A8C0CCE5/DATAFILE/sysaux.316.1044433571
File Name: +DATA/CDB01/A925580233FC4409E053CA42A8C0CCE5/DATAFILE/users.318.1044433577
File Name: +DATA/CDB01/A924CDCB20AF2791E053CA42A8C0A799/DATAFILE/undotbs1.311.1044433557
File Name: +DATA/CDB01/A924CDCB20AF2791E053CA42A8C0A799/DATAFILE/system.313.1044433563
File Name: +DATA/CDB01/A924CDCB20AF2791E053CA42A8C0A799/DATAFILE/sysaux.315.1044433569
File Name: +DATA/CDB01/DATAFILE/system.308.1044433521
File Name: +DATA/CDB01/DATAFILE/sysaux.309.1044433533
File Name: +DATA/CDB01/DATAFILE/undotbs1.310.1044433549
File Name: +DATA/CDB01/DATAFILE/users.317.1044433575

List of Files Which Were Not Cataloged
=======================================
File Name: +DATA/CDB01/spfilecdb01.ora
RMAN-07518: Reason: Foreign database file DBID: 0 Database Name:

Mit “Switch database to copy” werden die neue Pfade anschließend aktiviert.

RMAN> switch database to copy;
datafile 1 switched to datafile copy "+DATA/CDB01/DATAFILE/system.308.1044433521"
datafile 2 switched to datafile copy "+DATA/CDB01/A924CDCB20AF2791E053CA42A8C0A799/DATAFILE/system.313.1044433563"
datafile 3 switched to datafile copy "+DATA/CDB01/DATAFILE/sysaux.309.1044433533"
datafile 4 switched to datafile copy "+DATA/CDB01/A924CDCB20AF2791E053CA42A8C0A799/DATAFILE/sysaux.315.1044433569"
datafile 5 switched to datafile copy "+DATA/CDB01/DATAFILE/undotbs1.310.1044433549"
datafile 6 switched to datafile copy "+DATA/CDB01/A924CDCB20AF2791E053CA42A8C0A799/DATAFILE/undotbs1.311.1044433557"
datafile 7 switched to datafile copy "+DATA/CDB01/DATAFILE/users.317.1044433575"
datafile 8 switched to datafile copy "+DATA/CDB01/A925580233FC4409E053CA42A8C0CCE5/DATAFILE/system.314.1044433565"
datafile 9 switched to datafile copy "+DATA/CDB01/A925580233FC4409E053CA42A8C0CCE5/DATAFILE/sysaux.316.1044433571"
datafile 10 switched to datafile copy "+DATA/CDB01/A925580233FC4409E053CA42A8C0CCE5/DATAFILE/undotbs1.312.1044433559"
datafile 11 switched to datafile copy "+DATA/CDB01/A925580233FC4409E053CA42A8C0CCE5/DATAFILE/users.318.1044433577"

7. Datenbank mittels “Recover Database noredo from Service” aktualisieren

Der folgende Befehl bewirkt, dass die Zieldatenbank mit den in der Quelldatenbank geänderten Blöcke aktualisiert wird.

RMAN> recover database noredo from service CDB_SOURCE;
Starting recover at 30-JUN-20
using channel ORA_DISK_1
skipping datafile 2; already restored to SCN 1116480
skipping datafile 4; already restored to SCN 1116480
skipping datafile 6; already restored to SCN 1116480
skipping datafile 8; already restored to SCN 1223606
skipping datafile 9; already restored to SCN 1223606
skipping datafile 10; already restored to SCN 1223606
skipping datafile 11; already restored to SCN 1223606
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using network backup set from service CDB01_SOURCE
destination for restore of datafile 00001: +DATA/CDB01/DATAFILE/system.308.1044433521
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using network backup set from service CDB01_SOURCE
destination for restore of datafile 00003: +DATA/CDB01/DATAFILE/sysaux.309.1044433533
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using network backup set from service CDB01_SOURCE
destination for restore of datafile 00005: +DATA/CDB01/DATAFILE/undotbs1.310.1044433549
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using network backup set from service CDB01_SOURCE
destination for restore of datafile 00007: +DATA/CDB01/DATAFILE/users.317.1044433575
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

Finished recover at 30-JUN-20

Solange die Quelldatenbank noch durch eine Datenbankanwendung geändert wird, kann dieser Vorgang bis zum GoLive beliebig oft wiederholt werden!

Phase 3: GoLive – Wechsel zur Zieldatenbank

Zum geplanten GoLive-Zeitpunkt, sprich, wenn die Zieldatenbank die Aufgabe der Quelldatenbank übernehmen soll, muss die Quelldatenbank gestoppt und ein letztes Mal das Controlfile sowie die Blöcke, die sich seit der letzen Synchronisation verändert haben, kopiert werden. Der Umstand, dass nur noch die letzen Änderungen eingespielt werden müssen, ermöglicht es, dass die dafür erforderliche Downtime auf ein Minimum reduziert werden kann. Allerdings muss man dabei berücksichtigen, dass dabei im Hintergrund ein Incremental Backup durchgeführt wird. Wenn kein Block Change Tracking aktiviert ist (Nur in der Enterprise Edition verfügbar), dann kann dies etwas länger dauner, da alle Datafiles gescanned werden müssen.  Im besten Fall dauert dieser Vorgang aber nur wenige Minuten.

8. Quelldatenbank in den Mount-Status setzen

Damit keine Änderungen mehr an der Quelldatenbank durchgeführt werden können, diese aber dennoch für die Zieldatenbank-Instanz erreichbar ist, muss diese in den Mount-Status versetzt werden. Die Quelldatenbank muss dazu unbedingt sauber mit einem “shutdown immediate” heruntergefahren werden, damit implizit ein Checkpoint durchgeführt wird und somit noch alle geänderten SGA-Buffer aus dem Cache in die Datenbankfiles geschrieben werden.

Auf dem Quellserver

sqlplus / as sysdba
SQL> shutdown immediate
SQL> startup mount

9. Controlfile letztmalig mittels “Restore Controlfile from Service” kopieren

Auf dem Zielserver

rman target sys@CDB01_DEST
RMAN> shutdown immediate
RMAN> startup nomount
RMAN> restore controlfile from service CDB01_SOURCE;
RMAN> alter database mount;

10. Kopierte Datenbankfiles katalogisieren und aktivieren

Der Schritt ist NICHT notwendig, wenn die Pfade der Datenbankfiles im Quell- und Zielsystem identisch sind!

a) Beispiel, wenn die Datenbank nun im Filesystem liegt

RMAN> catalog start with '/u02/oradata/CDB01/' noprompt;

b) Beispiel, wenn die Datenbank nun in ASM liegt

RMAN> catalog start with '+DATA/CDB01/' noprompt;
RMAN> switch database to copy;

11. Datenbank letztmalig mittels “Recover Database noredo from Service” aktualisieren

RMAN> recover database noredo from service CDB01_SOURCE;

12. Zieldatenbank öffnen und Redologfiles erstellen

Die Zieldatenbank kann nun mit „open resetlogs“ geöffnet werden. Dabei werden die Redologs und auch die Tempfiles erstellt.

RMAN> alter database open resetlogs;

Wenn ASM verwendet wird, werden die Redologs standardmaßig in der ASM Group der Fast Recovery Area, sofern verwendet, und der ASM Group, die mit dem Parameter DB_CREATE_FILE_DEST festgelegt wurde, erstellt.

Pfade der Redologs und Tempfiles prüfen.

RMAN> select name from v$tempfile union select member from v$logfile;
NAME
--------------------------------------------------------------------------------
+DATA/CDB01/A9243A643C1E3CBEE053C942A8C036C4/TEMPFILE/temp.278.1044278879
+DATA/CDB01/A924C9986DFC56ECE053C942A8C00089/TEMPFILE/temp.284.1044281263
+DATA/CDB01/TEMPFILE/temp.277.1044278879
+DATA/CDB01/ONLINELOG/group_1.268.1044278835
+DATA/CDB01/ONLINELOG/group_2.269.1044278839
+DATA/CDB01/ONLINELOG/group_3.270.1044278845
+FRA/CDB01/ONLINELOG/group_1.261.1044278837
+FRA/CDB01/ONLINELOG/group_2.262.1044278843
+FRA/CDB01/ONLINELOG/group_3.263.1044278849
RMAN> exit

Phase 4: Quelldatenbank herunterfahren

Nach erfolgreicher Migration kann die Quelldatenbank heruntergefahren werden. Darüberhinaus sollte man dafür sorgen, dass diese nach einem Serverstart nicht automatisch gestartet wird.

13. Shutdown der Quelldatenbank

Auf dem Quellserver

sqlplus / as sysdba
SQL> shutdown immediate
SQL> exit