Re: disaster recovery

From: Ben <benalvey_at_yahoo.com>
Date: Mon, 19 May 2008 05:37:19 -0700 (PDT)
Message-ID: <58c7e356-afd0-48e0-92f4-2903612c60c4@e53g2000hsa.googlegroups.com>


On May 16, 4:02 pm, Ben <benal..._at_yahoo.com> wrote:
> On May 16, 11:06 am, Ben <benal..._at_yahoo.com> wrote:
>
>
>
>
>
> > On May 16, 3:52 am, Frank van Bortel <frank.van.bor..._at_gmail.com>
> > wrote:
>
> > > Ben wrote:
> > > > On May 15, 2:31 pm, joel garry <joel-ga..._at_home.com> wrote:
> > > >> On May 15, 10:14 am, Ben <benal..._at_yahoo.com> wrote:
>
> > > >>> 10.2.0.2 EE aix5l 64bit
> > > >>> I guess I'll just reference my post that was somehow moved.
> > > >>>http://tinyurl.com/5zej6a
> > > >>> 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
> > > >> --
> > > >> @home.com is bogus.
> > > >> Maybe it's just customers who are stable enough to use remote DBA
> > > >> support that are slow to adopt...http://www.computerworlduk.com/technology/business-intelligence/datab...
>
> > > > 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- Hide quoted text -
>
> > > - Show quoted text -
>
> > for the backup process we do a
>
> > backup database
>
> > when restoring the spfile if I tell it to
>
> > restore spfile from autobackup;
>
> > will it find that backup that was included from the hotbackup?- Hide quoted text -
>
> > - Show quoted text -
>
> This is getting aggravating, I've tried almost all options other than
> pl/sql route.
>
> Here is how our backup was taken:
>
> 56> connect catalog *
> 57>
> 58> connect target *
> 59>
> 60> run {
> 61> # Hot database level 0 whole backup
> 62> allocate channel t1 type 'SBT_TAPE';
> 63> allocate channel t2 type 'SBT_TAPE';
> 64> backup
> 65>   incremental level 0
> 66>   skip inaccessible
> 67>   tag jde_hot_level0
> 68>   filesperset 10
> 69>   # recommended format
> 70>   format 'bk_%s_%p_%T'
> 71>     (database);
> 72> }
>
> now that we've lost the catalog, spfile, controlfiles, and everything
> else. Is there a way to get the controlfile and spfile out of that
> backup?
>
> It seems to me that rman can't extract the spfile from tape unless
> you've set controlfile autobackup on. Is there a way for rman to do
> this?- Hide quoted text -
>
> - Show quoted text -

just an fyi, it turned out that our sys admin had in-activated the policy that had our development client in it, that was causing an issue. And there might have been a hostnames file changed on the mml server since we tested it out that was causing a problem. And there are still issues with the veritas server that we have to work out. It is actually attempting to restore now though. Received on Mon May 19 2008 - 07:37:19 CDT

Original text of this message