Message-ID: <46E36ABA.3070804@rdtex.ru>
Date: Sun, 09 Sep 2007 07:38:34 +0400
From: Andrey Kriushin <Andrey.Kriushin@rdtex.ru>
Organization: RDTEX J.S.C.
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Jay.Miller@tdameritrade.com
Cc: oracle-l@freelists.org
Subject: Re: Missing archive logs from middle of level 0 backup - can _allow_resetlogs_corruption
 help?
References: <46DD7C44.83D7.0016.0@controller.state.nv.us> <716f7a630709051235y6c0656b5ra2741ca4afa32e15@mail.gmail.com> <46E19DCE.5050604@gmail.com> <304CF4722010DD4FA19829D09DDB956BAC3106@prdhswsemlmb01.prod-am.ameritrade.com>
In-Reply-To: <304CF4722010DD4FA19829D09DDB956BAC3106@prdhswsemlmb01.prod-am.ameritrade.com>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
Precedence: normal
Reply-to: Andrey.Kriushin@rdtex.ru

Hi Jay,

In this particular case you have a supported way to overcome the problem.

(Assuming you are using rman), set the UNTIL SEQUENCE to the sequence 
number of the last log available +1 (or +100) and repeat
restore database;
recover database;

At the end of the "recover database" you can check the last applied log 
sequence number in the V$LOG_HISTORY.

Then you can OPEN your database RESETLOGS. That's it.

I would definitely recommend the supported way.

------------------------------
Just in case if you are curious what is going on behind the scenes:

AFAIK, when Oracle does a _*complete*_ recovery, it relies upon the fact 
that all of the logs, including the CURRENT one, are available (you are 
that person who have directly told this to the server, BTW :-)). Thus 
the server "safely" (as the author of this piece of the code thought)  
increases the SCN at least by 1 after completing the application of each 
log - this is the controlfile transaction, which fixes the fact of redo 
application. IMHO it logically corresponds to the step 3 of this 
(http://www.ixora.com.au/notes/log_switch_steps.htm) note by Steve Adams.

If the next log is unavailable, then the server is in the situation when 
the last SCN known is greater (at least by 1) than that in the headers 
of all of the RW datafiles (the headers are updated after the completion 
of  each log application). So it (the server) shows you the diagnostics 
message saying that it needs more redo in order to reach the consistent 
state.

The situation described doesn't happen, if you would order the 
_*incomplete*_ recovery (UNTIL). Which tells the server to be more 
"carefull" with the SCN after each log is applied :-).

Funny enough, but using the "_allow_resetlogs_corruption=true" seems to 
be safe in this particular case (not in most of the others). This is 
because the single redo record never crosses the redo file boundary. In 
other words, the redo record (i.e. the set of instructions for "atomic" 
change in the dependent datafile blocks, etc), is not broken somewhere 
in the middle (which is not always the case when the redo log itself is 
corrupted).

HTH
-- Andrey
PS. Sorry for repeating the stuff which might be well known to the 
majority of the list authors. Just a self-training :-) and not having a 
good link handy.

Jay.Miller@tdameritrade.com wrote:
> I'm trying to recover a table from an old level 0 backup, Unfortunately
> it looks like 2 archivelogs must have been deleted in the middle of the
> backup and are not available for restore.
>
> I've recovered up to the latest archivelog I have before the gap, but
> can't open the database.  Would setting _allow_resetlogs_corruption=true
> let me open it?  The database only needs to be open for a few hours to
> do some queries and then I'll be trashing it.
>
>
>
>  
>
>
> Jay Miller
> Sr. Oracle DBA
> 201.369.8355
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>   

--
http://www.freelists.org/webpage/oracle-l