They're numbers I posted as an example. There were about 250 archived redo
logs over the two week period. My reasoning was that even if we opened and
closed the copy of the database on B, once the control files were re-copied
from A to B two weeks later, the SCN in the control files would be newer
than that in the data files, so the data files would need recovery. In our
case, they recovered from the FIRST redo log file (e.g. 8355 in my example),
and then said the database was consistent, and the log sequence number was
set immediately to 8401 (I guess based on the current log sequence number of
the online redo which were copied again with the control files a couple
weeks after the initial copy...
I was surprised it (1) didn't recover through the ~250 log files and (2)
considered the database consistent and let us open it, even though it's
missing the last 2 weeks worth of data.
Thanks,
Rich
-----Original Message-----
From: Riyaj Shamsudeen [mailto:rshamsud@(protected)]
Sent: Monday, July 17, 2006 11:25 AM
To: oramail@(protected)
Cc: oracle-l@(protected)
Subject: Re: Stragne Recovery problem
Rich
When you open a database normally, control file is read and cross
verified with data file header for consistency validation. If you
replace the control file with current copy of the control file, then the
data files will lag behind the control file and media recovery is
needed. In this case, 8355-8400 must be applied. But, Oracle will apply
the changes from redo log files,without prompting for any recovery, if
the log sequence range is sufficiently contained within the redo log
files themselves.
You say, it doesn't prompt for recovery and updates the log sequence
to 8400 from 8355. Are these numbers real log sequence numbers ? or
examples that you are posting ?
Is it possible that all the activity within the past two weeks
contained within the redo log files ? Can you find the log sequence #s
generated within those two weeks and check how many redo files are in
the database ? I think, the activity in this database is very low and
/or redo log files are huge.
Thanks
Riyaj Shamsudeen
--
http://www.freelists.org/webpage/oracle-l
