RE: Error recovering a database with a read-only tablespace

I would think that is because you could have brought the tablespace read write, and then read only before another backup, and during the restore process there is no way, for Oracle, to know if the file present is the right file or an older backup/copy restored in error.

The puzzler for me relative to Metalink note 266991.1, and this case, is that, the metalink note talks about recovering through resetlogs for read only tablespaces (for the same dbid). But in this case the error on file 13 was about a dbid mismatch. I wonder how Oracle allowed it to be plugged in using the same mechanism without going through a tablespace transport (as outlined in note 433569.1) - or perhaps I missed part of the restore activity.

-Krish

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of David Lord
Sent: Friday, April 18, 2008 2:17 PM
To: Finn Jorgensen
Cc: Niall Litchfield; oracle-l
Subject: Re: Error recovering a database with a read-only tablespace

Finn,

Yes, it does look like the resetlogs didn't update the datafile header - which I guess makes sense since the file could easily be on read-only media. I'm not sure why on earth the open resetlogs command can't work out that the file is read-only and just ignore it though.

Thanks for your reply.
David Lord

On 18/04/2008, Finn Jorgensen <finn.oracledba_at_gmail.com> wrote:
> David,
>
> Is it possible that after the duplicate that tablespace was still in
> READONLY mode and then a "nid" was issued for the database (I believe RMAN
> duplicate does that by derfault)? If so that tablespace would not have had
> its header updated. I suppose any subsequent backup's/restores would then
> experience the problem you're seeing.
>
> Finn

--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l