--
"Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message
news:3f7a5a50$0$13656$afc38c87_at_news.optusnet.com.au...
> Burt Peltier wrote:
>
> > If all you lost were archived redo logs, you should not have had to do
> > much , I think.
> >
> > Not sure what you did first, but the correct course of action might have
> > been real simple. Of course, once you do 1 wrong command, the correct
> > command may no longer work. Good reason to do a cold backup before doing
> > any recovery.
> >
> > I once had a database crash in the middle of a hot backup. It looked
like
> > I needed to do some kind of recover.
> >
> > But, I think (been a while - doing this from poor memory) all I had to
do
> > was 'recover database' . Basically, because the datafiles were in "begin
> > backup" mode, Oracle needed the current REDO log just to "sync" things
up
> > and take the datafiles out of backup mode.
> >
>
> This disaster just continues to run and run, doesn't it?
>
> No, Burt. You didn't need to do 'recover database' at all (and if you'd
just
> lost your archive logs, it wouldn't have worked in any case). All you need
I suppose it has been a while and I could be mistaken, but ...
Assuming the hot backup did not run for a long time and all the recently
archived REDO are still intact (not over-written since being archived)
because Oracle has not yet "cycled" thru all the online REDO logs, wouldn't
the most recent REDO needed for a "recover database" in this case have been
available and so Oracle would not have had to go to look in the archived log
dest?
> to do if you crash in the middle of a hot backup is 'alter database
> datafile x end backup'. That causes the headers of the files to be
> re-synchronised, and therefore an 'alter database open' would have worked.
> Of course there might be more than one file in hot backup mode, so a quick
> check of v$backup before doing anything is always in order.
Good info ... I will try to remember this . Thanks.
>
> The tragedy of Stan's predicament is that this is *not* what he did, but
> proceeded instead to muck about with incomplete recoveries on some files,
> and not on others, followed by Lord knows what else. And as you so wisely
> put it, once you've embarked upon a failed recovery, the correct recovery
> procedures are unlikely to work when they are (eventually) tried. The
> suggestion of a cold backup before starting any recovery is an excellent
> one -though often not practical in a production 24x7 environment :-(
>
Good point. Instead of a cold backup, could you just copy the REDO logs and
control files (while the database is down) ... so you could then copy these
back to try again:
- copy REDO and control files while the database is shutdown
- ** do failed recover wrong commands **
- recover all datafiles from hot backup (assuming you have these)
- restore REDO and control files from just copied versions before 1st failed
recover
- try recover again
> And that's the particular boat Stan is now in, with offlined datafiles
that
> cannot possibly be recovered, and no chance of doing an incomplete
> recovery. Data has been lost, and the situation is unrecoverable.
>
> Regards
> HJR
>
>
Received on Wed Oct 01 2003 - 18:29:13 CDT
