Oracle7 Server Administrator's Guide

Contents Index Home Previous Next

Guidelines for Database Backups

This section describes guidelines to consider before performing database backups, and includes the following topics:

Before you create an Oracle database, you should decide how you plan to protect the database against potential disk failures, or to enable point-in-time recovery (if desired). If such planning is not considered before database creation, database recovery may not be possible if a disk failure damages the datafiles, online redo log files, or control files of a database.

See Also: See "Creating a Backup Strategy" [*] if you are not familiar with typical backup strategies for a database.

Test Backup and Recovery Strategies

Test your backup and recovery strategies in a test environment before and after you move to a production system. By doing so, you can test the thoroughness of your strategies and minimize problems before they occur in a real situation.

Performing test recoveries regularly ensures that your archiving, backup, and recovery procedures work. It also helps you stay familiar with recovery procedures, so that you are less likely to make a mistake in a crisis.

Perform Operating System Backups Frequently and Regularly

Frequent and regular full or partial database backups are essential for any recovery scheme. The frequency of backups should be based on the rate or frequency of changes to database data (such as insertions, updates, and deletions of rows in existing tables, and addition of new tables). If a database's data is changed at a high rate, database backup frequency should be proportionally high. Alternatively, if a database is mainly read-only, and updates are issued only infrequently, the database can be backed up less frequently.

Backup Appropriate Portions of the Database When Making Structural Changes

If you make any of the following structural changes, perform a backup of the appropriate portion of your database immediately before and after completing the alteration:

Backing up the appropriate portion of the database depends on the archiving mode of the database, as described below:

Back Up Often-Used Tablespaces Frequently

If a database is operated in ARCHIVELOG mode, it is acceptable to back up the datafiles of an individual tablespace or even a single datafile. This option is useful if a portion of a database is used more extensively than others, such as the SYSTEM tablespace and tablespaces that contain rollback segments. By taking more frequent backups of the extensively used datafiles of a database, you gather more recent copies of the datafiles. As a result, if a disk failure damages the extensively used datafiles, the more recent backup can restore the damaged files. Only a small number of changes to data need to be applied to roll the restored file forward to the time of the failure, or desired point-in-time recovery, thereby reducing database recovery time.

Keep Older Backups

How long you should keep an older database backup depends on the choices you want for database recovery. If you want to recover to a past point-in-time, you need a database backup taken before that point-in-time. For a database operating in NOARCHIVELOG mode, this means a full database backup. For a database operating in ARCHIVELOG mode, this means you should perform a backup of each datafile, taken individually or together, taken any time before the desired recovery point-in-time, and a backup of the associated control file that reflects the database's structure at the point-in-time of recovery.

For added protection, consider keeping two or more backups (and all archive logs that go with these backups) previous to the current backup.

Warning: After opening the database with the RESETLOGS option, existing backups cannot be used for subsequent recovery beyond the time when the logs were reset. You should therefore shutdown the database and make a full offline backup. Doing so will enable recovery of database changes subsequent to using the RESETLOGS option.

See Also: For more information on the Export utility, see the Oracle7 Server Utilities guide.

Export Database Data for Added Protection and Flexibility

Because the Oracle Export utility can selectively export specific objects, you might consider exporting portions or all of a database for supplemental protection and flexibility in a database's backup strategy. Database exports are not a substitute for operating system backups and cannot provide the same complete recovery advantages that the built-in functionality of Oracle offers.

Consider Distributed Database Backups

If a database is a node in a distributed database, consider the following guidelines:

See Also: For more information about distributed database recovery when databases are operating in NOARCHIVELOG mode, see "Coordinate Distributed Recovery" [*].

Back Up after Creating Unrecoverable Objects

If users are creating tables or indexes using the UNRECOVERABLE option, consider taking backups after the objects are created. When tables and indexes are created as UNRECOVERABLE, no redo is logged, and these objects cannot be recovered from existing backups.

See Also: For information about the UNRECOVERABLE option, see the CREATE TABLE...AS SELECT and CREATE INDEX commands in the Oracle7 Server SQL Reference.

Contents Index Home Previous Next