Introduction to Physical Backups With and Without Archiving
Oracle Backup Strategies
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
- online redo log files, or
- 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.
Main Rule of Backup and Recovery
The set of files needed to recover from the failure of any Oracle database file,
- a datafile,
- control file, or
- online redo log
is called the redundancy set
. The redundancy set contains:
- The last backup of the control file and all the datafiles
- All archived redo logs generated after the last backup was taken
- A duplicate of the online redo log files generated by Oracle multiplexing, operating system mirroring, or both
- A duplicate of the current control file generated by Oracle multiplexing, operating system mirroring, or both
- 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
- online redo logs, and
- 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
- one to hold the files in the redundancy set and
- one to hold the database files.
Separate Redundancy Set from the Primary Files
Always keep the redundancy set
separate from the primary files in every way possible:
- on separate volumes,
- separate file systems, and
- 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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.