In this blog the restore of an Oracle database is described. The database was, before it got lost, daily backed up to an NFS mounted storage device. Next to that, every 10 minutes backups of the archived log files were created.
Starting point:
- Clean installed VM, no database running
- File systems created and sized to needed size
- No DB, no spfiles etc. found on the system
Steps:
- Set ORACLE_SID
- Mount NetApp storage for this database under /mnt/backup/$ORACLE_SID
- Find newest backup file that contains the spfile and restore it
$ rman target /
( do not connect to the recovery catalog, as it will not find this forcefully
started instance)
RMAN> startup nomount force;
SQL> select db_id from db where reg_db_unique_name='DBAPRDC';
- Return to RMAN and execute the following statements:
RMAN>
set DBID=<ID from query>;
RMAN> restore spfile from ‘<file found in ls -lrt command>';
-
Shutdown
the database and restart it in nomount
using the restored spfile and then connect to the RMAN catalog:
RMAN> shutdown immediate;
RMAN> startup nomount;
Quit RMAN and restart using the recovery catalog;
rman target / rcvcat /@tsmora
- Restore the controlfiles from the same backup file that held the spfile:
RMAN> restore controlfile from ‘<file found in ls -lrt command>’;
The control files are automatically
restored to the correct location.
- Restore and recover database
Now it is time to restore and recover the
database.
Since we assume that we don’t have anything but the backup of the database, a
full recovery is not possible as we are missing the latest redo information
from the online redo files. We do have to recovery with the amount of redo we
have from archived log backups:
RMAN> alter database mount;
RMAN> restore
database;
RMAN> recover
database until available redo;
Depending on the database size, this may take a while.
- Open the database using RESETLOGS, to let the new redo-log file being created:
RMAN> alter database open resetlogs;
That completes the restore of the database.
Remember that the last couple minutes between the latest archivelog backup and
the point in time where database got lost are gone. Data inconsistencies may therefore
exist.