1
Backup and Recovery Overview

In general, backup and recovery refers to the various strategies and procedures involved in protect ing your database against data loss and reconstructing the database after any kind of data loss.

Physical Backups and Logical Backups

A backup is a copy of data from your database that can be used to reconstruct that data. Backups can be div ided into physical backups and logical backups.

Physical backups are backups of the physical files used in storing and recovering your database, such as datafiles, control files, and archived redo logs. Ultimately, every physical backup is a copy of files storing database information to some othe r location, whether on disk or some offline storage such as tape.

Logical backups contain l ogical data (for example, tables or stored procedures) exported from a database with an Oracle export utility and stored in a binary file, for later re-importing into a database using the corresponding Oracle import utility..

See also: Oracle Database Utilities for more details about importi ng and exporting data using Oracle export and import utilities.

Physical backups are the foundation of any sound backup and recovery strategy. Logical backups are a useful supplement to phy sical backups in many circumstances but are not sufficient protection against data loss without physical backups.

Unless otherwise specified, the term "backup" as used in the backup and recovery documentation refers to physi cal backups, and to backup part or all of your database is to take some kind of physcial backup. The fo cus in the backup and recovery documentation set will be almost exclusively on physical backups.

Errors and Failures Requiring Recovery from B ackup

While there are several types of problem that can halt the nor mal operation of an Oracle database or affect database I/O operations, only two typically require DBA intervention and media recovery : media failure, and user errors.

Other failures may require DBA intervention to restart th e database (after an instance failure) or allocate more disk space (after statement failure due to, for instance, a full datafile) bu t these situations will not generally cause data loss or require recovery from backup.

User Error

User errors occur when, either due to an error in application logic or a manual mis-step, data in your database is changed or deleted incorrectly. Data loss due to user error includes such missteps as dropping important tables or deleting or cha nging the contents of a table. While user training a nd careful management of privileges can prevent most user errors, your backup st rategy determines how gracefully you recover the lost data when user error does cause data loss.

Media Failure

A media failure is the failure of a read or write of a disk file required to run the database, due to a physical problem with the disk such as a head crash. Any database file can be vulnerable to a media failure.

• Recovery Manager (RMAN), a tool (with command-line client and Enterprise Manager GUI interfaces) that integrates with sessions running on the Oracle server to perform a r ange of backup and recovery activities, as well as maintaining a repository of historical data about your backups
• The traditional u ser-managed backup and recovery, where you directly manage the files that make up your database with a mixture of host operating system commands and SQL*Plus backup and recovery-related capabilities

Both methods are supported by Oracle Corporation and are fully documented. Recovery Manager is, however, the preferred solution fo r database backup and recovery. It can perform the same types of backup and recovery available through user-managed methods more easi ly, provides a common interface for backup tasks across different host operating systems, and offers a number of backup techniques no t available through user-managed methods.

Most of the backup and recovery documentation set will focus on RMAN-based backup and recovery. User-managed backup and recovery techniques are covered in the later chapters of Oracle Database Backup and Recovery Advanced User's Guide.

Whether you u se RMAN or user-managed methods, you can supplement your physical backups with logical backups of schema objects made using data expo rt utilities. Data thus saved can later be imported to re-create this data after restore and recovery. However, logical backups are f or the most part beyond the scope of the backup and recovery documentation.

Backup and Recovery: Basic Concepts< /h2>

The physical structures of the database and the role each plays in the data base recovery process are what determine the forms of backup and recovery available through user-managed techniques and through RMAN.

Physical Database Structures Used in Recovering Data

The files and other structures that make up an Oracle database store data and safeguard it against possible failures. This section in troduces each of the physical structures that make up an Oracle database and their role in the reconstruction of a database from back up. This section contains these topics:

• Datafiles and Data Blocks
• Redo Logs< /li>
• Undo Segments
• Control Files

Datafiles and Data Blocks

An Oracle database consists of one or more logical storage units called tablespaces. Each tablespace in an Or acle database consists of one or more files called datafiles, physical files under the host operating system in which the database is running.

A database's data is collectively stored in the datafiles that constitute each ta blespace of the database. The simplest Oracle database would have one tablespace, stored in one datafile. The datbase manages the sto rage space in the datafiles of a database in units called data blocks. A data block is the smallest unit of data used by a database. Data blocks are the smallest units of storage that the database can use or allocate.

Modifi ed or new data is not written to datafiles immediately. Updates are buffered in memory and written to datafiles at intervals. If a da tabase has not gone through a normal shutdown (that is, if it is open, or exited abnormally, as in an instance failure or a SHU TDOWN ABORT) then there are typically changes in memory that have not been written to the datafiles. Datafiles that were resto red from backup, or were not closed during a consistent shutdown, are typically not completely up to date.

Copies of the datafiles of a database are a c ritical part of any backup.

See also: Oracle Database Concepts for more detail about the structure and contents of datafiles and data blocks.

Redo Logs

Redo logs record all changes made to a database's data files. With a complete set of redo logs and an older copy of a datafile, the databa se can reapply the changes recorded in the redo logs to re-create the database at any point between the backup time and the end of th e last redo log. Each time data is changed in the database, that change is recorded in the online redo log first, before it is applied to the datafiles. An Oracle d atabase requires at least two online redo log groups, and in each group there is at least one online redo log member, an individual redo log file where the changes a re recorded.

At intervals, the database rotates through the online redo log groups, storing changes in the current online redo log while the groups not in use can be copied to an archive location, where they are called archive d redo logs (or, collectively, the archived redo log). You can run your database in ARCHIVELOG mode (in which this archiving of redo log files is enabled) or NOARCHIVELOG mode (in w hich redo log files are simply overwritten).

Preserving the archived redo log is a major pa rt of most backup strategies, as they contain a record of all updates to datafiles. Backup strategies often involve copying the archi ved redo logs to disk or tape for longer-term storage. Running in NOARCHIVELOG mode limits your data recovery options.

See also: Oracle Database Administrator's Guide for more details about the online redo logs, Oracle Database Administrator's Guide for more details about archived redo logs, and "Deciding Between ARCHIVELOG and NOARCHIVELOG Mode" for a discussion of the implic ations of archiving or discarding your redo log files.

Control Files

The control file contains a crucial record of the physical structures of the database and their status. Se veral types of information stored in the control file are related to backup and recovery:

• Database information (RESETLOGS SCN and time stamp)
• Tablespace and datafile records (filenames, datafile checkpoints, read/write status, offline ranges)
• Information about redo threads (current online redo log)
• Log records (log sequence numbers, SCN range in each log)
• A record of past RMAN backups
• Information about corrupt datafile blocks

The recovery process for datafiles is in part guided by status information in the control file, such as the database checkpoints, current online redo log file, and the datafile header checkpoints for the datafi les. Loss of the control file makes recovery from a data loss much more difficult.

Undo Segments

In general, when data in a datafile is updated, "before images" of that data are written into undo segments. If a transaction is rolled back, this und o information can be used to restore the original datafile contents.

In the context of reco very, the undo information is used to undo the effects of uncommitted transactions, once all the datafile changes from the redo logs have been applied to the datafiles. The database is actually opened before the undo is applied.

You should not have to concern yourself with undo segments or manage them directly as part of your backup and recovery process.< /p>

See also: Oracle Database Concepts for more information about control files.

See also: Oracle Database Concepts for detailed information about undo segements.

The Dat abase Recovery Process: Basic Concepts

Reconstructing the contents o f all or part of a database from a backup typically involves two phases: retrieving a copy of the datafile from a backup, and reapply ing changes to the file since the backup from on the archived and online redo logs, to bring the database to the desired SCN (usually the most recent one).

To restore a datafile or control file from backup is to retrieve the file onto disk from a backup l ocation on tape, disk or other media, and make it available to the database server.

To recover a datafile (also called performing recovery on a datafile), is to tak e a restored copy of the datafile and apply to it changes recorded in the database's redo logs. To recover a whole database is to per form recovery on each of its datafiles.

Figure 1-1 ill ustrates the basic principle of backing up, restoring, and recovering a database. Most of the data recovery procedures supported by t he Oracle database are variations on the process described here.

Figure 1-1 Restoring and Recovering a Database

Text description of the illustration brbsc002.gif

In this example a full backup of a database (copies of its datafiles and control file) i s taken at SCN 100. Redo logs generated during the operation of the database capture all changes that occur between SCN 100 and SCN 5 00. Along the way, some logs fill and are archived. At SCN 500, the datafiles of the database are lost due to a media failure. The da tabase is then returned to its transaction-consistent state at SCN 500, by restoring the datafiles from the backup taken at SCN 100, then applying the transactions captured in the archived and online redo logs and undoing the uncomitted transactions.

Forms of Data Recovery

The preceding scenario outlined the basics of the restore-and-recover y process. Several variants on this scenario are important to your backup and recovery work.

This section contains the following topics:

• Datafile Media Recovery: Restore Datafiles, Apply Redo
• Automatic Recovery After Instance Failure: Crash Recovery
• Complete, Incomplete and Point-In-Time Recovery

Datafile Media Recovery: Restore Datafiles, Apply R edo

Datafile media recovery (often sim ply called media recovery) is the most basic form of user-initiated data recovery. It can be used to re cover from a lost or damaged current datafile, SPFILE or control file. It can also recover changes that were recorded in the redo log s but not in the datafiles for a tablespace that went offline without the OFFLINE NORMAL option. Datafile m edia recovery can be performed whether you use Recovery Manager or user-managed backup and recovery. (For user-managed backup and rec overy, it is in fact the main option available.)

Like crash recovery, datafile media recove ry is intended to restore database integrity. However, there are a number of important differences between the two:

• Media recovery must be explicitly invoked by a user. The database will not run media recovery on its own.
• Media recovery applies needed changes to datafiles that have been restored from backup, not to online datafiles left over after a crash.
• Media recovery must use archived logs as well as the online logs, to find changes reaching back to the time of the datafile b ackup.

The need to restore a datafile from backup is not detected automatically. The first step in performing media recovery is to manually restore the datafile by copying it from a backup. Once a datafile has been cop ied from backup, however, the database does automatically detect that this datafile is out of date and must undergo media recovery.

Several situations force you to perform media recovery:

• You restore a backup of a datafile.
• You res tore a backup control file (even if all datafiles are current).
• A datafile is taken offline (either by you or automatically by the database) without the OFFLINE NORMAL option.

For a datafile to be available for media recovery, one of two things must be true:

• The database that the datafile belongs to must not be open;

or

• The specific datafile ne eding recovery must be offline, if the database is open.

A datafile that needs media recovery cannot be brought online until media recovery has been completed. A database cannot be opened if any of the online datafiles needs media recovery.

You can manage the expected duration of media recovery as part of yo ur backup and recovery strategy. It is affected by, for example, the frequency of backups and parallel recovery parameters.

Complete, Incomple te and Point-In-Time Recovery

Complete recovery is recovering a database to the most recent point in time, without the loss of any committed transactions. Generally, the t erm "recovery" refers to complete recovery.

Occasionally, however, you need to return a dat abase to its state at a past point in time. For example, to undo the effect of a user error, such as dropping or deleting the content s of a table, you may want to return the database to its contents before the delete occurred. In incomplete reco very, also known as point-in-time recovery, the goal is to restore the database to its state a t some previous target SCN or time. Point-in-time recovery is one possible response to a data loss caused by, for instance, a user er ror or logical corruption that goes unnoticed for some time.

Point-in-time recovery is also your only option if you have to perform a recovery and discover that you are missing an archived log covering time between the backu p you are restoring from and the target SCN for the recovery. Without the missing log, you have no record of the updates to your data files during that period. Your only choice is to recover the database from the point in time of the restored backup, as far as the un broken series of archived logs permits, then perform an OPEN RESETLOGS and abandon all changes in or after the missing log. (If you d iscover that you have lost archived logs and your database is still up, you should do a full backup immediately.)

Note: If only one tablespace is affected by the data loss, you have the option of performing point-in-time recovery on that tablespace instead of the entire databas e. Tablespace point-in-time recovery (often abbreviated TSPITR) is an advanced technique documented in Oracle Database Backup and Recovery Advanced User's Guide.

Automatic Recovery After Instance Failure: Crash Recovery

The crash recovery process is a special form of recovery, which happens the first time an Oracle database instance is started after a crash (or SHUT DOWN ABORT). In crash recovery, the goal is to bring the datafiles to a transaction-consistent state, preserving all committed changes up to the point when the instance failed.

Unlike the forms of recovery performed m anually after a data loss, crash recovery uses only the online redo log files and current online datafiles, as left on disk after the instance failure. Archived logs are never used during crash recovery, and datafiles are never restored from backup.

The database applies any pending updates in the online redo logs to the online datafiles of your database. The result is that, whenever the database is restarted after a crash, the datafiles reflect all committed changes up to the moment wh en the failure occurred. (After the database opens, any changes that were part of uncommitted transactions at the time of the crash a re rolled back.)

The duration of crash recovery is a function of the number of instances ne eding recovery, amount of redo generated in the redo threads of crashed instances since the last checkpoint, and user-configurable fa ctors such as the number and size of redo log files, checkpoint frequency, and the parallel recovery setting.You can set parameters i n the database server that can tune the duration of crash recovery. You can also tune checkpointing to optimize recovery time.

Note: Crash recovery in a Real Application Cluster (RAC) database takes place when all instances in the cluster have fail ed. The related process of instance recovery takes place when some but not all instances fail. For more information on crash and instance recovery in the context of RAC, refer to Real Application Clusters Quick Start.