Oracle RMAN 11g Backup and Recovery (98 page)

The restore Command

While the
restore
command has several ancillary purposes, its main function is to restore files from RMAN backups in preparation for recovery. RMAN and the
restore
command are quite intelligent, and they will choose the most recent backup to restore, in an effort to reduce recovery time. As a result, the
restore
command might restore your datafiles from a backup set, or it might restore them from an image copy, or it might choose to do a little of both, if that will help speed up the restore process.

The
restore
command is used to restore SPFILEs and control files from automated backups.

The
restore
command can also be used to create a standby control file for a standby database.

You also use the
restore
command to restore the database to any point in time, and in that case, it will find the closest backups to that given point in time to restore. Without a recovery catalog, RMAN can restore the database to any point in time within that database’s incarnation (assuming that a backup is available). The
restore
command can also be used to restore databases from previous incarnations, but a control file backed up during that incarnation is required. If you are using a recovery catalog, you can restore the database back to any incarnation.

The
restore
command can also be used to restore a specific backup based on a given tag assigned to that backup. This might be useful in development environments where you might have a “golden” backup that you want to restore to on a regular basis. The
restore
command can also be used to restore archived redo logs, if that is required for operations like LogMiner (but the
recover
command will do this during database recoveries).

Want more? The
restore
command can be used to validate the ability to actually recover the database. It will make sure that backups are available to restore the database, and it will validate the integrity of those backups. You can also use the
restore preview
command to identify the backups that will be needed to restore the database (much like the
list
command that we discuss in Chapter 18).

NOTE

The
restore preview
command can be quite handy if you are moving
backup sets from a storage device that RMAN is not aware of. For

example, if you back up to disk with RMAN and then later use an OS

backup to move those files to tape, RMAN will not be aware of this

move. You can use the
restore preview
to determine which files need
to be restored from the OS backup, simplifying the restore process.

When using the
restore
command, if you are using encryption for your backups, you need to ensure that the encryption method in use is properly configured. Thus, if you are using transparent-mode encryption, the required wallet must be available.

When you use the
restore
command, it overwrites any files that already exist without notice, unless you use the
set newname
command (which we document later in this chapter). Because of Chapter 12: RMAN Restore and Recovery
281

this, be very careful when restoring files, and make sure that you don’t mind overwriting what is already out there.

The
restore
command also has a failover feature. If, during a recovery, RMAN finds that a given backup file is not available or is corrupted, it automatically tries to use previous backups to complete the recovery process. In cases where failover happens, RMAN puts a message in the database alert log.

The recover Command

The
recover
command is used to recover the database. It can perform a complete recovery, or it can perform a point-in-time recovery of the database. The
recover
command determines which archived redo logs are required and extracts and applies them. Once the application of the redo is complete, all you need to do is open the database with the
alter database open
command.

The
recover
command also determines if any incremental backup images are available to apply. These images can be applied to base incremental backups or to datafile image copies. The
recover
command always tries to use incremental backups first, if they are available, because that will be the quickest way to restore your database (as opposed to applying archived redo logs).

When restoring the archived redo logs, the
recover
command attempts to use any redo logs that are already present on disk. If they are not available on disk, the
recover
command then tries to restore them from the various archived redo log backup sets. Note that you can use the
noredo
parameter in the
recover
command to indicate that RMAN should not try to apply redo to the database. As you will see in an example later in this chapter, the
noredo
parameter is used for recovery of NOARCHIVELOG databases.

Restore and Recover the Database in

NOARCHIVELOG Mode

If your database is in NOARCHIVELOG mode, you will be recovering from a full, offline backup, and point-in-time recovery won’t be possible. If your database is in ARCHIVELOG mode, read the

“Database Recoveries in ARCHIVELOG Mode” section later in this chapter. If you are doing incremental backups of your NOARCHIVELOG database, then you will also want to read “What If I Use Incremental Backups?” later in this chapter.

Preparing for the Restore

If you are running in NOARCHIVELOG mode, and assuming you actually have a backup of your database, performing a full recovery of your database is very easy. First, it’s a good idea to clean everything out. You don’t have to do this, but we have found that in cases of NOARCHIVELOG

recoveries, cleaning out old datafiles, online redo logs, and control files is a good idea. You don’t want any of those files lying around. Since you are in NOARCHIVELOG mode, you will want to start afresh (of course, it’s also a very good idea to make sure that those files are backed up somewhere just in case you need to get them back!).

Having cleaned out your datafiles, control files, and redo logs, you are ready to start the recovery process. First, recover the control file from your last backup, as we demonstrated earlier in this chapter. Alternatively, you can use a backup control file that you created at some point after the backup you wish to restore from. If you use the
create control file
command, you need to catalog the RMAN backup-related files before you can restore the database.

282
Part II: Setup Principles and Practices

For this example, we assume that you are not using a recovery catalog. We also assume you want to recover from the most current backup, which is the default setting for RMAN. If you want to recover from an older backup, you need to use the
set time
command, which we will discuss later in this section.

The differences in recovery with and without a recovery catalog are pretty much negligible once you are past the recovery of the SPFILE and the control file. So, we will only demonstrate recoveries without a recovery catalog. Also, at this point, there is little difference in how you perform a recovery if you are using the FRA or not. In the upcoming examples, we use the FRA and highlight any issues that arise from this fact in the text.

First, let’s look at the RMAN commands you use to perform this recovery: startup mount;

restore database;

recover database noredo;

alter database open resetlogs;

Looks pretty simple. Of course, these steps assume that you have recovered your SPFILE and your database control files. The first command,
startup mount
, mounts the database. So, Oracle reads the control file in preparation for the database restore. The
restore database
command causes RMAN to actually start the database datafile restores. Following this command,
recover
database noredo
instructs RMAN to perform final recovery operations in preparation for opening the database. Since the database is in NOARCHIVELOG mode, and there are no archived redo logs to apply and the online redo logs are missing, the
noredo
parameter is required. If the online redo logs were intact, the
noredo
parameter would not be needed. Finally, we open the database with the
alter database open resetlogs
command. Since we have restored the control file and we need the online redo logs rebuilt, we need to use the
resetlogs
command. In fact, you will probably use
resetlogs
with about every NOARCHIVELOG recovery you do.

So, let’s look at this recovery in action:

d:>set oracle sid testoem

d:>rman target sys/robert

RMAN> startup mount

connected to target database (not started)

Oracle instance started

database mounted

Total System Global Area 209715200 bytes

Fixed Size 1248164 bytes

Variable Size 100664412 bytes

Database Buffers 104857600 bytes

Redo Buffers 2945024 bytes

RMAN> restore database;

Starting restore at 26-DEC-05

channel ORA DISK 1: starting datafile backupset restore

channel ORA DISK 1: specifying datafile(s) to restore from backup set

restoring datafile 00001 to

C:\ORACLE\DATAFILE\TESTOEM\TESTOEM\SYSTEM01.DBF

restoring datafile 00002 to

C:\ORACLE\DATAFILE\TESTOEM\TESTOEM\UNDOTBS01.DBF

restoring datafile 00003 to

C:\ORACLE\DATAFILE\TESTOEM\TESTOEM\SYSAUX01.DBF

Chapter 12: RMAN Restore and Recovery
283

restoring datafile 00004 to C:\ORACLE\DATAFILE\TESTOEM\TESTOEM\USERS01.DBF

restoring datafile 00005 to

C:\ORACLE\DATAFILE\TESTOEM\TESTOEM\CATALOG01.DBF

channel ORA DISK 1: reading from backup piece

C:\ORACLE\PRODUCT\10.2.0\FLASH RECOVERY AREA\TESTOEM\BACKUPSET

\2005 12 26\O1 MF NNNDF TAG20051226T085336 1V00ZL3Y .BKP