Oracle RMAN 11g Backup and Recovery (28 page)

NOARCHIVELOG Mode Recoveries

If you need to recover a backup taken in NOARCHIVELOG mode, doing so is as simple as recovering all the database datafiles, the control files, and the online redo logs and starting the database. Of course, a total recovery may require such things as recovering the Oracle RDBMS

software, the parameter file, and other required Oracle items, which we will discuss in the last section of this chapter.

Chapter 1: Oracle Database 11
g
Backup and Recovery Architecture Tour
29

Note that a recovery in NOARCHIVELOG mode is only possible to the point in time that you took your last backup. If you are recovering a database backed up in NOARCHIVELOG mode, you can only recover the database to the point of the backup. No database changes after the point of the backup can be recovered if your database is in NOARCHIVELOG mode.

ARCHIVELOG Mode Recoveries

A database that is in ARCHIVELOG mode can be backed up using online or offline backups. The fortunate thing about ARCHIVELOG mode, as opposed to NOARCHIVELOG mode, is that you can recover the database to the point of the failure that occurred. In addition, you can choose to recover the database to a specific point in time, or to a specific point in time based on the change number.

ARCHIVELOG mode recoveries also allow you to do specific recoveries on datafiles, tablespaces, or the entire database. In addition, you can do point-in-time recovery or recovery to a specific SCN. Let’s quickly look at each of these options.

In this section, we briefly cover full database recoveries in ARCHIVELOG mode. We then look at tablespace and datafile recoveries, followed by point-in-time recoveries.

ARCHIVELOG Mode Full Recovery
You can recover a database backup in ARCHIVELOG

mode up to the point of failure, assuming that the failure of the database did not compromise at least one member of each of your current online redo log groups and any archived redo logs that were not backed up. If you have lost your archived redo logs or online redo logs, then you will need to perform some form of point-in-time recovery, as discussed later in this section. Also, if you have lost all copies of your current control file, you will need to recover it and perform incomplete recovery.

To perform full database recovery from a backup of a database in ARCHIVELOG mode, follow this procedure:

1.
Restore all the database datafiles from your backup.

2.
Restore all backed up archived redo logs.

3.
Mount the database (
startup mount
).

4.
Recover the database (
recover database
).

5.
Oracle prompts you to apply redo from the archived redo logs. Simply enter
AUTO
at the prompt, and Oracle will automatically apply all redo logs.

6.
Once all redo logs have been applied, open the recovered database (
alter database open
).

ARCHIVELOG Tablespace and Datafile Recovery
Tablespace and datafile recovery can be performed with the database mounted or open. To perform a recovery of a tablespace in Oracle with the database open, follow these steps:

1.
Take the tablespace offline (
alter tablespace offline
).

2.
Restore all datafiles associated with the tablespace to be recovered.

3.
Recover the tablespace (
recover tablespace
) online.

4.
Once recovery has completed, bring the tablespace online (
alter tablespace online
).

30
Part I: Getting Started with RMAN in Oracle Database 11
g
Just as you can recover a tablespace, you can also recover specific datafiles. This has the benefit of leaving the tablespace online. Only data that resides in the offline datafiles will be unavailable during the recovery process. The rest of the database will remain available during the recovery. Here is a basic outline of a datafile recovery:

1.
Take the datafile offline
(alter database datafile ‘file_name’ offline
).

2.
Restore all datafiles to be recovered.

3.
Recover the tablespace (
recover datafile
) online.

4.
Once recovery has completed, bring the datafile online (
alter database datafile ‘file_

name’ online
).

ARCHIVELOG Point-In-Time Recoveries
Another benefit of ARCHIVELOG mode is the capability to recover a database to a given point in time rather than to the point of failure. This capability is used often when creating a clone database (perhaps for testing or reporting purposes) or in the event of major application or user error. You can recover a database to either a specific point in time or a specific database SCN.

If you want to recover a tablespace to a point in time, you need to recover the entire database to the same point in time (unless you perform tablespace point-in-time recovery, which is a different topic). For example, assume that you have an accounting database, that most of your data is in the ACCT tablespace, and that you wish to recover the database back in time two days. You cannot just restore the ACCT tablespace and recover it to a point in time two days ago, because the remaining tablespaces (SYSTEM, TEMP, and RBS, for example) will still be consistent to the current point in time, and the database will fail to open because it will be inconsistent.

To recover a database to a point in time, follow these steps:

1.
Recover all database datafiles from a backup that ended before the point in time that you want to recover the database to.

2.
Recover the database to the point in time that you wish it to be recovered to. Use the command
recover database until time ‘01-01-2010 21:00:00’
and apply the redo logs as required.

3.
Once the recovery is complete, open the database using the
alter database open
resetlogs
command.

You can also choose to recover the database using an SCN number:

1.
Recover all database datafiles from a backup that ended before the point in time that you want to recover the database to.

2.
Recover the database to the SCN that you wish it to be recovered to. Use the command
recover database until change ‘221122’
and apply the redo logs as required.

3.
Once the recovery is complete, open the database.

Further, you can apply changes to the database and manually cancel the process after a specific archived redo log has been applied:

1.
Recover all database datafiles from a backup that ended before the point in time that you want to recover the database to.

Chapter 1: Oracle Database 11
g
Backup and Recovery Architecture Tour
31

2.
Recover the database to the point in time that you wish it to be recovered to. Use the command
recover database until cancel
and apply the redo logs as required. When you have applied the last archived redo log, simply issue the
cancel
command to finish applying redo.

3.
Once the recovery is complete, open the database.

Keep in mind the concept of database consistency when doing point-in-time recovery (or any recovery, for that matter). If you are going to recover a database to a given point in time, you must do so with a backup that finished before the point in time that you wish to recover to. Also, you must have all the archived redo logs (and possibly the remaining online redo logs) available to complete recovery.

A Word About Flashback Database
Another recovery method available to you is the use of Oracle’s flashback features. We will cover Oracle’s flashback features in more depth in Chapter 13, but know that with the various flashback functionality, you can significantly reduce the overall time it takes to recover your database from user- and application-level errors. RMAN supports some of the Oracle Database 11
g
flashback features, so it is most appropriate to cover those in this book.

Backing Up Other Oracle Components

We have quickly covered the essentials of backup and recovery for Oracle. One last issue that remains to be covered are the things that need to be backed up. These are items that generally are backed up with less frequency because they change rarely. These items include

■ The Oracle RDBMS software (Oracle Home and the Oracle Inventory).

■ Network parameter files (names.ora, sqlnet.ora, and tnsnames.ora).

■ Database parameter files (init.ora, INI files, and so forth). Note that RMAN does allow you to back up the database parameter file (only if it’s a SPFILE) along with the control file!

■ The system oratab file and other system Oracle-related files (for example, all rc startup scripts for Oracle).

It is important that these items be backed up regularly as a part of your backup and recovery process. You need to plan to back up these items regardless of whether you do manual backups or RMAN backups, because RMAN does not back up these items either.

As you can see, the process of backup and recovery of an Oracle database can involve a number of steps. Since DBAs want to make sure they do backups correctly every time, they generally write a number of scripts for this purpose. There are a few problems with this practice.

First of all, scripts can break. When the script breaks, who is going to support it, particularly when the DBA who wrote it moves to a new position somewhere in the inaccessible tundra in northern Alaska? Second, either you have to write the script to keep track of when you add or remove datafiles, or you have to manually add or remove datafiles from the script as required.

With RMAN, you get a backup and recovery product that is included with the base database product for free, and that reduces the complexity of the backup and recovery process. Also, you get the benefit of Oracle support when you run into a problem. Finally, with RMAN, you get additional features that no other backup and recovery process can match. We will look at those in coming chapters.

32
Part I: Getting Started with RMAN in Oracle Database 11
g
RMAN solves all of these problems and adds features that make its use even more beneficial for the DBA. In this book, we will look at these features and how they can help make your life easier and make your database backups more reliable.

Summary

We didn’t discuss RMAN much in this chapter, but we laid some important groundwork for future discussions of RMAN that you will find in later chapters. As promised, we covered some essential backup and recovery concepts, such as high availability and backup and recovery planning, that are central to the purpose of RMAN. We then defined several Oracle terms that you need to be familiar with later in this text. We then reviewed the Oracle database architecture and internal operations. We cannot stress enough how important it is to have an understanding of how Oracle works inside when it comes time to actually recover your database in an emergency situation.

Finally, we discussed manual backup and recovery operations in Oracle. Contrast these to the same RMAN operations in later chapters, and you will find that RMAN is ultimately an easy solution to backup and recovery of your Oracle database.

CHAPTER

2

Introduction to the

RMAN Architecture

34
Part I: Getting Started with RMAN in Oracle Database 11
g
his chapter will take you through each of the components in the RMAN architecture one by one, explaining the role each plays in a successful backup or recovery of the Oracle database. Most of this discussion assumes that you have a good understanding
T
of the Oracle RDBMS architecture. If you are not familiar at a basic level with the different components of an Oracle database, you might want to read the brief introduction in Chapter 1, or pick up a beginner’s guide to database administration, before continuing. After we discuss the different components for backup and recovery, we walk through a simple backup procedure to disk and talk about each component in action.