Oracle7 Server Concepts
An Introduction to Database Backups
No matter what backup and recovery scheme you devise for an Oracle database, operating system backups of the database's datafiles and control files are absolutely necessary as part of the strategy to safeguard against potential media failures that can damage these files. The following sections provide a conceptual overview of the different types of backups that can be made and their usefulness in different recovery schemes. The Oracle7 Server Administrator's Guide provides guidelines for performing database backups.
This section includes the following topics:
Full Backups
A full backup is an operating system backup of all datafiles and the control file that constitute an Oracle database. A full backup should also include the parameter file(s) associated with the database. You can take a full database backup when the database is shut down or while the database is open. You should not normally take a full backup after an instance failure or other unusual circumstances.
Full Online Backups vs. Full Offline Backups
Following a clean shutdown, all of the files that constitute a database are closed and consistent with respect to the current point in time. Thus, a full backup taken after a shutdown can be used to recover to the point in time of the last full backup. A full backup taken while the database is open is not consistent to a given point in time and must be recovered (with the online and archived redo log files) before the database can become available.
See the section "Online Datafile Backups" ![[*]](jump.gif)
for more information on backing up datafiles while the database is open.
Backups and Archiving Mode
The datafiles obtained from a full backup are useful in any type of media recovery scheme:
Because an archived redo log is not available to bring the database up to the current point in time, all database work performed since the full database backup must be repeated. Under special circumstances, a disk failure in NOARCHIVELOG mode can be fully recovered, but you should not rely on this.
After restoring the necessary datafiles from the full backup, database recovery can continue by applying archived and current online redo log files to bring the restored datafiles up to the current point in time.
In summary, if a database is operated in NOARCHIVELOG mode, a full backup is the only method to partially protect the database against a disk failure; if a database is operating in ARCHIVELOG mode, the files assembled by a full backup can be used to restore damaged files as part of database recovery from a disk failure.
Partial Backups
A partial backup is any operating system backup short of a full backup, taken while the database is open or shut down. The following are all examples of partial database backups:
- a backup of all datafiles for an individual tablespace
- a backup of a single datafile
- a backup of a control file
Partial backups are only useful for a database operating in ARCHIVELOG mode. Because an archived redo log is present, the datafiles restored from a partial backup can be made consistent with the rest of the database during recovery procedures.
Datafile Backups
A partial backup includes only some of the datafiles of a database. Individual or collections of specific datafiles can be backed up independently of the other datafiles, online redo log files, and control files of a database. You can back up a datafile while it is offline or online.
Choosing whether to take online or offline datafile backups depends only on the availability requirements of the data -- online datafile backups are the only choice if the data being backed up must always be available. The following sections describe each type of datafile backup.
Offline Datafile Backups Any datafile of a database can be backed up when the datafile is offline. The following situations provide examples of offline datafile backups:
- A database is shut down. As a result, all datafiles of the database are normally closed or "offline". If any datafiles of a shutdown database are backed up, these are considered offline datafile backups.
- A database is open, and a tablespace is offline. As a result, normally all datafiles of the tablespace are offline. If any datafiles of an offline tablespace are backed up, these are considered offline datafile backups.
Note: In most situations, the above are examples of when offline datafile backups can be taken. However, in certain circumstances, a database may be shutdown or a tablespace can be offline, but the associated datafiles are actually online with respect to the operating system. For example, a database may be mounted and closed for database recovery, but the associated datafiles are open and undergoing changes during the recovery operation. Avoid backing up datafiles in such situations.
When a database instance is shut down in normal priority (in other words, not aborted) or when a tablespace is taken offline in normal priority (in other words, not temporary or immediate), an offline datafile backup is a copy of "consistent" data. All of the data within an offline datafile backup is consistent with respect to a single point in time -- the time of the backup.
Online Datafile Backups If a database is operating in ARCHIVELOG mode, you can back up any datafile in it while the database is open, while the associated tablespace is online, and while the specific datafiles are online and currently in normal use. This type of datafile backup is considered an online datafile backup.
An online datafile backup is a copy of fuzzy or inconsistent data. A datafile that is online or being recovered is said to be "fuzzy" because the blocks are not necessarily written in the order they are changed. Therefore, all of the data within the online datafile backup is not guaranteed to be consistent with respect to a specific point in time. However, a fuzzy datafile backup is easily made consistent during database recovery procedures.
When the backup of an online tablespace (or individual datafile) starts, Oracle stops recording the occurrence of checkpoints in the headers of the online datafiles being backed up. This means that when a datafile is restored, it has "knowledge" 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. Once an online backup is completed, Oracle advances the file header to the current database checkpoint.
Consistent and Fuzzy Backup Data The data in datafile backups can exist in one of two states: consistent or fuzzy.
Consistent backup data is obtained when an offline datafile is backed up. This datafile must not be offline as the result of an I/O error or have been taken offline with the immediate option. The data in a single file is said to be "consistent" with itself because all blocks of data within it correspond to a specific point in time. You still must perform recovery actions if using a consistent backup to recover a database, as the backup is consistent only with itself, not with the current point in time.
To restore datafile(s) to a particular point in time, you can use a full or partial backup taken while the database is shut down or the tablespace is offline. Because the data is already consistent, no action is required to make the data in the restored datafiles correct.
If a database is not shut down cleanly (for example, an instance failure occurred, or a SHUTDOWN ABORT statement was issued), the offline datafiles can be fuzzy.
You can also use a complete or partial database backup, taken while the database is open and the tablespace is online, to restore datafiles to a particular point in time. However, the data in the restored datafiles is fuzzy. Therefore, the appropriate redo log files (online and archived) must be reapplied to these restored datafiles to make the data consistent.
Consider the following simplified example to understand how fuzzy backup data is generated, and then used during database recovery.
Example
A backup is being made of a datafile of an online tablespace. The datafile corresponds to four data blocks. For simplicity, a representative piece of data in each block is represented by a letter.
Refer to Figure 23 - 1. During this online datafile backup, the following actions take place with respect to time.
1. At the first instant in time, Block #1 of the datafile is written to the backup file.
2. At the second instant in time, Block #2 of the datafile is written to the backup file. At the same time, a modified version of data block #1 was written from the SGA to the datafile.
3. At the third instant in time, Block #3 of the datafile is written to the backup file.
4. At the fourth instant in time, a modified version of database Block #4 is written from the SGA to the datafile. This modified block is written to the backup file.
At least two redo entries were also generated because of the modifications to Blocks #1 and #4, as represented in Figure 23 - 2.
Figure 23 - 1. An Example of an Online Database File Backup
Figure 23 - 2. Redo Entires Generated During an Online Database File Backup
If the backup file restores the datafile, the restored datafile is inconsistent, as is. However, when recovery is performed the corresponding redo log entries are checked. This causes the following actions, which make the data consistent:
1. Block #1 is updated from A to E.
2. Block #4 is verified to contain the correct information (F).
Control File Backups
Another form of a partial backup is a control file backup. Because a control file keeps track of the associated database's physical file structure, a backup of a database's control file should be made every time a structural change is made to the database.
Multiplexed control files safeguard against the loss of a single control file. However, if a disk failure damages the datafiles and incomplete recovery is desired, or a point-in-time recovery is desired, a backup of the control file that corresponds to the intended database structure should be used, not necessarily the current control file. Therefore, the use of multiplexed control files is not a substitute for control file backups taken every time the structure of a database is altered.
The Export and Import Utilities
Export and Import are utilities used to move Oracle data in and out of Oracle databases. Export is a utility that writes data from an Oracle database to operating system files in an Oracle database format. Export files store information about schema objects created for a database. Import is a utility that reads Export files and restores the corresponding information into an existing database. Although Export and Import are designed for moving Oracle data, they can be used also as a supplemental method of protecting data in an Oracle database. Use of these utilities is described in Oracle7 Server Utilities.