Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Question of degrees in Oracle DB recovery

Re: Question of degrees in Oracle DB recovery

From: Tim Gorman <>
Date: Tue, 29 Jun 2004 10:43:16 -0600
Message-ID: <>


One good rule of thumb is that nothing can be considered recoverable until it is copied to tape, at least once.

Regardless of where your archivelog destination is located on disk, the files that reside there should simply be considered a convenience for faster recovery and not a recoverable repository of saved transactions. In other words, if they are there, then OK -- but don't count on them being there.

The key is to get those archived redo logfiles backed up, very often and redundantly if possible.

My advice is to create (at least) two "classes" or "policies" (terminology varies between tape-management packages) of backup jobs for each Oracle database:

Backing up the archived redo logfiles is a much more urgent process than backing up datafiles, for many reasons, some of which you've touched upon. Thus, backing up those files should be a different higher-priority "job stream" separate from backing up datafiles. And, if both types of jobs are queued waiting for a tape drive, the jobs for archivelog files should "win". Datafile backups can wait -- archivelog backups should not wait.

In this fashion, you can choose how close to real-time you are able recover to. For example, at one site running Oracle Apps R11.0.3, we scheduled archivelog backups to tape every 8 mins, which includes a call to ALTER SYSTEM SWITCH LOGFILE just before starting the backup. Datafile backups are nightly. We don't remove those archivelog files from disk after they are backed up, but have a separate job which removes the oldest when the file-system gets full or when they are 3 days old, which ever happens first.

The devil is in the details, of course, but those are some important points to bear in mind.

Hope this helps...


on 6/29/04 9:59 AM, Wolfe Stephen S GS-11 6 MDSS/SGSI at wrote:

> First off, I'm an Oracle newbie for sure. My main question now is more
> DR policy/intent
> Oriented than technical. I'm still in the discovery process of all the
> ways an Oracle instance can be recovered, I'm now reading a PDF on
> online point-in-time recovery strategies and this is where I have a
> question.
> How many of you guys provide as close as possible to the
> transaction-on-the-fly point-in-time recovery?
> Currently, we do only an offline, once a day backup to a SAN on two
> Oracle applications. I was asked last Friday if we had a catastrophic
> failure (server destruction or totally non-recoverable disk failure) how
> would I recover our TPOCS database. I replied I could recover to
> whatever was there at 00:15 that day, because, with Crondsys we stop the
> database, then backup the entire Oracle directory and all of its
> subdirectories (I was told I actually only needed to keep the oradata
> folder but we have a large SAN so why not get all the stuff config file,
> etc) and an interface directory where daily interface files and archives
> are kept from a system that sends data to TPOCS via importable text
> delimited flat files.
> I received a few concerned looks because the using departments were
> under the impression that I could bring them back to just before the
> failure. I can't and the vendor that was tasked to provide the database
> application was only tasked to provide a 24 hour backup scenario. If a
> site wants anything better they have to do it on their own after
> submitting the plan and procedures to the tier 3 helpdesk (the vendor)
> for approval.
> I am doing a lot of reading right now, but I would like to get your
> ideas on the cost and complexity of getting a true PIT recovery system
> in place or can a near PIT be established like configuring the redo logs
> to reside on the SAN instead of the local server?
> v/r
> Stephen S. Wolfe, GS-11, DAFC
> Data Services Manager
> (813) 827-9972 DSN 651-9972

Please see the official ORACLE-L FAQ:

To unsubscribe send email to: put 'unsubscribe' in the subject line.
Archives are at
FAQ is at
Received on Tue Jun 29 2004 - 11:40:03 CDT

Original text of this message