Re: RMAN restore of full backup fails completely

From: joel garry <>
Date: Fri, 21 Nov 2008 14:59:13 -0800 (PST)
Message-ID: <>

On Nov 21, 9:09 am, "Andreas Zimmermann" <> wrote:
> Hi,
> after searching for a hint to solve this problem for quite some time, I
> thought I might try it here to get help - I am a RMAN novice, so please
> excuse me seeming uninformed or plain dumb, but since this is a production
> problem posting instead of reading to even more material than I already did
> and trying around more is not really an option.
> Situation:
> We have servers (DELL 2650, 6 disks, 12 GB RAM) both running CentOS 5
> (Redhat) & Oracle 10gR2. Both servers are set up the same way (and running 4
> instances each - 2 production, 1 development, 1 reporting) with one being
> the production server (the 2 production instances up & running in archivelog
> mode connected to our web application) and one the development / reporting
> server. Overnight the production data is automatically restored to the 'warm
> backup' server (via RMAN full / cumulative backups & archivelogs) to have a
> somewhat actual failover in case of emergency and for reporting. After a
> disk failure on the production server we actually had to switch over and
> everything worked fine up to that point: restored the last cumulative backup
> and recovered to the last archived log ... so far so good. Now that the
> other server has new disks and is back in business I wanted to set it up as
> 'warm backup' again but unfortunately I ran into problems that I neither
> understand nor can solve (which is a result of not understanding what's
> happening obviously). Here is what I try to do:

Unscientific wild-ass guess here: check the docs about incarnations and orphaned backups. I'm wondering if somewhere in all this you did a flashback or recovery or read-only or something that made those 4 data files strange as far as RMAN is concerned. LIST INCARNATION, v $datafile, alert log and the backup logs may provide clues.


-- is bogus.
Received on Fri Nov 21 2008 - 16:59:13 CST

Original text of this message