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@xxxxxxxxx <mailto:litanli@xxxxxxxxx>>
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.
