Re: disaster recover from RMAN backup

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. 


--
http://www.freelists.org/webpage/oracle-l

Other related posts: