RESTORE-TEST

04.
Dezember
2020
Veröffentlicht von: Kurt Sauer

Ein Kunde führt regelmäßig einen Datenbank-Backup mit dem Recovery Manager (RMAN) durch, möchte aber gerne von Zeit zu Zeit wissen, inwieweit seine Datenbank recovery-fähig ist. Leider hat der Kunde kein Testsystem zur Verfügung und auf eine reine Simulation des Restores mit RMAN möchte er sich nicht verlassen. Es muss der Restore-Test auf dem Produktionssystem durchgeführt werden, aber natürlich darf der Produktionsbetrieb nicht beeinträchtigt oder gar die Datenbank überschrieben werden. Erschwerend kommt hinzu, dass es sich um einen Oracle Real Application Clusters (RAC) mit dem Automatic Storage Management (ASM) als Speicherverwaltungs-System handelt.

Da der Recovery-Test möglichst realitätsnah durchgeführt werden soll, wünscht der Kunde auch keine Durchführung mit dem RMAN “Duplicate“-Kommando. Der vorliegende Monatstipp beschreibt im Detail die Vorgehensweise, um mit Hilfe des RMANs eine Kopie der Produktionsdatenbank auf dem gleichen Server-System zu erstellen. Die Vorgehensweise ist identisch mit den im Memory-Skript des RMAN “Duplicate“ ablaufenden Kommandos.

 

BESCHREIBUNG

Die produktive Datenbank lautet in unserem Beispiel “rac19db“, die zu erstellende Kopie “restdb“. Der Speicherplatz in der ASM Diskgruppe hat noch entsprechend Kapazität, um die Datenbankkopie aufzunehmen.
 

1) Parameterdatei (init.ora) für Kopie erstellen

Auf Knoten 1 des RAC-Systems folgendes ausführen:

SQL> create pfile='/home/oracle/initrestdb.ora' from memory;


Als Erstes müssen innerhalb der init.ora Datei alle Referenzen von “rac19db“ auf “restdb“ geändert werden.
Zusätzlich müssen noch folgende Parameter geändert werden:

(..)
*.cluster_database=false
*.instance_number=0
(..)


Die init.ora beinhaltet dann folgende, die neue Kopie betreffenden Inhalte:

(..)
*.audit_file_dest='/u01/app/oracle/admin/restdb/adump'
*.cluster_database=false
*.control_files='+FRA/RESTDB/CONTROLFILE/current.269.1041616821'
*.control_files='+DATA/RESTDB/CONTROLFILE/current.270.1041616821'
*.core_dump_dest='/u01/app/oracle/diag/rdbms/restdb/restdb1/cdump'
*.db_create_file_dest='+DATA'
*.db_create_online_log_dest_1='+FRA'
*.db_create_online_log_dest_2='+DATA'
*.db_domain='muniqsoft.de'
*.db_name='restdb'
*.db_unique_name='restdb'
*.instance_number=0
*.local_listener=' (ADDRESS=(PROTOCOL=TCP)(HOST=10.10.58.11)(PORT=1521))'
*.thread=1
*.undo_tablespace='UNDOTBS1'
(..)

Evtl. sollten auch noch die Memory-Werte deutlich reduziert werden, damit das produktive System durch den Recovery-Test nicht über Gebühr belastet wird.


2) Verzeichnisse anlegen

Folgende Verzeichnisse für adump und diag (hier beispielhaft) müssen angelegt werden:

[oracle@tl19kusa01:~]>mkdir -p /u01/app/oracle/admin/restdb/adump
[oracle@tl19kusa01:~]>mkdir -p /u01/app/oracle/diag/rdbms/restdb


3) “restdb“-Instanz starten

Nun wird versucht, die neue Instanz mit der angepassten init.ora zu starten:

[oracle@tl19kusa01:~]>export ORACLE_SID=restdb
SQL> startup nomount pfile='/home/oracle/initrestdb.ora'


4) Controlfile restoren und Datenbank „restdb“ mounten

Nach erfolgreichem Start der Instanz wird versucht, die Controlfiles der produktiven Datenbank in den ASM-Verzeichnispfad der Kopie-Datenbank zu restoren.
Den Namen des Controlfiles bekommt man z. B. über das asmcmd-Kommando:

[grid@tl19kusa01:~]>asmcmd ls +fra/RAC19DB/AUTOBACKUP/2020_05_28

RMAN> restore controlfile from '+fra/RAC19DB/AUTOBACKUP/2020_05_28/s_1041614743.267.1041614745';
Starting restore at 28-MAY-20
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=263 device type=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
output file name=+FRA/RESTDB/CONTROLFILE/current.269.1041616821
output file name=+DATA/RESTDB/CONTROLFILE/current.270.1041616821
Finished restore at 28-MAY-20

Nach erfolgreichem Restore der Controlfiles wird versucht, die Controlfiles zu mounten:
RMAN> alter database mount;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of sql statement command at 05/28/2020 17:52:41
ORA-01103: database name 'RAC19DB' in control file is not 'RESTDB'

An dieser Stelle erkennt Oracle, dass die Controlfiles zu einer anderen Datenbank gehören. Um das zu umgehen, muss folgender Parameter in der init.ora geändert werden:

Editieren intrestdb.ora

(..)
*.db_name=rac19db
(..)


Der Parameter “db_unique_name“ muss weiterhin auf folgendem Wert stehen:

(..)
db_unique_name=‘restdb‘
(..)


Anschließend muss die Datenbank-Instanz nochmals gestartet werden

SQL> startup force nomount pfile='/home/oracle/initrestdb.ora'


Das Controlfile-Backup von vorher nochmals restoren:

RMAN> restore controlfile from '+fra/RAC19DB/AUTOBACKUP/2020_05_28/s_1041614743.267.1041614745';
RMAN> alter database mount;
Statement processed

Jetzt konnten die Controlfiles erfolgreich gemountet werden.


5) Datenbank-Restore durchführen

In den nächsten Schritten kann die Funktionalität des RMAN-Backups getestet werden.

Achtung: Den Befehl „set newname“ auf alle Fälle ausführen, sonst werden möglicherweise die Datenbankdateien der Produktivdatenbank überschrieben. Mit der Angabe %U können innerhalb ASM generische Dateinamen erzeugt werden. Eine Umbenennung jeder einzelnen Datenbankdatei ist nicht erforderlich.

RMAN> run
2> {
3> set NEWNAME FOR DATABASE TO '+data/restdb/datafile/%U';
4> restore database;
5> switch datafile all;
6> }


6) Datenbank-Recovery durchführen

Nach erfolgreichem Restore kann der Recovery durchgeführt werden:

RMAN> recover database;
Starting recover at 29-MAY-20
using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 164 is already on disk as file +FRA/RAC19DB/ARCHIVELOG/2020_05_28/thread_1_seq_164.265.1041614743
archived log for thread 1 with sequence 165 is already on disk as file +DATA/RAC19DB/ONLINELOG/group_1.258.1032010933
archived log file name=+FRA/RAC19DB/ARCHIVELOG/2020_05_28/thread_1_seq_164.265.1041614743 thread=1 sequence=164
archived log file name=+DATA/RAC19DB/ONLINELOG/group_1.258.1032010933 thread=1 sequence=165
media recovery complete, elapsed time: 00:00:01
Finished recover at 29-MAY-20

Achtung: Nach dem Recovery kein “open resetlogs“ ausführen, da sonst die Logfiles im Originalverzeichnis der Produktivdatenbank angelegt werden


7) Datenbank Redolog-Dateien mit Skript anlegen

Hierzu folgenden Befehl absetzen:

SQL> alter database backup controlfile to trace as ‘/home/oracle/cre_CF.sql‘;
Das Trace-File cre_CF.sql editieren:
STARTUP NOMOUNT pfile='/home/oracle/initrestdb.ora'
CREATE CONTROLFILE set DATABASE "RESTDB" RESETLOGS  noARCHIVELOG
    MAXLOGFILES 192
    MAXLOGMEMBERS 3
    MAXDATAFILES 1024
    MAXINSTANCES 32
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 (
    '+FRA',
    '+DATA'
  ) SIZE 200M BLOCKSIZE 512,
  GROUP 2 (
    '+FRA',
    '+DATA'
  ) SIZE 200M BLOCKSIZE 512
DATAFILE
  '+DATA/restdb/datafile/data_d-rac19db_ts-system_fno-1',
  '+DATA/restdb/datafile/data_d-rac19db_ts-sysaux_fno-2',
  '+DATA/restdb/datafile/data_d-rac19db_ts-undotbs1_fno-3',
  '+DATA/restdb/datafile/data_d-rac19db_ts-undotbs2_fno-4',
  '+DATA/restdb/datafile/data_d-rac19db_ts-users_fno-5'
CHARACTER SET AL32UTF8;
ALTER DATABASE OPEN RESETLOGS;
ALTER TABLESPACE TEMP ADD TEMPFILE '+DATA' size 200M autoextend on next 100M maxsize 1G;

Achtung: Die Logfile-Gruppen, die der zweiten Instanz bei der Produktionsdatenbank angehören, herausnehmen. Zu ermitteln mit:

SQL> select group#,thread#  from v$log where thread# > 1;


8) Skript ausführen

Die Instanz stoppen und das Skript ausführen

SQL> shutdown immediate


Das editierte Skript nun ausführen:

SQL> @/home/oracle/cre_CF.sql
CREATE CONTROLFILE set DATABASE "RESTDB" RESETLOGS  noARCHIVELOG
*
ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-00200: control file could not be created
ORA-00202: control file: '+DATA/restdb/controlfile/current.269.1041616291'
ORA-17502: ksfdcre:4 Failed to create file
+DATA/restdb/controlfile/current.269.1041616291
ORA-15046: ASM file name '+DATA/restdb/controlfile/current.269.1041616291' is
not in single-file creation form

Die Fehlermeldung besagt, dass das Controlfile mit dem Namen in der init.ora nicht angelegt werden kann, da ASM die OMF-Nomenklatur verwendet, bei dem der hintere Teil des Namens als sogenannte Incarnation definiert wird.

Dazu muss die init.ora der “restdb“ geändert werden:

init.ora
(..)
#*.control_files='+DATA/restdb/controlfile/current.269.1041616291'
*.control_files='+DATA'
(..)


Die Instanz stoppen und das Skript nochmals ausführen

SQL> shutdown immediate
SQL> @/home/oracle/cre_CF.sql
Control file created.
Database altered.
Tablespace altered.


9) Datenbank nochmals durchstarten

Im letzten Schritt wird die erstellte Kopie der Produktionsfatenbank nochmals neugestartet.
Vor dem Neustart muss der Name des Controlfiles ermittelt und in der init.ora angepasst werden:

SQL> select name from v$controlfile;
+DATA/restdb/controlfile/Current.278.1047135271


Eintrag in init.ora

(..)
*.control_files='+DATA/restdb/controlfile/Current.278.1047135271 ‘
(..)


Jetzt kann die Datenbank gestoppt und fehlerfrei gestartet werden:

SQL> shutdown immediate
SQL> startup
Database opened.


Ein Überblick über die Datenbank-Files in ASM:

Kontrolldateien:

+DATA/restdb/controlfile/Current.278.1047135271


Daten-/Tempdateien:

+DATA/restdb/datafile/data_d-rac19db_ts-system_fno-1
+DATA/restdb/datafile/data_d-rac19db_ts-sysaux_fno-2
+DATA/restdb/datafile/data_d-rac19db_ts-undotbs1_fno-3
+DATA/restdb/datafile/data_d-rac19db_ts-undotbs2_fno-4
+DATA/restdb/datafile/data_d-rac19db_ts-users_fno-5
+DATA/restdb/tempfile/TEMP.285.1047135957


Redolog-Dateien:

+DATA/restdb/onlinelog/group_1.283.1047135941
+DATA/restdb/onlinelog group_2.284.1047135941
+FRA/restdb/onlinelog/group_1.275.1047135925
+FRA/restdb/onlinelog/group_2.282.1047135931


FAZIT

Mit diesen Schritten ist der Nachweis erbracht, dass die Datenbank im Worst-Case zurückgesichert werden kann. Da die Erstellung einer Kopie öfters durchgeführt werden soll, wird auf eine weitere Integration der Kopie im RAC verzichtet. Die durchzuführenden Schritte erfordern einige Konzentration und sollten auf keinen Fall auf die „Schnelle“ durchgeführt werden. Besser ist es auf alle Fälle, über ein Testsystem nachzudenken, auf dem ohne Gefahr für das Produktions-System ein Restore erfolgen kann.

Jede Menge Know-how für Sie!

In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.