Oracle RMAN 11g Backup and Recovery (93 page)

CHAPTER

12

RMAN Restore and

Recovery

266
Part II: Setup Principles and Practices

ll of your planning and backing up is about to pay off. This chapter is about restoring your backups and then recovering your database. We will first address some basic issues regarding the overall recovery process. Then, we will look at the
A
different methods that you might need to use to restore your RMAN backups to disk and to recover your Oracle database in the event of an outage. We strongly suggest that you test these different types of recoveries on a test database, because you never quite know when you will need to recover your database, and under what conditions.

This chapter is an introduction to foundational restores in RMAN. The number of situational recovery permutations that might exist for a given database is pretty large (we tried to figure it out, but we blew our budget on designing a computer to calculate the answer, and it ended up just giving us plans for a bigger computer to do the job), so it’s important that you understand not only the mechanics of recovery (as we will discuss here), but also how it works in concert with Oracle’s architecture. In this chapter, you will find some rather straightforward recovery situations. In Chapter 15, we will address some of the more advanced recovery techniques. In Chapter 21, we will plow through a number of different recovery case studies. We suggest you read this chapter and test each of the recoveries documented here. Then, look at the more advanced situations in Chapter 15. Once you are really good at recoveries, look at Chapter 21 and try out some of those restores.

RMAN Restore and Recovery Basics

In this chapter, we will be discussing the concepts of restores and recoveries. In RMAN parlance,

“restore” and “recovery” have different meanings. A
restore
implies that we are accessing a previously made backup set to get one or more objects from it and to restore them to some location on disk. A restore is separate from a recovery, then, in that a
recovery
is the actual process of making a database consistent to a given point in time so that it can be opened, generally through the application of redo (contained in online redo logs or archived redo logs).

If the Oracle RDBMS is anything, it is particular. The database is particular about the state of the data within the database, and it demands that the data be consistent to a given state in time when the database is started. If the database is consistent, then it will open; if it isn’t consistent, then it will not open. Through the use of rollback segments, this consistency is maintained while the database is up and running. When the database is shut down normally, the datafiles are made consistent again. As you’ve likely noticed, the ongoing theme here is consistency.

Unfortunately, inconsistency can creep into the database through myriad causes. An abnormal shutdown of the database (as happens with a
shutdown abort
, or due to power loss on the server) will leave it in an inconsistent state. Oracle hates inconsistency, and it refuses to just start the database in the face of this demon.

Of course, other problems can plague your database. You can lose database datafiles through the loss of a disk, or perhaps lose the entire database. It is because these kinds of losses occur that you back up your database datafiles with RMAN. The problem is that when you restore those datafiles, they are likely to be inconsistent. Worse yet, those restored datafiles are likely to be anywhere from a few hours old to several days old—which safely qualifies as really inconsistent.

As we said, Oracle is a stickler about consistency. When you try to restart the database after recovering datafiles, Oracle is going to detect that those datafiles are in an inconsistent state. How does it do this? Recall from Chapter 1 our discussion of the SCN. Oracle tracks the current SCN in the datafile headers of each database datafile and in the database control file. Oracle goes Chapter 12: RMAN Restore and Recovery
267

through three stages when opening the database: nomount, mount, and open. When the database startup enters the open stage, Oracle begins attempting to open the database. As it opens the database, it checks the SCN in the control file against the SCNs in each of the database datafiles.

If the SCNs don’t match, Oracle knows that something is amiss with the database and that it is inconsistent.

Other checks occur during startup, as well, and some of these are not consistency checks. For example, Oracle checks each datafile for a bit that indicates the datafile is in hot backup mode.

If this bit is set, Oracle will not open the database. In this event, a simple
alter database datafile
end backup
command will suffice to restart the database. Oracle might also determine, while trying to open the database, that a given datafile is missing. The solution to this problem might be as easy as mounting the file system the datafile is on, or perhaps a restore of the datafile will be required.

If Oracle discovers that the database is inconsistent, it needs to determine whether it can recover the database based on the online redo logs, or whether it’s going to require archived redo logs to do the trick. If it can perform the recovery with the online redo logs, then Oracle will perform crash recovery (or instance recovery in the case of Real Application Clusters). If Oracle cannot make the database consistent with the online redo logs, it will stop the startup process and report that media recovery is required.

Media recovery is a condition where Oracle will require archived redo logs to recover the database and to make it consistent if the database is in ARCHIVELOG mode. If the database is in NOARCHIVELOG mode, then a restore/recovery of a consistent backup of the database will likely be required. This chapter is all about recovery of your database. You can do all kinds of recoveries. Sometimes you will need to recover the entire database, and sometimes you will just need to recover a few datafiles. We will discuss all of these different possibilities in this chapter.

We have highlighted the issues that revolve around restore and recovery of your database.

Now it’s time to hit the road and see how this all works in practice.

Before You Can Restore the Database

In this chapter, we are going to approach the restore and recovery process from the beginning, assuming you have nothing left of your database except a backup somewhere. First, we are going to look at restoring the SPFILE, if you are using one, and then we will look at restoring the control file. Once we have those preliminaries out of the way, we will move on to the bigger topic of restoring and recovering the database. Of course, your specific recovery situation may not require recovery to this depth. You might have lost just a few datafiles, or perhaps you want to perform a point-in-time recovery. Some restores will need to use these preliminary steps and others will not.

We think that between the layout of this chapter and the case studies later in this book, you will be quite confident as to what you need to restore and when.

Finally, you will note that in most of the examples we use, we do not connect to a recovery catalog unless the operation is different when using the recovery catalog. This lends some consistency to our examples and saves a few pages with duplicate results. So, keep an eye out for any notes that we might include about recovery catalog issues.

Before RMAN Can Get Going

Before RMAN can do its thing, you need to do a few things first. Preparation is the mother of success, someone once said, and this is so true when it comes to restoring your database. You
268
Part II: Setup Principles and Practices

need to work with your system administrator to make sure the following are done before you attempt your restore/recovery:

■ The OS parameters are configured for Oracle.

■ Your disks are configured correctly and are the correct sizes.

■ The tape drives are installed, and the tape software is installed and configured.

■ Your network is operational.

■ The Oracle RDBMS software is installed.

■ The MML is configured.

■ Ancillary items are recovered from backups that RMAN does not back up, which include

■

The database networking files (for example, sqlnet.ora and listener.ora)

■

The oratab file, if one is used

■

The database parameter files, if they are not SPFILEs and are not backed up by RMAN

■

Any RMAN control file backups that were made to disk if you have enabled autobackup of control files

Once these items have been restored, you are ready to begin restoring your Oracle database.

If you are using a recovery catalog, you will want to recover it first, of course. Then, you can recover the remaining databases.

When you start recovering databases, you need to start by recovering the SPFILE (if you are using one and it was backed up), followed by the control file. The next two sections cover those topics for you.

A Note about Recoveries, the Recovery Catalog,

and the MML Layer

In our travels around the world to talk about RMAN, and in our own experiences, we’ve learned a thing or two that really strike us as important. One of these lessons learned is that when you are using one of the MML API interfaces, it is almost a requirement to use a recovery catalog. Why is the recovery catalog so important, you might ask?

Remember that all of the important RMAN metadata is stored in the control file. If you lose the control file, then all of this important metadata is lost. If you are doing automated control file backups (
set controlfile autobackup on
), then this is one way of making sure that you protect the control file from loss. We have had some cases, however, where restoring the control file from the MML backups was quite complex and time-consuming. For example, we have had a case where the backup was successful, but the control file autobackup was not. In this case, you really want to have a recovery catalog available!

Having a recovery catalog would have made the job much easier, and when we are talking about restores, time is a precious component. Many of the MML vendors do not support taking RMAN files directly off of their backup media and restoring them without using the RMAN client.

Chapter 12: RMAN Restore and Recovery
269

Also, getting a list of all the RMAN backup set pieces contained on backup media along with the time/date they were created can be difficult. Finally, you cannot use the
catalog
command to catalog backup set pieces backed up to an MML device. Thus, if you lose your control file and have to recover it manually, the recovery of backup set pieces is much more complex (possible, but complex). Overall, you have several pretty good reasons to use a recovery catalog. We discuss the recovery catalog in great detail in Chapter 10.

Restoring the SPFILE

If you are not using Oracle9
i
Release 2 or later and are not using an SPFILE, then this section really does not apply to you. As a result, you need to restore your SPFILE (or your database parameter file) from an operating system backup. On the other hand, if you have started using SPFILEs and you have backed them up using RMAN’s control file autobackup abilities, then you are in good shape!

Recall from Chapter 9 that we suggested that if you are performing RMAN database backups without a recovery catalog, you might want to note the DBID of your database for restore and recovery purposes. This is one of those times that such an action comes in handy, though it is not 100 percent critical.

SPFILE recoveries come in several flavors, including recoveries that do not use the flash recovery area (FRA) and those that do use the FRA. RMAN offers other ways to recover the SPFILE, as we will find in the following sections.

Recovering the SPFILE from an Autobackup Using RMAN, No FRA

If you have lost your SPFILE, you will want to recover it from the control file autobackup set if you are using this feature. As we have already described, Oracle will by default back up the SPFILE

(along with the control file) to the $ORACLE_HOME/dbs or to the ORACLE_HOME%\database directory (depending on the operating system). If you choose to use the default location (or if you back up to an alternate disk location), you will probably want to back up these backup sets to another backup medium such as tape (which RMAN can do for you).

The general procedure to restore the SPFILE is to first set your ORACLE_SID and then log into RMAN. Then, you need to set the DBID, so that RMAN will know which database SPFILE it is looking for. We have to start the database instance at this point in the operation. The instance of an Oracle Database 10
g
database will not start on its own without a basic parameter file being present.

Having started the instance, if you are using the default location to back up your control file autobackup to, you can simply issue the
restore spfile from autobackup
command, and RMAN