Hi Riyaj, Yes, it shows correctly printed in the alert log . but when I try to do show parameter it do not show . does that mean it is effective on the background? but if it is effective then when I try to open in resetlogs it should not complain about undotbs . but right now it complains. Thanks -Prasad On Jan 18, 2008 11:29 AM, Shamsudeen, Riyaj <RS2273@xxxxxxx> wrote: > So, If I understand correctly, show parameter does not show this list? > But, is it correctly printed in alert.log? > > > > This might be the limitation of show parameter, not necessarily with > parameter itself. I think, max size is 512. You might able to go up to 50 as > each entry takes 10 characters below. Also, query v$parameter directly. > > > > Thanks > > Riyaj > > > ------------------------------ > > *From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto: > oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Prasad > *Sent:* Friday, January 18, 2008 12:09 PM > *To:* Mark W. Farnham > *Cc:* oracle-l > *Subject:* 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 > > >