Databases Reference
In-Depth Information
Create Powerful Backup Strategies
The strength of your backup strategy determines the strength of your recovery strategy. No backups, no recovery! Your
backup strategies are derived entirely from your recovery strategies. Ideally, you must plan your recovery strategy
based on the potential types of database failures you might encounter. The more types of database failures you want
to guard against, the more complex your backup strategy will be.
Schedule Regular Backups
Schedule your backups on a regular basis, thus reducing your exposure to media failures. You, of course, can recover
any database from a backup made at any remote time in the past, provided you have all the archived redo logs
from that point forward. But can you imagine applying all those archived redo logs to the backups and suffering a
horrendous downtime?
Create Regular Backups of the Control File
Back up a database's control file after any structural change to your database, such as creating a new tablespace or
adding or renaming a data file or an online redo log member. The best way to do this is to issue the RMAN command
configure controlfile autobackup on
. By default, the automatic backup of the control file is turned off. By turning
control file autobackups on, you make sure that at the end of every RMAN
backup
command, RMAN automatically
backs up the control file. When you make some changes via SQL*Plus, even though you're outside the purview of
RMAN, the control file is automatically backed up, if you set the control file autobackup feature on. Using the control
file autobackup, you can restore RMAN's backup and recovery information (called RMAN's
repository
) when you lose
all your control files and aren't using the optional recovery catalog.
Run the Database in Archivelog Mode
To be able to restore a database completely (that is, bring it up-to-date with all the changes ever made to that
database), you must run the database in archivelog mode. Only development and test databases where data loss isn't
an issue should be run in noarchivelog mode.
Multiplex the Control File
Since the control file is absolutely necessary during a recovery, use the following guidelines to safeguard the control file:
•
Keep the Oracle-recommended three copies of the control file.
•
Put each copy of the control file on a separate disk.
•
Place at least one of the three copies on a separate disk controller.
Multiplex the Redo Log Groups
If you lose your online redo logs, you may not be able to recover all committed changes to your database following a
media failure and subsequent recovery. You must always duplex the online redo logs, using the following guidelines:
•
Have a minimum of two members in each redo log group.
•
Place each member on a separate disk drive.
•
Place each redo log member on a separate disk controller.
