With each round of disasters, blackouts and other site-wide failure occurrences, the concepts of backup, recovery,...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
failover and disaster recovery are taking center stage. Who could have imagined that a single power station in Canada would bring down the entire Northeastern U.S. power grid for nearly two days? Was your site protected? Could your customers get to your database or Web site? Most of us think in terms of a couple of miles away when we think of a disaster recovery site, but that would not have helped in the above case. It is a good practice to use an Oracle hot site (standby database, Data Guard, etc.) to provide a geo-mirrored site that is far away from your primary site. The hot site should be far enough away to not get caught in site disaster (power, phone/network or physical access limitations). The hot site should mirror the regular site (backup capability and bandwidth for all connections; remember you may need to operate there for a while).
Now I know there are exceptions (for example, data warehousing), but generally it is a good practice to use RMAN where applicable, such as for OLTP and small DBs; other solutions may apply for large DBs or DWH. RMAN encapsulates backup commands into RMAN syntax so that a script created on one site will most likely run on most others using RMAN.
On sites where mirroring is used, use multiple mirrors (I mean more than two). Multiple mirrors allow tools to break off the mirror for making backups, thus eliminating downtime. If possible utilize three-way mirrors, so redundancy is not lost during the backup timeframe.
Encrypt backups -- I have heard of several companies losing control of sensitive data through improper disposal of backup media containing un-encrypted Oracle database backups. If someone obtains an old backup, a simple restore operation puts your entire corporate data set at their fingertips.
I also consider it a good practice to use Oracle Real Application Clusters (RAC). RAC is provided for instance redundancy, preventing a downed box from bringing down your entire database. Combined with standby databases, RAC makes a truly high-availability setup. RAC allows for use of low-cost hardware in a redundant configuration (RAIS instead of RAID, Redundant Array of Inexpensive Servers).
It is a good practice to store a verified copy of backup tapes offsite. A copy of all backups should be sent to an offsite facility for storage. In a disaster, the entire site and the surrounding area could be inaccessible. However, you should also maintain proper backup copies onsite. This means maintain at least two backup cycles of backup tapes or other media onsite.
For databases that aren't easily rebuilt or where data volumes don't prohibit it, use archive logging. For databases that need up-to-the moment recovery, use archive logging to allow point-in-time recovery. For databases that can be rebuilt (such as a data warehouse) archive logging may not be advisable.
Return to Mike Ault's Oracle "good practices."
About the author
Mike Ault is an Oracle database specialist at Quest Software and a recognized Oracle expert with over 16 years' experience as an Oracle DBA and consultant in a variety of industries and companies. A prolific author, Mike has published over 20 Oracle-related books including Oracle Administration and Management, Oracle DBA OCP ExamCram and Oracle10g Grid and RAC. He is a regular contributor to trade publications including Oracle magazine, and frequently presents at major Oracle conferences such as IOUG.