Backup and Recovery - Expert Consolidation in Oracle Database 12c - page 402

■ one of the reasons to modify initialization parameters is media failure and the loss of a mount point. you can
read more about this scenario in the next section.

Note

The process for restoring the control file is very similar to the restoring of the server parameter file, the main
difference being the command: instead of using “restore spfile from autobackup” you use “restore controlfile from
autobackup”. But before you start the restore process you should check if you do not have a multiplexed copy of the
controlfile. The following query can help you find the other copy of the controlfile:

SYS@CDB$ROOT> select value from v$parameter where name = 'control_files';

Be careful not to copy the bad controlfile over the good one! If you are in a situation where the controlfile was not
multiplexed you have to restore.
The example shown here assumes that all control files have been lost. Shut the database down if that has not yet
happened to remedy the situation, and start it in nomount mode. If you are not using a catalog database, you may
have to set the dbid and start into the nomount state, followed by the restore controlfile from autobackup command.
Users with a recovery catalog are luckier, the command sequence to restore the controlfile is shown here, with
some of the RMAN output removed for clarity:

RMAN> startup nomount
[...]
RMAN> restore controlfile;

Starting restore at 22.09.2013 21:05
[...]
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: reading from backup piece 
+RECO/CDB1/AUTOBACKUP/2013_09_22/s_826832795.297.826832795
channel ORA_DISK_1: piece handle=+RECO/CDB1/AUTOBACKUP/2013_09_22/s_826832795.297.826832795 
tag=TAG20130922T194635
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
output file name=+DATA/CDB1/CONTROLFILE/current.262.826623553
Finished restore at 22.09.2013 21:

The next steps are identical for both users without and with a recovery catalog database. You need to mount the
database and recover it before opening it with the resetlogs option.

Restoring databases
Restoring database files is nothing to be afraid of, even though many production database administrators will likely
get a little bit nervous when they are tasked with partial or full restore operations. This is completely understandable,
especially if one is not all too familiar with the database having a problem. There are two complementary strategies for
how to make the database administrator more comfortable with the restore/recovery situation. The first is to ensure
that the procedures to be taken are well documented and more importantly: understood. The second option to be
taken by management is to perform restore and recover exercises throughout the year and on a regular schedule. You
can read a little more about this thought later in the chapter.
The following sections explain the general process of restoring database files for Container Databases and
Pluggable Databases.