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.
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.
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
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'
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.
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> }
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
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;
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.
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
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.
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.