Yes, I did the same thing to avoid the hassle :) On 6/15/07, fmhabash <fmhabash@xxxxxxxxx> 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@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.