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

Date: Tue, 29 Jun 2004 11:27:16 -0500
Message-ID: <0186754BC82DD511B5C600B0D0AAC4D607B008F5@EXCHMN3>


   You are getting some excellent responses. I don't see where the following point was mentioned (forgive me if I have overlooked it)

Dennis Williams
Lifetouch, Inc.
I said it "looked" clear - Riddick

-----Original Message-----
[]On Behalf Of Daniel Fink Sent: Tuesday, June 29, 2004 11:22 AM
Subject: Re: Question of degrees in Oracle DB recovery


I would suggest (gently) that you purchase the Oracle Backup and Recovery Handbook to get the fundamentals of how Oracle performs B&R. It is a very enlightening book in many ways. The Oracle doc is not bad either and the Recovery 101 book has its good points (no offense to either author intended, I just prefer B&R Handbook). I also have a paper (started to get out of data) called "Real Life Recovery" on my website ( that might help.

All of the production/qa databases our team supports can be recovered to a point in time. Some of the development databases are able to be recovered to a PIT, others not.

I am not an expert in RMAN (here comes Tim with a big stick), so I am only going to address the fundamentals. You can implement this approach regardless of the backup software you are using.

In terms of your situation, all of the components for a PIT recovery in Oracle already exist. With the proper information, Oracle can recover to the last *committed* transaction (before a failure/shutdown). The key to this is to enable archiving and properly manage the archived redo logs.

Key point - Redo logs (online and archived) are the *MOST* important files in your database system. If you are unable to read a log during recovery (missing or corrupted), you cannot move forward. (Yes, I know there are ways around this, but they are not for the faint of heart and have serious side-effects). Keeping a copy on the SAN and another storage device (local disk for example) is not a bad idea. My rule of thumb for logs is that they are on at least 2 backup sets (tape or other offline storage) in non-compressed format and 3 more sets in compressed format. There is nothing worse than going to management and saying "We can't recover the database as the archived redo logs are corrupted." (yup, been there, done that, got the t-shirt). If you have all of the redo logs from the beginning of the database, you can (in theory, I've never tried this myself) recover the database to the point of failure without having a single backup of the datafiles.

One of the advantages to this approach is that you do not need to change your backup process at this time. If you want to eventually perform online (hot) backups, you will need to enable archiving anyway.

I hope this answers some of your questions. Feel free to ask more or request clarification...that's what we are here for.

Daniel Fink

Wolfe Stephen S GS-11 6 MDSS/SGSI 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=20
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ:
> ----------------------------------------------------------------
> To unsubscribe send email to:
> put 'unsubscribe' in the subject line.
> --
> Archives are at
> FAQ is at
> -----------------------------------------------------------------

Please see the official ORACLE-L FAQ:

To unsubscribe send email to: put 'unsubscribe' in the subject line.
Archives are at
FAQ is at
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:28:21 CDT

Original text of this message