Re: Error recovering a database with a read-only tablespace
- From: "David Lord" <dlordster@xxxxxxxxx>
- To: krish.hariharan@xxxxxxxxxxxx
- Date: Sat, 19 Apr 2008 07:46:19 +0100
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@xxxxxxxxxxxx
<krish.hariharan@xxxxxxxxxxxx> 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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
