Wir kennen es wahrscheinlich alle und hoffen, dass es nie passieren wird: der Disasterfall - der Datenträger mit den Datendateien der Datenbank geht unwideruflich verloren.
In diesem Beispiel handelt es sich um eine Oracle Datenbank 11.2 in einem 2 Knoten Real Application Cluster 11.2 unter der Verwendung von ASM. Die Oracle Datenbank benutzt zwei Diskgroups, FRA und DATA.
Auf der DATA Diskgroup befinden sich die Datendateien, das SPFile, ein Control-File und jeweils das erste Member der Redolog-Gruppen.
Auf der FRA Diskgroup befindet sich die FRA der Datenbank (und somit alle Backups und Archivelogs), ein zweites Control-File und die zweiten Member der Redolog-Gruppen.
Desweitern ist ein regelmäßiges Full- und Archivelog Backup mit aktivem Autobackup eingerichtet. (Ohne vollständig funktionierendes Backup ist es nicht möglich, diesen Disasterfall heil zu überstehen).
Die Diskgroup DATA fällt aus (inklusive aller Redundancen auf ASM und/oder SAN Ebene) und ist unwiderruflich verloren.
Als erstes müssen Sie neue Datenspeicher für die DATA Diskgroup zur Verfügung stellen. Diese müssen Sie dann mit dem Befehl oracleasm createdisk ASM_DISK1 /dev/sdc1 für ASM bereitstellen. In diesem Monatstipp sind dies die Partitionen /dev/sdc1, /dev/sdd1, /dev/sdh1 und /dev/sdi1. Vorher prüfen, ob nicht bereits die Disks als ASM-Disks markiert wurden: oracleasm querydisk /dev/sdc1
[root@s-sl-rac10a ~]# oracleasm createdisk ASM_DISK1 /dev/sdc1
Writing disk header: done
Instantiating disk: done
[root@s-sl-rac10a ~]# oracleasm createdisk ASM_DISK2 /dev/sdd1
Writing disk header: done
Instantiating disk: done
[root@s-sl-rac10a ~]# oracleasm createdisk ASM_DISK5 /dev/sdh1
Writing disk header: done
Instantiating disk: done
[root@s-sl-rac10a ~]# oracleasm createdisk ASM_DISK6 /dev/sdi1
Writing disk header: done
Instantiating disk: done
Danach sollten Sie auf dem zweiten Knoten noch den Befehl oracleasm scandisks absetzen, damit dieser Knoten die ASM Disks "bemerkt".
[root@s-sl-rac10b ~]# oracleasm scandisks
Reloading disk partitions: done
Cleaning any stale ASM disks...
Scanning system for ASM disks...
Instantiating disk "ASM_DISK1"
Instantiating disk "ASM_DISK2"
Instantiating disk "ASM_DISK5"
Instantiating disk "ASM_DISK6"
Zur Kontrolle kann auf beiden Knoten oracleasm listdisks ausgeführt werden.
Im Anschluss legen wir über SQL*Plus die Diskgroup 'DATA' wieder an.
Wenn möglich, Informationen zur Diskgroup (Grösse, FG, Kompatibilität) aus dem regelmäßigem Backup der ASM-Metadaten holen (mit asmcmd md_backup) oder aus dem alert.log.
SYS@+ASM1> CREATE DISKGROUP DATA NORMAL REDUNDANCY
FAILGROUP FG1_DATA DISK
'ORCL:ASM_DISK1',
'ORCL:ASM_DISK5'
FAILGROUP FG2_DATA DISK
'ORCL:ASM_DISK2',
'ORCL:ASM_DISK6'
ATTRIBUTE
'compatible.asm' = '11.2',
'compatible.rdbms' = '11.2';
Diskgroup created.
Da die DATA Diskgroup wieder vorhanden ist, können wir zum nächsten Schritt übergehen und die entsprechende Dateien, die für die Datenbank nötig sind, restoren und recovern.
Als erstes muss das SPfile der Datenbank restored werden, damit die Datenbank wenigstens im Nomount-Modus gestartet werden kann. Dazu muss man sich per RMAN connecten und eine "DUMMY" Instanz starten, sonst funktioniert RMAN nicht.
[oracle@s-sl-rac10a:~]>rman target /
Recovery Manager: Release 11.2.0.2.0 - Production on Fri Aug 10 18:23:00 2012
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database (not started)
RMAN> startup nomount
startup failed: ORA-01078: failure in processing system parameters
ORA-01565: error in identifying file '+DATA/racdb/spfileracdb.ora'
ORA-17503: ksfdopn:2 Failed to open file +DATA/racdb/spfileracdb.ora
ORA-15056: additional error message
ORA-17503: ksfdopn:2 Failed to open file +DATA/racdb/spfileracdb.ora
ORA-15173: entry 'racdb' does not exist in directory '/'
ORA-06512: at line 4
starting Oracle instance without parameter file for retrieval of spfile
Oracle instance started
Total System Global Area 158662656 bytes
Fixed Size 2224584 bytes
Variable Size 104861240 bytes
Database Buffers 46137344 bytes
Redo Buffers 5439488 bytes
Danach muss das SPfile aus dem Autobackup wiederhergestellt werden.
RMAN> restore spfile from autobackup db_recovery_file_dest='+FRA'
db_name='racdb';
Starting restore at 10.08.2012 18:33:58
using channel ORA_DISK_1
recovery area destination: +FRA
database name (or database unique name) used for search: RACDB
channel ORA_DISK_1: AUTOBACKUP +fra/RACDB/AUTOBACKUP/2012_08_10/s_790966236.318.790966239 found in the recovery area
AUTOBACKUP search with format "%F" not attempted because DBID was not set
channel ORA_DISK_1: restoring spfile from AUTOBACKUP +fra/RACDB/AUTOBACKUP/2012_08_10/s_790966236.318.790966239
channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete
Finished restore at 10.08.2012 18:34:00
Nun können wir die Instanz herunterfahren und wieder normal in den nomount Modus starten und die weiteren Dateien wiederherstellen.
RMAN> shutdown immediate
Oracle instance shut down
RMAN> startup nomount
connected to target database (not started)
Oracle instance started
Total System Global Area 1043886080 bytes
Fixed Size 2233088 bytes
Variable Size 763366656 bytes
Database Buffers 272629760 bytes
Redo Buffers 5656576 bytes
Bevor wir uns um die eigentlichen Datendateien der Datenbank kümmern, stellen wir erstmal das fehlende Control-File, in Diskgroup DATA, wieder her. In unserem Fall einfach das noch vorhandene Control-File "kopieren".
RMAN> restore controlfile to '+DATA' from '+FRA/RACDB/CONTROLFILE/Current.256.788964485';
Starting restore at 10.08.2012 18:55:15
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=142 instance=racdb1 device type=DISK
channel ORA_DISK_1: copied control file copy
Finished restore at 10.08.2012 18:55:19
Nachdem das Control-File per OMF benannt wurde, muss man sich den Namen des neuen Control-Files für die entsprechenden Änderungen am control_file Parameter im SPFile notieren.
SYS@racdb1> ALTER SYSTEM SET control_files='+DATA/racdb/controlfile/current.257.790973717', '+FRA/racdb/controlfile/current.256.788964485' SCOPE=SPFILE;
System altered.
Danach kann man die Instanz herunterfahren und bis in die Mount-Phase wieder starten.
SYS@racdb1> shutdown immediate
ORA-01507: database not mounted
ORACLE instance shut down.
SYS@racdb1> startup mount
ORACLE instance started.
Total System Global Area 1043886080 bytes
Fixed Size 2233088 bytes
Variable Size 763366656 bytes
Database Buffers 272629760 bytes
Redo Buffers 5656576 bytes
Database mounted.
SYS@racdb1>
Im Anschluss können jetzt im RMAN die eigentlichen Datendateien wiederhergestellt ...
RMAN> restore database;
Starting restore at 10.08.2012 19:02:24
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=17 instance=racdb1 device type=DISK
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 +DATA/racdb/datafile/system.259.790962489
channel ORA_DISK_1: restoring datafile 00002 to +DATA/racdb/datafile/sysaux.258.790962487
channel ORA_DISK_1: restoring datafile 00003 to +DATA/racdb/datafile/undotbs1.260.790962491
channel ORA_DISK_1: restoring datafile 00004 to +DATA/racdb/datafile/undotbs2.261.790962491
channel ORA_DISK_1: restoring datafile 00005 to +DATA/racdb/datafile/users.262.790962493
channel ORA_DISK_1: reading from backup piece +FRA/racdb/backupset/2012_08_10/nnndf0_tag20120810t164721_0.330.790966043
channel ORA_DISK_1: piece handle=+FRA/racdb/backupset/2012_08_10/nnndf0_tag20120810t164721_0.330.790966043 tag=TAG20120810T164721
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:01:46
Finished restore at 10.08.2012 19:04:12
... und recovered werden.
RMAN> recover database;
Starting recover at 10.08.2012 19:04:26
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 10 is already on disk as file +FRA/racdb/archivelog/2012_08_10/thread_1_seq_10.282.790966107
archived log for thread 1 with sequence 11 is already on disk as file +FRA/racdb/archivelog/2012_08_10/thread_1_seq_11.303.790966211
archived log for thread 1 with sequence 12 is already on disk as file +FRA/racdb/archivelog/2012_08_10/thread_1_seq_12.272.790966215
archived log for thread 1 with sequence 13 is already on disk as file +FRA/racdb/archivelog/2012_08_10/thread_1_seq_13.302.790966215
archived log for thread 1 with sequence 14 is already on disk as file +FRA/racdb/archivelog/2012_08_10/thread_1_seq_14.281.790966233
archived log file name=+FRA/racdb/archivelog/2012_08_10/thread_1_seq_10.282.790966107 thread=1 sequence=10
archived log file name=+FRA/racdb/archivelog/2012_08_10/thread_1_seq_11.303.790966211 thread=1 sequence=11
archived log file name=+FRA/racdb/archivelog/2012_08_10/thread_1_seq_12.272.790966215 thread=1 sequence=12
archived log file name=+FRA/racdb/archivelog/2012_08_10/thread_1_seq_13.302.790966215 thread=1 sequence=13
media recovery complete, elapsed time: 00:00:02
Finished recover at 10.08.2012 19:04:33
Wenn alle Archivelogs und Redologs vorhanden und für RMAN zu finden waren, sollte sich die Datenbank mit einem einfach alter database open; in SQL*Plus öffnen lassen.
SQL*Plus: Release 11.2.0.2.0 Production on Fri Aug 10 19:04:49 2012
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters and Automatic Storage Management options
SYS@racdb1> alter database open;
Database altered.
Weitere wertvolle Tipps und Informationen erhalten Sie in unseren Backup & Recovery- und RAC-Schulungen. Auch unser Consulting Team hilft Ihnen gerne persönlich weiter.
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.