Desaster recovery in a nutshell for Oracle Database 10gR2

The article gives a brief overview how to restore and recover an Oracle database. Of course its a requirement to have a working rman backup of the database. We start at the point where the database is lost and we need to restore it from scratch using the backup files. In this scenario we use a controlfile and not a catalog database. Before you begin you need to make sure that the failed storage is available again and the directories and permissions are created and granted. 




We start the instance without a parameter file:

RMAN> connect target

connected to target database (not started)

RMAN> startup nomount

startup failed: ORA-01078: failure in processing system parameters

LRM-00109: could not open parameter file '/opt/oracle/product/10.2/dbs/initMYDB.ora'

trying to start the Oracle instance without parameter files

Oracle instance started

...

We now have a started instance and restore the spfile and the controlfile. Since Oracle does not know its location we have to provide them on the command line:

RMAN> restore spfile from '/opt/oracle/...‘;

RMAN> restore controlfile from '/opt/oracle...';

We need to restart the instance so that it can use the parameter file and the control file. In this case we can use the force command option. "force" internally uses a shutdown abort followed by startup mount command.

RMAN> startup force mount

Now we have a started instance that is aware of the backup files since the backup file references are stored in the controlfile which we just recovered. We can start the recovery and the restore process using a rman run block:

RMAN>
run{
restore database;
recover database;
}

The recover command applies all archive logs it find in the controlfile. If you have some newer archive logs which are not listed in the controlfile you need to catalog them and start the recovery process again:

catalog backuppiece '/backup/MYSID/01dmsbj4_1_1.bcp';


Then use „recover database“ to apply them. If all archive logs are applied. You need to open the database with the resetlogs option. This creates a new database incarnation. Archive logs of the old and the new incarnation are not compatible. This means no further recovery with the new archive logs and the old backup is possible and newly created archive logs are not compatible with the old backup. For this reason you need to create immediately a new backup of the new incarnation database. Until this backup finishes you have a gap in the backup strategy.


RMAN> alter database open resetlogs