"Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote in message news:<atum6m$d9o$3$8302bc10_at_news.demon.co.uk>...
> I wouldn't normally consider doing this, but
> since Richard Foote will only stick his oar
> otherwise -
>
> The undo_retention is handled by keeping
> a list of current extents with the time of the
> last commit that happened in that extent;
> the list is kept in the segment header block,
> which reduces the number of available TT
> slots. I claim this is an architectural
> difference - ta-da !
>
> BTW - do you have any indication of when
> Oracle will run multiple transactions into an
> Undo ? I haven't seen it happen yet, and the
> use of the retention map suggest that there
> is a nasty trap waiting to be engineered if
> it does.
>
>
> --
> Regards
>
> Jonathan Lewis
> http://www.jlcomp.demon.co.uk
>
> Coming soon a new one-day tutorial:
> Cost Based Optimisation
> (see http://www.jlcomp.demon.co.uk/tutorial.html )
>
> Next Seminar dates:
> (see http://www.jlcomp.demon.co.uk/seminar.html )
>
> ____England______January 21/23
>
>
> Howard J. Rogers wrote in message ...
> >
> >Someone is bound to mention 'undo retention'. That's not an
> architectural
> >change per se. It simply means that the old rule whereby the rollback
> >segment's tail pointer was updated at the moment of commit is
> modified so
> >that it is only updated when the timeout specified by undo_retention
> is
> >reached. That's an artifice of kernel code, not an architectural
> change to
> >the rollback segments themselves, however.
> >
Jonathan, are you willing to enlighten us on the trap?
Received on Fri Dec 20 2002 - 12:07:33 CST
