Oracle 11g Grid & Real Application Clusters by Rampant TechPress is written by four of the top Oracle database experts (Steve Karam, Bryan Jones, Mike Ault and Madhu Tumma). The following is an excerpt from the book.
Disaster Recovery is necessary in the case of datafile or environment loss and corruption. If the centralized database files, the central storage array, or the entire server environment is lost, recovery will be necessary.
A loss of datafiles is relatively easy to recover compared to a full server environment loss. Using RMAN, a backup can be used to restore and recover missing or corrupt datafiles. If the affected tablespaces are not the SYSTEM, SYSAUX, or UNDO tablespaces, the rest of the database can even stay online while the recovery is in progress.
However, when an entire environment such as a server room
or office building is lost, as in a natural disaster, disaster recovery is
required. Disaster recovery
involves having a duplicated database environment in another location,
preferably one outside of the same range of natural disasters that could
occur at the primary site. For
instance, if the primary database cluster is in
The primary Oracle tool for disaster recovery is Data Guard; however, there are many third party options also offered to achieve a full disaster recovery implementation.
Whatever tool is used, it is important that it make
incremental updates to the standby environment as much as possible in order
to be available in the case of a failure.
It is important to calculate beforehand what the maximum allowable
downtime will be. This is
usually decided by management as a company’s service level agreements (
Physical backups are created by duplicating the actual files that comprise the database. These files include the datafiles, control files, and redo/archive logs. Additionally, the SPFILE can be considered a crucial database file.
Backups can be taken while the database is either online or offline. In order to take online backups, the database must be in hot backup mode.
When a hot backup is taken, the files in the backup are necessarily inconsistent. By themselves they are not able to fix a broken database. With archive logs, however, the backup files can be caught up allowing full recovery to the point of time of failure in the case of a crash. The database is fully available while in hot backup mode, but Oracle performs internal block activity to prevent what are known as fractured blocks.
It is also possible to take a cold backup. This is a backup that is taken when the entire database environment is offline. In the case of a RAC environment, this means that all nodes must be in an offline state such as shut down, nomount, or mount.
A cold backup does not require any archive logs in order to be immediately usable as a recovery option. The backup itself is consistent, meaning it can be restored and opened immediately. However, without archive logs it will be impossible to recover the database to the point in time at which the failure occurred. In a hot backup, archive logs are both the glue which brings the inconsistent datafiles together and the mechanism by which the database can be brought up to date. In a cold backup, archive logs are only used to bring the database up to date.
It is important to remember that a cold backup requires the entire database be offline. As such, cold backups are not necessarily popular in the RAC world, as the purpose of RAC is to maintain 24 x 7 availability.
Restore and Recover
The previous two sections on hot and cold backups made frequent use of the words restore and recover. In backup and recovery, restoring is performed when files are placed back in their proper locations by either overwriting corrupt files or replacing missing files. Recovery, on the other hand, is bringing those files up-to-date to ensure complete database consistency. This is accomplished by catching up all datafiles to the same SCN.
Logical backups involve backing up the data contained within the database, but not the physical database files. The most popular form of logical backup is performed with Oracle’s export utilities. These include the expcommand for 9i and lower compatible dumps, and the expdpcommand for the 10g datapump dumps.
If a database is in use when a logical backup is being taken, then the backup will be inconsistent. Though there are mechanisms by which an online logical dump can be created with full consistency, they are costly since they require enough UNDO to satisfy the entire time in which the logical dump occurs.
Usually a logical backup will be taken at the schema or table level to quickly dump tables to physical files in case the data is quickly needed again. This is different from a physical backup where the entire datafile or database must be recovered in order to restore a single table.
Copyright © 1996 - 2014 by Burleson. All rights reserved.
Oracle® is the registered trademark
of Oracle Corporation.