|Oracle9i Backup and Recovery Concepts
Release 1 (9.0.1)
Part Number A90133-02
This chapter introduces database concepts that are fundamental to backing up a database.
This chapter includes the following topics:
Backups of Oracle data are either physical or logical.
This section contains these topics:
In contrast to logical backups, physical backups are backups of physical database files: datafiles and control files. If you run the database in
ARCHIVELOG mode, then the database also generates archived redo logs. You can back up the datafiles, control files, and archived redo logs. Backups of online redo logs are not supported, as explained in "Avoiding the Backup of Online Redo Logs".
Physical backups are divided into two categories: image copies and backups in a proprietary format. An image copy is an exact duplicate of a datafile, control file, or archived log. You can create image copies of physical files with operating system utilities or the RMAN
COPY command, and you can restore them as-is without performing additional processing by using either operating system utilities or the RMAN
BACKUP command generates a backup set, which is a logical object containing one or more backup pieces. Each backup piece is a physical file in a proprietary, binary format. You must use RMAN to restore a backup set.
In contrast to physical backups, logical backups are exports of schema objects into a binary file. Import and Export are utilities used to move Oracle data in and out of Oracle schema. Export writes data from an Oracle database to binary operating system files. These export files store information about schema objects, for example, tables and stored procedures. Import is a utility that reads export files and restores the corresponding data into an existing database.
Although Import and Export are designed for moving Oracle data, you can also use them as a supplemental method of protecting data in an Oracle database. You should not use Import and Export as the sole method of backing up your data.
Oracle9i Database Utilities to learn more about logical backups
This section includes these topics:
Whole database backups do not require you to operate the database in a specific archiving mode. Before performing whole database backups, however, be aware of the implications of backing up in
NOARCHIVELOG modes (refer to "Database Archiving Modes").
Figure 2-1 illustrates the valid configuration options given the type of backup that is performed.
You can make backups of the entire database with the following methods:
DATAFILEcommand run against each datafile in the database, and the
CONTROLFILEcommand run against the control file
A tablespace backup is a backup of the datafiles that constitute the tablespace. For example, if tablespace
users contains datafiles
4, then a backup of tablespace
users backs up these three datafiles.
Tablespace backups, whether online or offline, are valid only if the database is operating in
ARCHIVELOG mode. The reason is that redo is required to make the restored tablespace consistent with the other tablespaces in the database.
The only time a tablespace backup is valid for a database in
NOARCHIVELOG mode is when the tablespace is currently read-only or offline-normal. These cases are exceptions because no redo is required to recover them.
For example, take the scenario depicted in Figure 2-2:
Because there were no changes to the offline tablespace between t + 5 and t + 10, no media recovery is needed. If you make the tablespace read/write at t + 15 and then subsequently attempt to restore the t + 5 backup, however, Oracle requires media recovery for the changes after t + 15. Hence, you can only open the database if all necessary redo is located in the online redo logs.
You can make backups of an individual tablespace with the following methods:
DATAFILEcommand run against each datafile in the tablespace
A datafile backup is a backup of a single datafile. Datafile backups, which are not as common as tablespace backups, are valid in
ARCHIVELOG databases. The only time a datafile backup is valid for a database in
NOARCHIVELOG mode is if:
You can make backups of an individual datafile using these methods:
DATAFILEcommand, which produces a datafile copy
Backing up the control file is a crucial aspect of backup and recovery. Without an accessible control file, you cannot mount or open the database.
If you use RMAN as your backup and recovery solution, and if you run the
AUTOBACKUP command, then RMAN automatically backs up the control file whenever you run backup and copy jobs. This backup is called a control file autobackup. Because the autobackup uses a default filename, RMAN can restore this backup even if the RMAN repository is unavailable. Hence, this feature is extremely useful in a disaster recovery scenario.
You can make manual backups of the control file by using the following methods:
CONTROLFILEcreates an RMAN-specific backup of the control file, and the
CONTROLFILEcommand creates an image copy of the control file.
CONTROLFILEmakes a binary backup of the control file.
TRACEexports the control file contents to a SQL script file. You can use the script to create a new control file. Trace file backups have one major disadvantage: they contain no records of archived redo logs, offline ranges for datafiles, and RMAN backups and copies. For this reason, binary backups are preferable.
Archived redo logs are essential for recovering an inconsistent backup. The only way to recover an inconsistent backup without archived logs is to use RMAN incremental backups. To be able to recover a backup through the most recent log, every log generated between these two points must be available. In other words, you cannot recover from log 100 to log 200 if log 173 is missing. If log 173 is missing, then you must halt recovery at log 172 and open the database with the
Because archived redo logs are essential to recovery, you should back them up regularly. If you use a media manager, then back them up regularly to tape.
You can make backups of archived logs by using the following methods:
You can use RMAN or operating system commands to make an inconsistent backup or a consistent backup. An inconsistent backup is a backup of one or more database files that you make while the database is open or after the database has shut down abnormally. A consistent backup is a backup of one or more database files that you make after the database has been closed with a clean
SHUTDOWN command. Unlike an inconsistent backup, a consistent, whole database backup does not require recovery after it is restored.
Whether you make consistent or inconsistent backups depends on a number of factors. If your database must be open and available all the time, then inconsistent backups are your only option. If there are recurring periods of minimal use, then you may decide to take regular consistent backups of the whole database and supplement them with online backups of often-used tablespaces.
A consistent backup of a database or part of a database is a backup in which all read/write datafiles and control files have been checkpointed with respect to the same system change number (SCN). In addition, every online, read/write datafile is not a fuzzy file, that is, does not contain changes beyond the SCN in the datafile header. Oracle determines whether a restored backup is consistent by checking the datafile headers against the datafile header information contained in the control file.
Oracle makes the control files and datafiles consistent to the same SCN during a database thread checkpoint. The only tablespaces in a consistent backup that are allowed to have older SCNs are read-only and offline normal tablespaces, which are still consistent with the other datafiles in the backup because no changes have been made to them. If the checkpoint SCN in the datafile header matches the offline-start SCN in the control file, then Oracle knows that the datafile needs no recovery.
The important point is that you can open the database after restoring a consistent whole database backup without applying redo because the data is already consistent: no action is required to make the data in the restored datafiles correct. Hence, you can restore a year-old consistent backup of your database without performing media recovery and without Oracle performing instance recovery.
The only way to make a consistent whole database backup is to shut down the database with the
TRANSACTIONAL options and make the backup while the database is closed. If a database is not shut down cleanly, for example, an instance fails or you issue a
ABORT statement, then the database's datafiles are always inconsistent--unless the database is a read-only database. Instance recovery will be required at open time.
A consistent whole database backup is the only valid backup option for databases operating in
NOARCHIVELOG mode, because otherwise redo will need to be applied to create consistency. In
NOARCHIVELOG mode, Oracle does not archive the redo logs, and so the required redo logs may not exist on disk.
An inconsistent backup is a backup in which all read/write datafiles and control files have not been checkpointed with respect to the same SCN. For example, one read/write datafile header may contain an SCN of 100 while other read/write datafile headers contain an SCN of 95 or 90. Oracle cannot open the database until all of these header SCNs are consistent, that is, until all changes recorded in the online redo logs have been applied to the datafiles on disk.
If the database must be up and running 24 hours a day, 7 days a week, then you have no choice but to perform inconsistent backups of a whole database. For example, a backup of an offline tablespace in an open database is inconsistent with other tablespaces because portions of the database are being modified and written to disk while the backup of the tablespace is progressing. The datafile headers for the online and offline datafiles may contain inconsistent SCNs. You must run your database in
ARCHIVELOG mode to make online backups of online datafiles.
If you run the database in
ARCHIVELOG mode, then you can construct a whole database backup using backups of online datafiles taken at different times. For example, if your database contains seven tablespaces, and if you back up the control file as well as a different tablespace each night, then in a week you will back up all tablespaces in the database as well as the control file. You can consider this staggered backup as a whole database backup.
You have the option of making inconsistent closed backups if a database is backed up after a system crash or
ABORT. This type of backup is valid if the database is running in
ARCHIVELOG mode, because both online and archived redo logs are available to make the backup consistent.
If you run the database in
NOARCHIVELOG mode, then only back it up when you have closed it cleanly with the
TRANSACTIONAL options. Inconsistent whole database backups of databases running in
NOARCHIVELOG mode are usable only if the redo logs containing the changes made prior to the backup are available when you restore it--an unlikely occurrence.
The reason that
NOARCHIVELOG inconsistent backups are not recommended is that the datafile headers of the backed up files contain different SCNs (a normal shutdown guarantees the consistency of these SCNs), and because the database is in
NOARCHIVELOG mode, no archived redo logs are available to apply the lost changes. For this reason, RMAN does not allow you to back up a database that has been running in
NOARCHIVELOG mode and shut down abnormally because the backup is not usable for recovery.
The basic guideline is: if you run your database in
NOARCHIVELOG mode, always have a backup that is usable without performing any recovery. This aim is defeated if you need to apply redo from logs to recover a backup.
After an online backup or inconsistent closed backup, always ensure that you have the redo necessary to recover the backup by archiving the unarchived redo logs. When the database is open, run the following SQL statement to force Oracle to switch out of the current log and archive it as well as all other unarchived logs:
When the database is mounted, open, or closed, you can run the following SQL statement to force Oracle to archive all noncurrent redo logs:
When the database is mounted, open, or closed, you can run the following SQL statement to archive a specific group, where
integer is the number of the group:
After open or inconsistent closed backups, Oracle recommends backing up all archived logs produced during the backup, and then backing up the control file after the backup completes. If you do not have all archived redo logs produced during the backup, then you cannot recover the backup because you do not have all the redo records necessary to make it consistent. Having a control file backup generated after the completion of the database backup is helpful when using RMAN because the control file contains a record of the backup (in
This section contains these topics:
You can back up all or specified datafiles of an online tablespace while the database is open, but only when the database runs in
ARCHIVELOG mode. In this case, Oracle can write changes to the online datafiles while the backup is occurring. A backup of online datafiles is called an online backup.
One danger in making online backups is the possibility of inconsistent data within a block. For example, assume that either RMAN or an operating system utility reads the entire block while database writer is in the middle of updating the block. In this case, RMAN or the copy utility may read the old data in the top half of the block and the new data in the bottom top half of the block. In this case, the block is a fractured block, meaning that the data contained in this block is not consistent.
During an RMAN backup, an Oracle server session reads the datafiles, not an operating system utility. The server session reads whole Oracle blocks and determines whether the block is fractured by comparing the header and footer of each block. If the session detects a fractured block, then it rereads the block until it gets a consistent picture of the data.
When you back up an individual datafile or online tablespace with an operating system utility (rather than with RMAN), you must use a different method to handle fractured blocks. You must first place the online tablespace in backup mode with the
BACKUP statement. As a result, Oracle stops recording checkpoints to the tablespace's datafiles. You must put a tablespace in backup mode to make user-managed backups of datafiles in an online, read/write tablespace. After an online backup is completed, Oracle advances the file header to the current database checkpoint, but only after you run the
BACKUP statement to take the tablespace out of backup mode.
When you restore a datafile from an operating system backup, the datafile header has a record of the most recent datafile checkpoint that occurred before the online tablespace backup, not any that occurred during it. As a result, Oracle asks for the appropriate set of redo log files to apply should recovery be needed.
An offline backup is performed while the tablespace or datafile is offline. You can take tablespaces offline with the
OFFLINE statement by using any of three different options:
IMMEDIATE. Taking an offline backup with the
NORMAL option ensures that after the backup is complete, you do not have to perform recovery to bring the tablespace or datafile back online. In this way, you can perform necessary backups on datafiles and tablespaces without ever having to shut down the database or perform recovery.
This section contains these topics:
RMAN backups are stored in a different format from user-managed backups. You generate an RMAN backup by running the
BACKUP command from within the RMAN interface, as in the following example:
BACKUP command generates either a backup set or a proxy copy and writes it to the operating system or a third-party media manager (if used). A backup set is a logical construction composed of one or more backup pieces. A backup piece is a file in a proprietary format composed of the blocks from one or more input datafiles, control files, or archived redo logs. For example, you can back up 5 datafiles into 1 backup set containing 1 backup piece, which causes RMAN to intermingle the blocks from the different datafiles into a single file.
The format of a backup piece is "proprietary" in the sense that only RMAN can generate backup sets, and only RMAN can restore them. A proxy copy is a special type of RMAN backup whose data transfer is managed by a third-party media vendor. You must use the RMAN interface to create and restore proxy copies.
In contrast to the
BACKUP command, the RMAN
COPY command generates a datafile, control file, or archived log image copy that can be restored by an operating system utility. An image copy is an exact duplicate of the input file. For example, this command copies datafile
df1.copy on the operating system:
COPY command only copies to disk. However, you can use the
BACKUP command to back up image copies to tape.
Whenever you use RMAN to make a backup or copy, it records the action in the target database control file. If you use a recovery catalog, then RMAN pulls the metadata from the control file into the catalog. When you want to restore the backups or copies, run the
RESTORE command. RMAN queries the metadata and then chooses among the available backups and copies and restores them.
You must use operating system utilities to make user-managed backups. The available commands are operating system specific. For example, on a UNIX system you can back up a datafile using
dd as follows:
On Windows NT, you can back up a datafile by pressing
CTRL+C and then
CTRL+V, by dragging and dropping, or by running a
COPY command at the Command Prompt as in the following example:
One major difference between user-managed backups and RMAN backups is that in the former there is no automatic metadata record of the backup. In other words, you must manually keep records of what you back up and where you back it up.
Oracle9i User-Managed Backup and Recovery Guide to learn how to make backups using operating system utilities