Lesson 1

Before you create an Oracle database, you need to plan how you will protect the database against potential media or disk failure, and whether or not to enable point-in-time recovery. If such planning is not done, you may not be able to recover the database if a disk failure damages the datafiles, online redo log files, or control files. This module investigates various methods to perform database backups as well as what parts of a database need backing up. After completing this module, you will be able to:

1. Perform database backups using operating system commands
2. Describe the recovery implications of closed and open database backups
3. Perform closed and open database backups
4. Identify the different types of control file backups
5. Identify the backup implications of the logging and nologging options
6. Describe backup issues associated with read-only tablespaces
7. List the data dictionary views useful for backup operations

The next lesson introduces basic database backup concepts.

Before you create an Oracle database, decide how to protect the database against potential media failures. If you do not develop a backup strategy before creating your database, then you may not be able to perform recovery if a disk failure damages the

1. datafiles,
2. online redo log files, or
3. control files.

This section describes general guidelines that can help you decide when to perform database backups and which parts of a database you should back up. Of course, the specifics of your strategy depend on the constraints under which you are operating.

The set of files needed to recover from the failure of any Oracle database file,

1. a datafile,
2. control file, or
3. online redo log

is called the redundancy set. The redundancy set contains:

1. The last backup of the control file and all the datafiles
2. All archived redo logs generated after the last backup was taken
3. A duplicate of the online redo log files generated by Oracle multiplexing, operating system mirroring, or both
4. A duplicate of the current control file generated by Oracle multiplexing, operating system mirroring, or both
5. Configuration files such as the server parameter file, tnsnames.ora, and listener.ora

The primary rule of backup and recovery is: the set of disks or other media that contain the redundancy set should be separate from the disks that contain the

1. datafiles,
2. online redo logs, and
3. control files.

This strategy ensures that the failure of a disk that contains a datafile does not also cause the loss of the backups or redo logs needed to recover the datafile. Consequently, a minimal production-level database requires at least two disk drives:

1. one to hold the files in the redundancy set and
2. one to hold the database files.

Always keep the redundancy set separate from the primary files in every way possible:

1. on separate volumes,
2. separate file systems, and
3. separate RAID devices.

These systems are reliable, but they can and do fail. Keeping the redundancy set separate ensures that you can recover from a failure without losing committed transactions. You can implement a system that follows the golden rule in several different ways. Oracle recommends following these guidelines:

1. Multiplex the online redo log files and current control file at the Oracle level, not only at the operating system or hardware level. Multiplexing at the Oracle level has the advantage that an I/O failure or lost write should only corrupt one of the copies.
2. Use operating system or hardware mirroring for at least the control file, because Oracle does not provide complete support for control file multiplexing: if one multiplexed copy of the control file fails, then the Oracle instance shuts down.
3. Use operating system or hardware mirroring for the primary datafiles if possible to avoid having to apply media recovery for simple disk failures. Keep at least one copy of the entire redundancy set, including the most recent backup on hard disk.
4. If the redundancy copy is created by splitting a local mirror, then it is not as good as a backup created through operating system or RMAN commands because it relies on the mirroring subsystem for both the primary files and redundancy set copy. The last file backup, such as the last backup to tape, is the redundancy set copy. Hence, keep archived logs needed to recover this copy.
5. If your database is stored on a RAID device, then place the redundancy set on a set of devices that is not in the same RAID device.
6. If you keep the redundancy set on tapes, then maintain at least two copies of the data because tapes can fail. Also, if you have more than one copy of the same data, then consider keeping backups from different points in time. In this way, if one backup or split mirror was done when the database was corrupted, then you have an older backup when the database was not corrupted.