 |
 |
 |
 |
 |
|||
 |
|||
 |
|||
 |
|||
 |
|||
 |
|||
 |
|||
 |
|||
 |
|||
 |
|||
 |
|||
 |
|||
 |
|||
 |
|||
 |
|||
 |
|||
 |
|||
 |
|||
 |
|||
|
|||
 |
|||
|
|||
 |
|||
|
|||
|
|
 |
Oracle RAC Disaster Recovery (DR)Oracle Tips by Burleson Consulting |
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.
Hot Backups
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.
TIP:
Remember that in a RAC environment, even if only one instance of many is
online in OPEN mode, the database is considered to be ‘online’.
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.
Cold Backups
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 - 2011 by
Burleson Enterprises. All rights reserved.
Oracle® is the registered trademark
of Oracle Corporation.