I know we're backing up & restoring what we think we are -- we took a full
image of the system (think "shutdown database, Ghost the system.").
Then a week later we took the "as of right now" control file & online redo
from the existing production system and copied them over to the target
system (which had been opened already). We were thinking this would let us
recover through the last week or so of redo, to get to the "current" state
of the production system.
As Riyaj Shamsudeen pointed out, once the database has been opened on the
target system in read/write mode, the two part ways. I'm just trying to
find out the internals of why that's so, because I can't come up with a
logical reason in my mind for doing that.
We copy the entire database from host A to host B and open it on B.
Everything is consistent and the current log sequence number is 8355. We
shut down. Wait a week. Re-copy the control files & online redo from host
A to host B. The log sequence number associated with that set of control
files is 8400 say. Since they're the same database and we've recovered the
control files from a point in time later than the data files, why wouldn't
we be able to startup mount & recover database to the 8400 log sequence?
What we saw was that 8355 was applied, then the current number was set to
8400 and everything was marked consistent... Even if it won't let me apply
the redo, I don't think it should be marking the database consistent and
letting me open it -- the data files are consistent as of a point in time 2
weeks ago, but the control files are from today. That doesn't make sense.
Thanks,
Rich Holland
Guidance Technologies, Inc.
Cell: 913-645-1950
-----Original Message-----
From: oracle-l-bounce@(protected)]
On Behalf Of Hemant K Chitale
Sent: Monday, July 17, 2006 9:35 AM
To: oramail@(protected)
Subject: Re: Stragne Recovery problem
I would think that the controlfile that the STARTUP MOUNT and RECOVER
commands are reading is _*not*_ the "current" (ie this, now,
point-in-time)
file.
eg when you said you restored the controlfile and online logs and
the recovery applied only archive 8555, that would mean that the
controlfile
that you "restored" is as of the 8555 point in time.
Possibilities :
a. Your restoration command is not restoring the files that you think
it is restoring.
b. Your backup command is not backing-up the files that you think
it is backing-up.
c. The init.ora of the database instance is referencing a _different_
controlfile,
already present on disk, other than the one you are restoring.
To verify you could just do a STARTUP MOUNT and __before__ attempting
a RECOVER, query the controlfiles -- eg query V$LOG and see what the
controlfile thinks is the current Log Sequence Number.
Hemant
At 09:17 PM Monday, Rich Holland [oramail] wrote:
><snip>
>
>We then logged on to the new system, did a 'startup mount' and a 'recover
>database' and the system recovered from the first archive log and then said
>media recovery was complete - it skipped the other 40-50 logs we'd copied
>over. We're able to open the database (it's marked consistent), but it
>didn't roll through the last 2 weeks worth of archived redo, so I know it
>can't be right (we have logs 8555 - 8598 to play back, and it only used
>8555).
>
>--
>http://www.freelists.org/webpage/oracle-l
Hemant K Chitale
http://web.singnet.com.sg/~hkchital
--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l
