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

Krish,

The file was made read-only on the live database in April 2007 and has been through at least one resetlogs since: when the database was duplicated. Because its read-only, the datafile won't have changed in that time so, in effect, it is from another database. From Oracle's point-off-view, it doesn't matter whether the backup was from yesterday or from last May as long as it was after the time it was made read-only. Now the restore command is bright enough to ignore the datafile and the alter tablespace online command presumably checks the controlfile to ensure that the file is at the right SCN. The puzzle for me is why the open resetlogs command can't work this out.

Thanks for your reply
David Lord

On 18/04/2008, krish.hariharan_at_quasardb.com <krish.hariharan_at_quasardb.com> wrote:
> 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

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