Oracle RMAN 11g Backup and Recovery (100 page)

If your online redo logs had not been removed, you would have used

the
recover database
command instead of
recover database noredo
.

Database Recoveries in ARCHIVELOG Mode

Typically, you will find production databases in ARCHIVELOG mode because of one or more requirements, such as the following:

■ Point-in-time recovery

■ Minimal recovery time service-level agreements (SLAs) with customers

■ The ability to do online database backups

■ The ability to recover specific datafiles while the database is available to users When the database is in ARCHIVELOG mode, you have a number of recovery options that you can choose from:

■ Full database recovery

■ Tablespace recoveries

■ Datafile recoveries

■ Incomplete database recovery

■ Online block media recovery

We cover the first three items in this section. Later in this chapter, we look at incomplete database recoveries. In Chapter 15, we will look at online block media recovery in more detail.

With each of these types of recoveries, you will find that the biggest difference compared with NOARCHIVELOG mode recovery is the application of the archived redo logs, as well as some issues with regard to defining when you wish to recover to if you are doing incomplete recovery.

For now, let’s start by looking at a full database recovery in ARCHIVELOG mode.

NOTE

Recoveries of SPFILEs and control files are the same regardless of

whether you are running in ARCHIVELOG mode.

Point-of-Failure Database Recoveries

With a point-of-failure database recovery (also known as a full database recovery), you hope that you have your online redo logs intact; in fact, any unarchived online redo log must be intact. If you lose your online redo logs, you are looking at an incomplete recovery of your database.

Reference Chapter 15 for more information on incomplete recoveries. Finally, we are going to assume that at least one control file is intact. If no control file is intact, you need to recover a control file backup, and again you are looking at an incomplete recovery (unless your online redo logs are intact).

288
Part II: Setup Principles and Practices

In this first example, we have lost all of our database datafiles. Our online redo logs and control files are safe, and we just want our database back. In this case, we opt for a full recovery of our database to the point of the failure. Here is the command set we use to perform this restore operation:

shutdown;

startup mount;

restore database;

recover database;

alter database open;

And here is an actual restore operation:

RMAN> restore database;

Starting restore at 09-JAN-06

using target database control file instead of recovery catalog

allocated channel: ORA DISK 1

channel ORA DISK 1: sid 156 devtype DISK

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

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

restoring datafile 00005 to

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

restoring datafile 00009 to C:\ORACLE\TESTDBF\TABLESPACE NOASSM 01.DBF

restoring datafile 00010 to C:\ORACLE\TESTDBF\TABLESPACE YESASSM 01.DBF

channel ORA DISK 1: reading from backup piece

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

\BACKUPSET\2006 01 08\O1 MF NNNDF TAG20060108T224324 1W3THND6 .BKP

channel ORA DISK 1: restored backup piece 1

piece handle C:\ORACLE\PRODUCT\10.2.0\FLASH RECOVERY AREA\TESTOEM

\BACKUPSET\2006 01 08\O1 MF NNNDF TAG20060108T224324 1W3THND6 .BKP

tag TAG20060108T224324

channel ORA DISK 1: restore complete, elapsed time: 00:07:46

channel ORA DISK 1: starting datafile backupset restore

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

restoring datafile 00006 to C:\ORACLE\TESTDBF\TABLESPACE 2K.DBF

channel ORA DISK 1: reading from backup piece

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

\BACKUPSET\2006 01 08\O1 MF NNNDF TAG20060108T224324 1W3TTCT2 .BKP

channel ORA DISK 1: restored backup piece 1

piece handle C:\ORACLE\PRODUCT\10.2.0\FLASH RECOVERY AREA\TESTOEM\

BACKUPSET\2006 01 08\O1 MF NNNDF TAG20060108T224324 1W3TTCT2 .BKP

Chapter 12: RMAN Restore and Recovery
289

tag TAG20060108T224324

channel ORA DISK 1: restore complete, elapsed time: 00:00:07

channel ORA DISK 1: starting datafile backupset restore

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

restoring datafile 00007 to C:\ORACLE\TESTDBF\TABLESPACE 4K.DBF

channel ORA DISK 1: reading from backup piece

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

\BACKUPSET\2006 01 08\O1 MF NNNDF TAG20060108T224324 1W3TTNWO .BKP

channel ORA DISK 1: restored backup piece 1

piece handle C:\ORACLE\PRODUCT\10.2.0\FLASH RECOVERY AREA\TESTOEM

\BACKUPSET\2006 01 08\O1 MF NNNDF TAG20060108T224324 1W3TTNWO .BKP

tag TAG20060108T224324

channel ORA DISK 1: restore complete, elapsed time: 00:00:03

channel ORA DISK 1: starting datafile backupset restore

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

restoring datafile 00008 to C:\ORACLE\TESTDBF\TABLESPACE 16K.DBF

channel ORA DISK 1: reading from backup piece

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

\BACKUPSET\2006 01 08\O1 MF NNNDF TAG20060108T224324 1W3TTYJM .BKP

channel ORA DISK 1: restored backup piece 1

piece handle C:\ORACLE\PRODUCT\10.2.0\FLASH RECOVERY AREA\TESTOEM

\BACKUPSET\2006 01 08\O1 MF NNNDF TAG20060108T224324 1W3TTYJM .BKP

tag TAG20060108T224324

channel ORA DISK 1: restore complete, elapsed time: 00:00:03

Finished restore at 09-JAN-06

RMAN> recover database;

Starting recover at 09-JAN-06

using channel ORA DISK 1

starting media recovery

media recovery complete, elapsed time: 00:00:12

Finished recover at 09-JAN-06

RMAN> alter database open;

database opened

Looks pretty easy, and it is. However, there are a few things to realize about restore operations like this. First, Oracle touts that if the file is there already and it doesn’t need to be recovered, Oracle will not recover it. After reading the Oracle documentation, you might think that if you lose a single datafile, all you need to do is run the
restore database
command, and Oracle will recover only the datafile you lost.

What really happens is that Oracle determines whether the file it’s going to restore already exists. If so, and the file that exists is the same as the file it’s preparing to restore, then RMAN

will not restore that file again. If the file on the backup image is different in any respect from the existing datafile, then RMAN will recover that file. So, if you lose a datafile or two, you will want to do a datafile or tablespace recovery instead of a full database recovery (since the datafile recoveries will be faster), which we will talk about shortly.

290
Part II: Setup Principles and Practices

Let’s take a moment now and look at what’s happening during each step of the restore/recovery process. Each of these steps is quite similar for any type of ARCHIVELOG restore. After we have recovered our SPFILE and control files, if that was required, we have the
restore database
command, which causes RMAN to begin restoring all database datafiles. Note that, in this case, the database has to be down because we are restoring critical tablespaces, namely the SYSTEM

tablespace. While many ARCHIVELOG recoveries can be done online, a full database point-in-time restore cannot.

Once the datafiles have been restored, Oracle will move on to the next command, the
recover database
command. This command is much like the
recover database
command that you would issue from inside SQL*Plus in that it will cause the Oracle RDBMS to start recovering the database to the point of failure by applying the archived redo logs needed to perform a full point-in-time recovery. An additional benefit that you get from RMAN is that it restores the needed archived redo logs from disk so that they can be applied during the recovery process.

Once Oracle has recovered the database, it’s as simple as issuing an
alter database open
command to get Oracle to finish the process of opening the database for use.

In Chapter 11, we talked about how using multiple channels can make a backup go faster, and the same is true with respect to a database recovery. If you have backed up to two different devices with two different channels, make sure that during your restores you also allocate two channels (assuming the hardware being used for the restore is the same). You can benefit from parallelism when restoring both normal backups and backups that occurred using multiple section sizes.

NOTE

If you attempt a full database restore and it fails, all recovered datafiles
will be removed. This can be most frustrating if the restore has taken a
very long time to complete. We suggest that you test different recovery
strategies, such as recovering tablespaces (say four to five tablespaces
at a time), and see which works best for you and which method best

meets your recovery SLA and your disaster recovery needs.

RMAN Workshop:
Complete Recovery of Your

ARCHIVELOG Mode Database

Workshop Notes

For this workshop, you need an installation of the Oracle software and an operational test Oracle database.

NOTE

For this workshop, the database must be configured for and running in
ARCHIVELOG mode.

Step 1.
Ensure that you have configured automated backups of your control files: set oracle sid recover

rman target rman backup/password

configure controlfile autobackup on;