Re: disaster recover from RMAN backup

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.

Other related posts: