Re: rman online backup with exclude undo tablespace

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

_CORRUPTED_ROLLBACK_SEGMENTS = (_SYSSMU1$, _SYSSMU10$,
_SYSSMU11$,_SYSSMU12$, _SYSSMU13$, _SYSSMU14$,
_SYSSMU15$,_SYSSMU16$, _SYSSMU17$, _SYS
SMU18$, _SYSSMU19$,_SYSSMU2$,_SYSSMU20$, _SYSSMU21$, _SYSSMU22$,_SYSSMU23$,
_SYSSMU24$,
_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?

TIA
-Prasad



On Jan 18, 2008 8:50 AM, Mark W. Farnham <mwf@xxxxxxxx> 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:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
> oracle-l-bounce@xxxxxxxxxxxxx] *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?
>
> TIA
> -Prasad
>

Other related posts: