When you enable the autobackup of your control file and are using an FRA, restoring your control file is fairly simple.

First, connect to your target database and then issue a STARTUP NOMOUNT command, followed by the RESTORE CONTROLFILE FROM AUTOBACKUP command, like this:

$ rman target /

RMAN> startup nomount;

RMAN> restore controlfile from autobackup;

RMAN restores the control files to the location defined by your CONTROL_FILES initialization parameter. You should see a message indicating that your control files have been successfully copied back from an RMAN backup piece. Here is a snippet of the output:

channel ORA_DISK_1: control file restore from AUTOBACKUP complete

You can now alter your database into mount mode and perform any additional restore-and-recovery commands required for your database. Practicing this example would be to move your control files off to another directory in a TEST environment and walk through the restore options. Copying off the files allows you to quickly get back up and running by moving them back, but it does give you practice with these restores.

Specifying a Backup Filename

When restoring a database to a different server, these are generally the first few steps in the process: take a backup of the target database, copy to the remote server, and then restore the control file from the RMAN backup. In these scenarios, the name of the backup piece is known that contains the control file. Here is an example in which you instruct RMAN to restore a control file from a specific backup piece file:

RMAN> startup nomount;

RMAN> restore controlfile from ‘/u01/db23c/rman/rman_ctl_c-3423216220-20130113-01.bk’; The control file will be restored to the location defined by the CONTROL_FILES initialization parameter.

Restoring the Spfile

You might want to restore a spfile for several different reasons:

•     You accidentally set a value in the spfile that keeps your instance from starting.

•     You accidentally deleted the spfile.

•     You are required to see what the spfile looked like at some point in time in the past.

One scenario (this has happened to me more than once) is that you are using an spfile, and one of the DBAs on your team does something inexplicable, such as this:

SQL> alter system set processes=1000000 scope=spfile;

The parameter is changed in the spfile on disk, but not in memory. Sometime later, the database is stopped for some maintenance. When attempting to start the database, you cannot even get the instance to start in a nomount state. This is because a parameter has been set to a ridiculous value that will consume all the memory on the box. In this scenario, the instance may hang, or you may see one or more of the following messages:

ORA-01078: failure in processing system parameters ORA-00838: Specified value of … is too small

If you have an RMAN backup available that has a copy of the spfile as it was before it was modified, you can simply restore the spfile. If you are using a recovery catalog, here is the procedure for restoring the spfile:

$ rman target / catalog rcat/Pa$$word1@rcat RMAN> startup nomount;

RMAN> restore spfile;

•     If you are not using a recovery catalog, there are a number of ways to restore your spfile. The approach you take depends on several variables, such as whether you are using an FRA.

•     You have configured a channel backup location for the autobackup.

•     You are using the default location for autobackups.

This is a general overview of these scenarios to show steps that need to be taken, but not every detail is listed here. Determine the location of the backup piece that contains the backup of the spfile and do the restore, like this:

RMAN> startup nomount force;

RMAN> restore spfile to ‘/tmp/spfile.ora’

from ‘/u01/db23C/rman/rman_ctl_c-3423216220-20130113-00.bk’;

You should see a message such as this:

channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete

In this example, the spfile is restored to the /tmp directory. Once restored, you can copy the spfile to ORACLE_HOME/dbs, with the proper name. For my environment (database name: db23c), this would be as follows:

$ cp /tmp/spfile.ora $ORACLE_HOME/dbs/spfiledb23c.ora

It is also possible to create a new spfile from a parameter file, called init.ora. I like to schedule regular copies of the spfile to an init.ora file.