Re: Incomplete Recovery

I suspect the usual file 1 reference is simply because it's the first file in the list. Ever done a select * from v$recover_file when you get the message?

If you ask me, I reckon the problem is in doing a shutdown abort. ALL the documentation for incomplete recoveries (indeed, for any recovery) insists on an immediate at the very least. An abort leaves the Controlfile in an inconsistent state... and guess which file isn't restored when performing incomplete recoveries??

Regards
HJR "Jim Gregory" <JG200024_at_NCR.com> wrote in message news:3a6f1320$1_at_rpc1284.daytonoh.ncr.com...
> Syband,
> I've had this error numerous times on a restore/roll forward. It appears
> that unless you roll forward to an SCN or a point in time, not just until
 a
> cancel, The data dictionary ( thus the usual file 1 reference ) can
> sometimes be in an inconsistent state with the rest of the DD transaction
 in
> the next archive or possibly re-do file ( and they may not be available )
>
> This doesn't happen often, but if you do enough restores with roll forward
> it does occur. When it does, I have to find the SCN closest to the point
 of
> problem or the point in time and then start the process over again and
 roll
> forward to those values.
>
> --
> Jim Gregory
> Principal Consultant for Keane, Inc.
> Currently assigned to NCR
> "Opinions are my own and do not reflect
> those of Keane or my clients"
> <sybrandb_at_my-deja.com> wrote in message
 news:94m6u4$lq8$1_at_nnrp1.deja.com...
> > In article <3a6e83f5_at_news.iprimus.com.au>,
> > "Howard J. Rogers" <howardjr_at_www.com> wrote:
> > >
> > > Yes, well... best to learn about what's involved in an incomplete
 recovery,
> > > I suspect. For starters, you need to restore ALL datafiles from a
 backup
> > > taken before your test -but most definitely NOT the Controlfiles or
 Online
> > > Redo Logs. The entire database is then rolled forward to a given
 time, or
> > > until it's cancelled, or until a given SCN. Then you can do an open
> > > resetlogs.
> > >
> > > The commonest error encountered when performing incomplete recoveries
 is
> > > something along the lines of "Media recovery complete, but attempt to
 open
> > > with a restlogs will generate the error 'File 1 needs more recovery
 to be
> > > consistent'.... and every time, it's because the person doing the
 recovery
> > > has only restored the datafile they thought was relevant, not all DBFs
> > > without exception.
> > >
> > > Regards
> > > HJR
> > >
> > > <si_bendovi_at_hotmail.com> wrote in message
> > > news:3A6E69A6.14DEA570_at_hotmail.com...
> > > > I am trying to have database running in backup mode to be
> > > > able to 'rollback' all transactions after backup mode was
> > > > started. Goal is to be able to put database to the same
> > > > state as it was before certain test. But I could not make
> > > > recovery done without complaining that system tablespace
> > > > needs more recovery. I am putting all tablespaces into
> > > > backup mode, running my tests and after that doing 'shutdown
> > > > abort'.
> > > >
> > > > recover until change (last change from v$backup);
> > > >
> > > > finish with warning, that system tablespace needs more
> > > > recovery. I could not figure out what it means more :-). Any
> > > > idea? Of course 'alter database open resetlogs' fails.
> > > >
> > > > Stan
> > > >
> > >
> > >
> >
> > Just ran into this one yesterday. Definitely DID restore *ALL*
> > datafiles, yet ran into the error above.
> > No logical explanation. Managed to get around it (error moved to the
> > rollback tablespace), files seemed to have change timestamps (original
> > 'backup' was made with cp (without switches) controlfiles copied last.
> > Is there any explanation for this.
> > Also can only shutdown this instance (8.1.5.0.0 on solaris ) by using
> > abort. There seems to be an application process which is constantly
> > polling the database, and thus creating havoc.
> >
> > Regards,
> >
> >
> > --
> > Sybrand Bakker, Oracle DBA
> >
> > All standard disclaimers apply
> > ------------------------------------------------------------------------
> >
> >
> > Sent via Deja.com
> > http://www.deja.com/
>
>
Received on Wed Jan 24 2001 - 14:07:22 CST