Re: Missing archive logs from middle of level 0 backup - can _allow_resetlogs_corruption help?
- From: Andrey Kriushin <Andrey.Kriushin@xxxxxxxx>
- To: Jay.Miller@xxxxxxxxxxxxxxxx
- Date: Sun, 09 Sep 2007 07:38:34 +0400
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@xxxxxxxxxxxxxxxx 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
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
