Re: Error recovering a database with a read-only tablespace
Date: Wed, 16 Apr 2008 11:39:21 -0500
Message-ID: <203315c10804160939g789e0115tb3a9e479d03a4ab5@mail.gmail.com>
Hi David
I am really not sure what you are trying to do. Can you please clarify? If the tablespaces are in read only state at time of recovery, then they don't participate in recovery. rman recover database command takes care of that. I don't think 'check readonly' option is quite applicable here. In sqlplus, you could make those datafiles associated with read only tablespaces offline [ or offline drop, don't remember which one ] and recover the database, open resetlogs. Then you could just make read only tablespace onlline.
Cheers
Riyaj Shamsudeen
The Pythian Group
www.pythian.com
On Wed, Apr 16, 2008 at 10:54 AM, David Lord <dlordster_at_gmail.com> wrote:
> All,
>
> I'm running into a problem trying to recover a 9.2.0.8 test database
> with a read only tablespace ASSETS_21 from an RMAN backup.
>
> The restore runs fine and appears to restore the ASSETS_21.dbf
> datafile (number 13 for the superstitious amongst you):
>
> RMAN> restore database check readonly force;
> ...
> restoring datafile 00013 to /data/oradata/ESDCWTST/ASSETS_21.dbf
> ...
> Finished restore at 16-APR-08
>
> But when I do the recovery, I get the following error:
>
> RMAN> recover database check readonly;
> ...
> could not read file header for datafile 13 error reason 9
> ...
> RMAN-03002: failure of recover command at 04/16/2008 16:02:16
> RMAN-06094: datafile 1 must be restored
>
> And when I try it from sqlplus I get:
>
> SQL> recover database until cancel using backup controlfile;
> ORA-00283: recovery session canceled due to errors
> ORA-01110: data file 13: '/data/oradata/ESDCWTST/ASSETS_21.dbf'
> ORA-01122: database file 13 failed verification check
> ORA-01110: data file 13: '/data/oradata/ESDCWTST/ASSETS_21.dbf'
> ORA-01206: file is not part of this database - wrong database id
>
> Has anybody come across this before, or know what to do? I'm probably
> going to end up cloning a new copy from the live database, but it
> would be nice to know what the problem was.
>
> Regards
> David Lord
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Apr 16 2008 - 11:39:21 CDT