Yes, I did the same thing to avoid the hassle :)
On 6/15/07, fmhabash <fmhabash_at_gmail.com> wrote:
>
> Li Li wrote:
> > Just want to give you all an update in case you run into the same
> > problem. The problem here is the database was created by RMAN
> > duplicate, so the dbid for the read only files are still the original
> > dbid.
> >
> > On 6/13/07, *Li Li* <litanli_at_gmail.com <mailto:litanli_at_gmail.com>>
> wrote:
> >
> > Hi, List,
> >
> > I am testing a disaster recovery senario. RMAN backup was done
> > with no catalog. Below are what I did:
> >
> > 1. startup nomount
> > 2. restore spfile from xxx
> > 3. shutdown
> > 4. startup (this time it picks up the restored spfile)
> > 5. restore controlfile from xxx
> > 6. alter database mount
> > 7. restore database check readonly (I have 2 read only tablespaces)
> > 8. recover database until logseq 5 (log seq 4 was the last
> > archivelog backed up by rman)
> >
> > everything worked fine until step 8, I got an error on step 8
> > until follows:
> >
> > ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get
> > error below
> > ORA-01122: database file 9 failed verification check
> > ORA-01110: data file 9: 'H:\xxx\xxx\xxx.dbf'
> > ORA-01206: file is not part of this database - wrong database id
> >
> > file 9 is one of the READ ONLY tablespaces.
> > Any comment on what's wrong in here?
> >
> > TIA,
> > -Li
> >
> >
> >
> >
> Yes, this is the intended behavior. As you know, you can take a RO
> tablespace across resetlogs but not across a duplicate. I came across
> this scenario as you did and the options are you either imp/exp the
> tablespace or use transportable tablespace option. To avoid this hassle,
> I now check the target DB looking for RO tablespaces and change them to
> RW (check to see if you can do that). I then backup them up, then do my
> cloning. This way I do not have to worry about this issue.
>
>
>
--
http://www.freelists.org/webpage/oracle-l
Received on Fri Jun 15 2007 - 13:11:42 CDT
