Re: question about automatic undo management

"Joel Garry" <joel-garry_at_home.com> wrote in message news:91884734.0301211649.2d029eda_at_posting.google.com...
> "Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message
news:<IegX9.29683$jM5.76837_at_newsfeeds.bigpond.com>...
> > "Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote in message
> > news:b0jcjl$igp$1$830fa78d_at_news.demon.co.uk...
> > > Diskspace may be cheap, but I/Os are not, and
> > > any strategy that results in redundant I/O is inherently
> > > suspect. Allowing undo segments to become
> > > unnecessarily large is one way of generating
> > > redundant I/O.
> > >
> >
> > But since SMON shrinks anything that it considers too large every 12
hours
> > or so, this isn't going to be an issue, is it?
>
> Sounds like the real world is bound to undo all gains from moving to
> LMT's by simply requiring too much undo for useless flashbacks.
>

Too much undo is simply a question of storage. At this stage, unless Jonathan cares to clarify. Quite what benefits of LMTs that mitigates, I can't see. LMTs eliminate possible contention on UET$/FET$ data dictionary tables when allocating or deallocating space; they eliminate the possibility of tablespace fragmentation; they make segment sizing decisions a no-brainer. Now what has an 'excess' of undo to do with any of that?

HJR
> jg
> --
> @home is bogus.
> Moore's law ensconsed in a Klein Bottle and wrapped in a Moebius
> strip.
Received on Tue Jan 21 2003 - 18:59:15 CST