Re: Question of degrees in Oracle DB recovery
- From: Tim Gorman <tim@xxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 29 Jun 2004 10:43:16 -0600
Stephen,
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:
* a class of higher priority and frequency for backups of archived
redo logfiles
* a class of lower priority for datafile backups
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...
-Tim
on 6/29/04 9:59 AM, Wolfe Stephen S GS-11 6 MDSS/SGSI at
Stephen.Wolfe@xxxxxxxxxxxxxx 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
> stephen.wolfe@xxxxxxxxxxxxxx
> (813) 827-9972 DSN 651-9972
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
