Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Stragne Recovery problem

RE: Stragne Recovery problem

From: Rich Holland [oramail] <oramail_at_guidancetech.com>
Date: Mon, 17 Jul 2006 09:53:11 -0400
Message-ID: <016a01c6a9a8$57d56300$f4b90d46@CABLOE21441>


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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Hemant K Chitale
Sent: Monday, July 17, 2006 9:35 AM
To: oramail_at_guidancetech.com; oracle-l_at_freelists.org 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 :

  1. Your restoration command is not restoring the files that you think it is restoring.
  2. Your backup command is not backing-up the files that you think it is backing-up.
  3. 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
Received on Mon Jul 17 2006 - 08:53:11 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US