Oracle RMAN 11g Backup and Recovery (119 page)

On the third step of the wizard, you specify destination database elements that are internal to its operation, such as the Memory Confirmation. You can make Listener changes, and run any Post Cloning scripts that are particular to your environment. On the next page, you can specify file locations, FRA specifications, archive log destinations, and where to put diagnostic and audit files (where to put the ADR). After this, you schedule the job, review the specifications, and then execute.

After the cloning is finished, you will have a clone database on your destination server, open and available, and OEM will have discovered it, meaning that you can now manage it from within OEM—If you are using Grid Control. If you are using Database Control, you will need to utilize
emca
to drop and re-create the EM repository in the new clone. This is not automated in the cloning process.

Summary

In this chapter, we discussed the architecture and configuration of Oracle Enterprise Manager 11
g
Grid Control and Oracle Enterprise Manager 11
g
Database Control. We provided examples of configuring these utilities to take RMAN backups and of configuring a database for recovery in OEM. We discussed the Oracle-suggested backup strategy and showed how to schedule a customized backup. We touched on how to perform recovery. Finally, we showed how OEM

can be used to clone a database using RMAN as the underlying technology.

CHAPTER

14

RMAN Advanced

Recovery Topics

346
Part III: Using RMAN Effectively

his chapter introduces you to some advanced recovery topics. We start with a topic that tends to cause the most trouble and confusion when it comes to recovery topics, incomplete recoveries. Next, we look at some miscellaneous recovery topics. We
T
will then look at tablespace point-in-time recovery, followed by a look at how you can verify your backups. Finally, we will look at the DBMS_BACKUP_RESTORE

package that is associated with RMAN.

Incomplete Recoveries

An incomplete recovery is just what it sounds like—a recovery of the database that is incomplete.

It is similar to a complete recovery in many respects; the basic command set is the same, but with a few added wrinkles. The possible causes of an incomplete recovery are numerous, such as the loss of online or archived redo logs or a major user error that has seriously compromised the database. Incomplete recoveries impact the entire database; in other words, you cannot perform an incomplete recovery on just one part of the database, because it would result in that part of the database having a different System Change Number (SCN, or point in time if you prefer) than the remainder of the database.

Many junior DBAs fail to recognize the important impact incomplete recovery has on the entire database. Oracle demands that a database be consistent at startup, and if it is not consistent, Oracle will complain bitterly. To illustrate the point, consider an example in which a user who has his own tablespace has just mistakenly truncated a table in that tablespace, for which he has no backup. He calls a junior DBA in a panic and asks her to recover just that tablespace to the point in time before he issued the truncate operation.

At first thought, the junior DBA might think that she can just restore the datafiles of the offending tablespace and recover them to a time before the truncate operation was executed.

Seems somewhat logical, doesn’t it? (In fact, that’s what a logical backup is for.) So, the junior DBA restores the datafiles and recovers the tablespace to a point in time before the truncate operation. Now, she’s feeling pretty good about herself. Unfortunately, her euphoria is short lived, because when she tries to open the database, RMAN slaps her with this message: ERROR at line 1:

ORA-01113: file 3 needs media recovery

ORA-01110: data file 3: 'D:\ORACLE\ORADATA\RECOVER\INDX01.DBF'

Oracle is basically saying (in this case), “You recovered the datafile all right, but you didn’t do enough recovery on it, and it’s not consistent with the rest of the database!” So, as you can see, incomplete recovery is not the solution to all of your woes, but it can be the solution to some of them. If you need a form of inconsistent recovery (a fancy way of saying you need to restore some database data to a point in time different from the rest of the database), then look at tablespace point-in-time recovery, discussed later in this chapter, or Oracle’s Flashback Technology, discussed in Chapter 16.

However, if you want to restore the entire database to some point in time in the past that Flashback Database can’t touch, then incomplete recovery is the way you need to go. When you perform a database incomplete recovery, you need to use the
resetlogs
command, because it is common to just about every incomplete recovery situation there is. We discuss
resetlogs
next, and then we discuss actual incomplete recovery methods, including time-, SCN-, log sequence–, and cancel-based recoveries.

Chapter 14: RMAN Advanced Recovery Topics
347

Using the resetlogs Command

During incomplete recoveries, you pretty much always need to use the
resetlogs
command when opening the database, because you are deviating from an already established stream of redo, and you need to indicate this to Oracle. The
resetlogs
command really represents the end of one logical life of your database and the beginning of the next logical life of your database. This logical lifespan of a database is known as an
incarnation.
Each time you use
resetlogs
, you are creating a new incarnation of the database. This can be critical with regard to recovery, as we will discuss later in this section.

With each use of the
resetlogs
command, the SCN counter is not reset. However, Oracle does reset other counters, such as the log sequence number, and resets (and re-creates if required) the contents of the online redo logs.

Starting with Oracle Database 10
g,
Oracle has made recovery through the
resetlogs
command much easier. A new substitution string has been added for the archived redo log names (
%r
), which represents the
resetlog ID number.
When
%r
is included in the
log_archive_dest_format
parameter string, the archived redo log names will remain unique through each
resetlogs
command.

This, and other internal Oracle database changes, allows Oracle to easily recover a database through a given
resetlogs
operation. Therefore, the requirement to back up the database immediately after a
resetlogs
operation is relaxed. However, we still think that backing up your database after any incomplete recovery is probably a good idea.

NOTE

In previous versions of RMAN, you needed to re-create any temporary

tablespace temp files. This is not required in Oracle Database 10
g
and
later versions. RMAN creates these datafiles for you during the recover
database process, even during incomplete recoveries!

Establishing a Point to Recover To

One of the things you need to do when performing incomplete recovery with RMAN is to establish a recovery target. The recovery target is the point at which you wish to terminate the recovery process and can be identified based on a point in time, a specific SCN, or a log sequence number.

The recovery target can be established in a number of different ways. First, you can use the
set
command along with the
until time
,
until SCN
, or
until sequence
parameter within a
run
block, as shown in this example, which uses the
set until time
command to establish the recovery target as 3 P.M. on July 1, 2006:

run

{

set until time "to date('07/01/06 15:00:00','mm/dd/yy hh24:mi:ss')"; restore database;

recover database

alter database open resetlogs;

}

When this command is issued, RMAN looks for the backup set closest to, but not including or after, this period and restores the database from that backup set. If the database is in NOARCHIVELOG mode, then recovery will stop at that point; otherwise, during the execution