Re: rman online backup with exclude undo tablespace

From: Prasad <>
Date: Fri, 18 Jan 2008 10:09:19 -0800
Message-ID: <>

we are trying to build a test system and we took the rman online backup using exclude undo tablespace as the undo tablespace is very big (16G) and transferring between production and test network is very slow .

I am trying to force start the db so that I can do a expdp and recreate the db however I am facing difficulty while setting the _corrupted_rollback_segments

Is there a limitation on the length for setting the _CORRUPTED_ROLLBACK_SEGMENTS This below works


_SYSSMU25$, _SYSSMU26$,_SYSSMU27$, _SYSSMU28$, _SYSSMU 29$, _SYSSMU3$,_SYSSMU30$, _SYSSMU31$, _SYSSMU32$, _SYSSMU33$,_SYSSMU34$, _SYSSMU35$, _SYSSMU36$, _SYSSMU37$,_SYSSMU38$, _SYSSMU39$, _SYSSMU4$ , _SYSSMU40$,_SYSSMU41$, _SYSSMU42$, _SYSSMU43$, _SYSSMU44$,_SYSSMU45$,_SYSSMU46$,_SYSSMU5$,_SYSSMU8$) but when I try to add the below rest of the undo segment _SYSSMU46$, _SYSSMU5$, _SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$ it do not show me in show parameters.

any way to deal with this?


On Jan 18, 2008 8:50 AM, Mark W. Farnham <> wrote:

> Someone else has already mentioned ways to attempt to salvage data, but
> it seems you're not broken in production from what you've written. If you
> have an old enough copy of this file around and the intervening archived
> redo logs, you should be able to recover.
> Likewise, you can just take a new backup properly including the undo. If
> you're in a hurry to get the test system running, recovery of the file seems
> reasonable, but it is well worth your time to create and practice a working
> "disaster recovery scenario" without having to apply spit and bailing wire
> at the end of the process. Circa 1988 great care was required to get Oracle
> recovery "just right." For at least a decade is has been quite routine and
> the only complexity is figuring out which modes of recovery best fit your
> hardware, environment(s), and your requirements.
> I'm curious where you got the idea that you did not need the undo
> tablespace. If is was merely lack of understanding of recovery (restarts
> except for carefully constrained normal shutdowns routinely require some
> rollback after the redo is applied to account for transactions in flight
> that had database blocks flushed prior to the commit), that is one thing,
> but if someone is giving this as advice in developing a recovery or cloning
> protocol we need to debunk the notion. It would not be the first time
> anti-Oracle forces have spread pernicious rumors about how Oracle operates,
> and it would also not be the first time someone just plain wrong was giving
> out advice.
> Regards,
> mwf
> ------------------------------
> *From:* [mailto:
>] *On Behalf Of *Prasad
> *Sent:* Friday, January 18, 2008 9:39 AM
> *To:* oracle-l
> *Subject:* rman online backup with exclude undo tablespace
> All,
> we had a online backup taken on a 10gr2 production db on solaris with
> configure exclude undo tablespace . we are trying to do a disaster recovery
> scenario to build a test system.
> However we are getting into this scenario.
> ORA-00704: bootstrap process failure
> ORA-00604: error occurred at recursive SQL level 2
> ORA-00376: file 2 cannot be read at this time
> ORA-01110: data file 2: '/datastore/sfods03/undotbs01.dbf'
> Thu Jan 17 20:14:19 2008
> Error 704 happened during db open, shutting down database
> USER: terminating instance due to error 704
> Instance terminated by USER, pid = 21434
> Is it recoverable?
> -Prasad

Received on Fri Jan 18 2008 - 12:09:19 CST

Original text of this message