Re: _allow_resetlogs_corruption question ...

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 Sun Oct 03 2004 - 18:05:29 CDT