Blog 
Cloning mit RMAN ist einfach!

In diesem Blog geht es darum, wie man ein RMAN Backup dazu nutzt, eine Kopie einer Datenbank zu erstellen.

In meinem letzten Blog „Recovery mit RMAN ist einfach!“ bin ich darauf eingegangen, wie RMAN im Fehlerfall bei der Fehlerbehebung helfen kann.

Allerdings kommt es, zum Glück, nur selten zu Fehlern, die ein Recovery einer Datei erfordern. Und auch das Restore und Recovery von Datenbanken ist eher selten. Oft steht man aber vor der Herausforderung, eine Kopie einer Datenbank auf einem anderen Server / Stage zur Verfügung zu stellen. Zwar kann man das ganz elegant mit dem RMAN Duplicate Kommando durchführen. Aber es bietet sich an, im Zuge eines Clonings zu testen, ob das RMAN Backup auch tatsächlich funktioniert. Also spielen wir doch einfach das Backup auf einem anderen Server wieder ein.

Zuerst benötigen wir das Backup auf dem neuen Server (hier clapton). Außerdem bietet es sich an, erstmalig ein SPFILE zu erstellen, um die Testdatenbank bzw. den Clone auch mit anderen Parametern als die Produktion starten zu können.

Quelle (simon)

SQL> CREATE pfile='/tmp/initPAUL.ora' from spfile;
simon:% scp /tmp/initPAUL.ora clapton:/tmp
simon:% scp -r /u03/orabackup/PAUL clapton:/u03/orabackup/PAUL 

Bevor wir die Instanz starten können, müssen noch ein paar Verzeichnisse angelegt werden. Unter anderem für die Audit Dateien, ohne die die Datenbank nicht starten würde.

clapton:% mkdir –p /opt/oracle/admin/PAUL/adump
clapton:% mkdir –p /opt/oracle/admin/PAUL/dpdump
clapton:% mkdir –p /u02/oradata
clapton:% mkdir –p /u03/orabackup
clapton:% chown –R oracle:oinstall /opt/oracle/admin /u02/oradata /u03/orabackup 

Jetzt wird die Instanz auf dem zweiten Server (clapton) gestartet (ggf. mit geänderten Parametern):

clapton:% sqlplus / as sysdba
 
SQL> CREATE SPFILE FROM PFILE='/tmp/initPAUL.ora’;
 
SQL> startup nomount 

Da das spfile den Parameter db_recovery_file_dest enthält, „weiß“ die Datenbankinstanz, wo das Backup, was wir vorher kopiert haben, liegt. Sollten Sie hier eine andere Verzeichnisstruktur haben, müssen Sie nur den Parameter entsprechend anpassen. Somit können wir jetzt das Controlfile aus dem Backup wieder herstellen:

RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
 
Starting restore at 29-MAY-19
using channel ORA_DISK_1
 
recovery area destination: /u03/orabackup
database name (or database unique name) used for search: PAUL
channel ORA_DISK_1: AUTOBACKUP /u03/orabackup/PAUL/autobackup/2019_05_29/o1_mf_s_1009541851_ggwq1w6x_.bkp found in the recovery area
AUTOBACKUP search with format "%F" not attempted because DBID was not set
channel ORA_DISK_1: restoring control file from AUTOBACKUP /u03/orabackup/PAUL/autobackup/2019_05_29/o1_mf_s_1009541851_ggwq1w6x_.bkp
channel ORA_DISK_1: control file restore from AUTOBACKUP complete
output file name=/u02/oradata/PAUL/controlfile/o1_mf_gfqy132z_.ctl
output file name=/u03/orabackup/PAUL/controlfile/o1_mf_gfqy13hk_.ctl
Finished restore at 29-MAY-19 

Im nächsten Schritt lesen wir das Controlfile (Status Mount) und Restoren die Datenbank.

RMAN> ALTER DATABASE MOUNT;
released channel: ORA_DISK_1
Statement processed 

RMAN> RESTORE DATABASE;
 
Starting restore at 29-MAY-19
Starting implicit crosscheck backup at 29-MAY-19
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=38 device type=DISK
Crosschecked 23 objects
Finished implicit crosscheck backup at 29-MAY-19
 
Starting implicit crosscheck copy at 29-MAY-19
using channel ORA_DISK_1
Finished implicit crosscheck copy at 29-MAY-19
 
searching for all files in the recovery area
cataloging files...
cataloging done
 
 
List of Cataloged Files
=======================
File Name: /u03/orabackup/PAUL/autobackup/2019_05_29/o1_mf_s_1009547148_ggww7djy_.bkp
 
using channel ORA_DISK_1
 
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u02/oradata/PAUL/datafile/o1_mf_system_gfqxv3xm_.dbf
channel ORA_DISK_1: restoring datafile 00003 to /u02/oradata/PAUL/datafile/o1_mf_sysaux_gfqxy3cn_.dbf
channel ORA_DISK_1: restoring datafile 00004 to /u02/oradata/PAUL/datafile/o1_mf_undotbs1_gfqxztmj_.dbf
channel ORA_DISK_1: restoring datafile 00007 to /u02/oradata/PAUL/datafile/o1_mf_users_gfqxzvw6_.dbf
channel ORA_DISK_1: reading from backup piece /u03/orabackup/PAUL/backupset/2019_05_29/o1_mf_nnndf_TAG20190529T134448_ggww5jj6_.bkp
 channel ORA_DISK_1: piece handle=/u03/orabackup/PAUL/backupset/2019_05_29/o1_mf_nnndf_TAG20190529T134448_ggww5jj6_.bkp tag=TAG20190529T134448
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting datafile backup set restore
…
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
Finished restore at 29-MAY-19 

Jetzt fehlt nur noch das Recovery, also das Anwenden der archivierten Redolog-Dateien.

RMAN> RECOVER DATABASE;
 
Starting recover at 29-MAY-19
using channel ORA_DISK_1
 
starting media recovery
 
archived log for thread 1 with sequence 13 is already on disk as file /u03/orabackup/PAUL/archivelog/2019_05_29/o1_mf_1_13_ggww7bkc_.arc
archived log file name=/u03/orabackup/PAUL/archivelog/2019_05_29/o1_mf_1_13_ggww7bkc_.arc thread=1 sequence=13
unable to find archived log
archived log thread=1 sequence=14
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 05/29/2019 14:16:46
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 14 and starting SCN of 1599466 

Den Fehler an dieser Stelle können wir ignorieren, da er nur besagt, dass die nächste archivierte Redolog-Datei nicht existiert. Das ist aber auch so gewollt.

Schließlich können wir die Datenbank öffnen und nachsehen, ob sie dem Original entspricht.

Somit haben wir zwei Fliegen mit einer Klappe geschlagen:

  1. Wir haben eine Prozedur, um jederzeit einen Clone einer Datenbank zu erstellen.
  2. Wir haben verifiziert, dass unser Backup auch ein gültiges Format hat und sich wieder einspielen lässt.

Keine Kommentare zu “Cloning mit RMAN ist einfach!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Was kann CarajanDB für Sie tun?