My mistake -- the datafiles were from an SCN in the past except one --
I know what I did wrong now. Thanks.
"Howard J. Rogers" <howardjr_at_dizwell.com> wrote in message news:<4161d7e5$0$10346$afc38c87_at_news.optusnet.com.au>...
> Domenic wrote:
>
> > Whenever I try doing a cancel based recovery using an old controlfile,
> > ie:
> >
> > recover database using backup controlfile until cancel;
>
>
> I'd be interested to know what failure caused you to combine a cancel based
> recovery (which usually means 'I've lost a piece of redo') with the use of
> an old controlfile (which usually means 'A user dropped a tablespace' or,
> possibly, 'all my controlfiles were lost').
>
> > the database complains that file 1 is not consistent, even though
> > v$datafile and v$recover_file show consistent SCNs across the board
> > after the last archive log has been fed in.
>
> You're doing an incomplete recovery. You must therefore restore ALL data
> files, not just some. Did you do that? There's no indication in your post
> that you did. If, say, file 6 wasn't restored from backup, then it is left
> at an SCN ahead of where all the other data files got rolled forward to. To
> the database, that looks like file 1 is the (first) one out of synch. Only
> you know that actually it's file 6 that is at fault.
>
> In other words, the error message about file 1 needing more recovery to be
> consistent is a complete red herring. It will *always* be reported as a
> problem with file 1, even though the consistency problem lies elsewhere.
>
> Pay no attention to the contents of v$datafile, either. Not in this scenario
> at any rate. The success of an incomplete recovery comes about because you
> know what you are doing, not because some v$ reports something or other.
>
> > Before starting recovery, I did a shutdown abort and blew away the
> > online logs.
>
> Why on Earth would you do that? Are you just practising recovery scenarios
> (in which case, OK)? Because if you blew away online redo logs, one of
> which by definition is the only store of committed transaction information,
> in a production system, I'd fire you on the spot. And I'd fire myself
> afterwards for letting you do it!
>
> > Is this error because it thinks there may be uncommitted
> > changes in the datafiles that need to be reversed by scanning the last
> > online log?
>
> This has nothing to do with it. Of course your data files will contain
> uncommitted changes. But those will be rolled back when the database opens.
> Of course, too, the online redo logs you deleted contain redo for pending
> transactions. But a pending transaction that gets interrupted half-way
> through gets rolled back. Recovery will therefore deal with those once you
> get the database opened.
>
>
> > Of course _allow_resetlogs_corruption does the trick, but I was
> > wondering if my understanding of this is right or wrong.
>
> I believe your understanding is incorrect, but it's difficult for me to tell
> without seeing exactly what you are doing to your database, and why.
>
> If you've lost your control files, and restore one from a binary backup then
> 'recover database using backup controlfile until cancel', immediately
> followed by 'cancel' will do the trick.
>
> If you've lost your online redo logs, then a restore of all data files (not
> control files), a 'recover database until cancel', and a cancel when the
> first missing log is prompted for will do the trick.
>
> If you've lost your control files AND your online redo logs, then a restore
> of all data files, and a binary backup of the control file, followed by a
> 'recover database using backup controlfile until cancel', and the typing of
> the word 'cancel' when the first missing redo log is prompted for, will do
> the trick.
>
> You only need 'allow resetlogs corruption' when your redo logs are known to
> contain corrupted redo change vectors.
>
> Regards
> HJR
>
>
> >
> > Thanks in advance!
> >
> > Domenic.
Received on Tue Oct 05 2004 - 09:29:24 CDT
