Call (800) 766-1884 for Oracle support & training
Free Oracle Tips


Oracle Consulting Support
Oracle Upgrades
Use New Oracle Features
Oracle Replication Support
Oracle Training
Remote Oracle DBA
System Documentation
Oracle Tips
Oracle Performance
 

Free Oracle Tips


 

HTML Text

BC Oracle tuning

Oracle training

Oracle support

Remote Oracle

 

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 (DR)

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 Florida, it is a good idea to place the disaster recovery (standby) site in a location without hurricanes. 

 

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 (SLA) will be affected by this downtime.

Physical Backups

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

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.

Oracle Consulting

  
 

Oracle performance tuning software 
 
 
 
 

Oracle performance tuning book

 

 
 
 
Oracle performance Tuning 10g reference poster
 
 
 
Oracle training in Linux commands
 
Oracle training Excel
 
Oracle training & performance tuning books
 
   

Copyright © 1996 -  2014 by Burleson. All rights reserved.

Oracle® is the registered trademark of Oracle Corporation.