It ensures that there will always be an on-line duplicate (hot backup) of the database and also helps avoid a CLI (Career Limiting Incident) !!.
A disaster recovery plan consists of preparing for unlikely events, but depending on what part of the world you are, this could be more than likely. Some of them might be:
It is recommended that you make a Disaster Recovery Plan that contemplates the previously mentioned contigencies you might encounter. The recovery plan should at a minimum consider Data, Equipment, Personnel and Facilities . If you are knowledgeable in spanish: "Backups" might be of interest to you.
The Oracle backup and recovery functionality relies on many components of the Oracle server architecture, including memory strcuture, background processes, and the physical database structure. (The following objectives pretty much cover these features)
The two main configurations for running a database are ARCHIVELOG and NOARCHIVELOG. Assuming a recovery operation is needed the following scenarios could arise:
If the database is in ARCHIVELOG there are two possibilities:
If the database is in NOARCHIVELOG:
You benefit from not having to save all the on-line redo log files, on heavily accesed systems this type of configuration alleviates disk-space usage,because in ARCHIVELOG every on-line redo log file is eventually backed-up; these archived redo-log files can easily fill up a WHOLE disk (10-12 GB) in a matter of hours. However the disadvantage of running this configuration is that in the event of a failure your only means of backup is by your last backup tape, Oracle cannot help in this case because it does not have a history of previous redo-log files , the ones that are ARCHIVED in ARCHIVELOG mode.
Testing the backup and recovery plan ensures: