Re: rman online backup with exclude undo tablespace

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_at_att.com> 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_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *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_at_rsiz.com> 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_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *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
>
>
>

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