Lesson 6	Restoring files to an alternative location
Objective	Restore files to a different location after media failure.

Restoring Files to an Alternative Location

In an earlier lesson, you learned how to recover a database by restoring backup files after a media failure occurs and is corrected. However, if a media failure cannot be corrected in time and it is necessary to have the database operating, you can restore the backup files to an alternative location in order to make the database accessible.

Restoring files to a different location

Restoring backup files to a different location involves a few simple steps. As you learned earlier in this module, all of the datafiles, control files, and redo log files must be restored, not just the damaged files. This will guarantee that the entire database is synchronized to a single point in time and functions properly. View the code below to see how to restore backup files to a different location.

You may also preview all the steps.

Steps to restore Backup Files to a different location

Shut down the database by issuing the SHUTDOWN ABORT command.
Restore the most recent database backup to a different location.
Edit the parameter file to indicate the new location of the control file.
Start an Oracle instance using the restored backup files and edited parameter file and mount the database by issuing the STARTUP MOUNT PFILE=INITSID.ORA command. Note: do not open the database at this point.
Update the control file with the new file location by issuing the ALTER DATABASE RENAME FILE <FILENAME> TO <FILENAME>; command.
The location for all restored datafiles and online redo log files must be updated in the control file. To check the information about the file location change, use the data dictionary view V$DATAFILE, which shows all datafile information recorded in the control file.
Repeat step 5 until all the necessary file locations are changed.
Open the database by issuing the ALTER DATABASE OPEN; command.

Inconsistent Backups

Any database backup that is not consistent is an inconsistent backup. A backup made when the database is open is inconsistent, as is a backup made after an instance failure or SHUTDOWN ABORT command. When a database is restored from an inconsistent backup, Oracle Database must perform media recovery before the database can be opened, applying any pending changes from the redo logs.
Note: RMAN does not permit you to make inconsistent backups when the database is in NOARCHIVELOG mode. If you employ user-managed backup techniques for a NOARCHIVELOG database, then you must not make inconsistent backups of this database.
If the database runs in ARCHIVELOG mode, and you back up the archived redo logs and datafiles, inconsistent backups can be the foundation for a sound backup and recovery strategy. Inconsistent backups offer superior availability because you do not have to shut down the database to make backups that fully protect the database.

View the code below to see all of the code you would normally see on your screen when you restore files to an alternate location.

SQL>
SQL> SHUTDOWN ABORT
ORACLE instance shut down.
SQL> HOST
Microsoft(R) Windows NT(TM)
(C) Copyright 1985-1996 Microsoft Corp.

C:\>COPY D:\ORCL_BCKUP\*.* D:\ORCL_NEW
D:\ORCL_BCKUP\Ctl1orcl.ora
D:\ORCL_BCKUP\LOG1ORCL.ORA
D:\ORCL_BCKUP\LOG2ORCL.ORA
D:\ORCL_BCKUP\LOG3ORCL.ORA
D:\ORCL_BCKUP\LOG4ORCL.ORA
D:\ORCL_BCKUP\OEM1ORCL.ORA
D:\ORCL_BCKUP\RBS1ORCL.ORA
D:\ORCL_BCKUP\SYS1ORCL.ORA
D:\ORCL_BCKUP\TMP1ORCL.ORA
D:\ORCL_BCKUP\Usr1orcl.ora
       10 file(s) copied.

    
C:\>HOST
SQL> STARTUP MOUNT PFILE=D:\ORANT\DBS\INITORCL.ORA
ORACLE instance started.
Total System Global Area                         15077376 bytes
Fixed Size                                          49152 bytes
Variable Size                                    12906496 bytes
Database Buffers                                  2048000 bytes
Redo Buffers                                        73728 bytes
Database mounted.
SQL> ALTER DATABASE RENAME FILE 
     2> 'C:\ORANT\DATABASE\USR1ORCL.ORA'
     3> TO 'D:\ORCL_NEW\USR1ORCL.ORA';
Statement processed.
SQL> ALTER DATABASE RENAME FILE
     2> 'C:\ORANT\DATABASE\SYS1ORCL.ORA'
     3> TO 'D:\ORCL_NEW\SYS1ORCL.ORA';
Statement processed.
SQL> ALTER DATABASE RENAME FILE
     2> 'C:\ORANT\DATABASE\OEM1ORCL.ORA'
     3> TO 'D:\ORCL_NEW\OEM1ORCL.ORA';
Statement processed.
SQL> ALTER DATABASE RENAME FILE
     2> 'C:\ORANT\DATABASE\LOG4ORCL.ORA'
     3> TO 'D:\ORCL_NEW\LOG4ORCL.ORA';
Statement processed.
SQL> ALTER DATABASE RENAME FILE
     2> 'C:\ORANT\DATABASE\LOG3ORCL.ORA'
     3> TO 'D:\ORCL_NEW\LOG3ORCL.ORA';
Statement processed.
SQL> ALTER DATABASE RENAME FILE
     2> 'C:\ORANT\DATABASE\LOG2ORCL.ORA'
     3> TO 'D:\ORCL_NEW\LOG2ORCL.ORA';
Statement processed.
SQL> ALTER DATABASE RENAME FILE
     2> 'C:\ORANT\DATABASE\LOG1ORCL.ORA'
     3> TO 'D:\ORCL_NEW\LOG1ORCL.ORA';
Statement processed.
SQL> ALTER DATABASE OPEN;
Statement processed.
SQL>

The next lesson concludes this module.

RMAN: Restoring and Recovering Control Files

Because of media failure, we can lose control files as well as datafiles and redo log files. This section will go over different scenarios with control file loss and practical recovery procedures.

Recovering from the Loss of a Control File When a Mirrored Copy is Available

It is always best to have backup copies of the control files. Oracle recommends having at least three copies of the control file at all times. It is recommended to multiplex control files to different physical disks so that if one of them is lost due to media failure, it can be restored from the other physical disks.
Please note that more than three copies can be made, but here, the more the merrier? is not the right thing to do. If multiplexed copies of the control file are going to be made and the database is doing a huge amount of control file updates, it would lead to the Control File Parallel Write wait event and also the Control File Enqueue will come into contention. So it is always better to use just the number of copies needed. If more than the maximum of eight copies of control files are made, the following error will occur:

ORA-00208: number of control file names exceeds limit of 8

If there is just one lost copy of the mirrored files, there is much less to do. See what happens in the following scenarios with our resident DBA, Bob:
1st Scenario
Due to media failure, Bob lost one of the control files of the database and got the following error:

ERROR at line 1:
 ORA-00210: cannot open the specified control file
 ORA-00202: control file: '/u02/oradata/db1/control01.ctl'
 ORA-27041: unable to open file
 Linux Error: 2: No such file or directory
 Additional information: 3

As Glenn has multiplexed controlfiles on the different hard drives, he performs the following actions:

Shuts down the database (in abort mode)
Copies available control file to the directory where the file was lost and renames it
Starts the database

Here are the steps in detail to recover the database:
If the database is already up, bring it down immediately without invoking the checkpoint.

SQL> shut abort;