Re: disaster recovery

From: Frank van Bortel <>
Date: Fri, 16 May 2008 09:52:41 +0200
Message-ID: <cf3b2$482d3d49$524b5c40$>

Ben wrote:

> On May 15, 2:31 pm, joel garry <> wrote:

>> On May 15, 10:14 am, Ben <> wrote:
>>> EE aix5l 64bit
>>> I guess I'll just reference my post that was somehow moved.
>>> I was wondering about the statement of better to use a current
>>> controlfile rather than one that I recovered. Why is it better?
>>> I believe I'm going to have to do a pitr, so why not just use the
>>> controlfile and spfile that was included in the hotbackup that I'm
>>> going to be using for recovery?
>> I think it's just easier to let Oracle do if possible, but if you are
>> PITR then do what you need to. As always, it depends. A lot of calls
>> for help here indicate people are unclear on when to use which syntax
>> (like using backup controlfile and such), often they will make it more
>> complicated than necessary and blow it. The trick is to understand
>> how Oracle compares SCN's in datafile headers and controlfiles, in
>> order to decide what recovery is needed. The bit about disk versus
>> tape - if you still have an original controlfile on disk and the
>> archived logs that the recovered data files will need, you probably
>> want to use that one, letting Oracle recover as much as it can, and
>> rollback the rest. But it depends on why you want PITR - what
>> happened that you don't want to be committed? If it is just all your
>> disks got wiped including archived logs and you need to restore to the
>> past, just do that.
>> jg
>> --
>> is bogus.
>> Maybe it's just customers who are stable enough to use remote DBA
>> support that are slow to adopt...
> The reference to disk in the original post was a typo, the only disk
> that the server can still find data on, is the root system disk. We
> may be able to get back the filesystem that included the oracle home.
> If we can, that would include our spfile and alert log from the day
> before the outage. Other than that, I don't have anything left except
> for backup pieces on tape.
> The specific timeline of events was
> Friday. full hot backup
> Sunday: power outtage to disk cabinet, server's conception of disks
> are scrambled.
> Monday: we realize that the server is up but no data.

I have to disagree with Joel on this one - *always* use the most current controlfile - it has the most up-to-date state of your database. OK - having said that:
Just restore your backups on a (different) machine. Mount, alter the locations of the tablespaces, move the datafiles around, recover (maybe until cancel, or until sunday/seconds before crash) and open.

Sounds so simple, and sometimes it is.

May the force be with you.

FvB Received on Fri May 16 2008 - 02:52:41 CDT

Original text of this message