Re: question about automatic undo management

Could well be, as it wasn't the most rigorous or vigorous test in the world, and the database wasn't stressed in the slightest.

I was hoping that the stats. exposed in v$undostat would be coming into play: it knows how much concurrency there is on the system in any 10 minute period, so if concurrency is known to be low, start sharing. When things get busy, start creating. That sort of thing.

This is the trouble, I suppose, with adopting the SQL Server paradigm: without the source code, you've no idea what it's doing (though I suppose some analysis of the recursive SQL would reveal a bit). It's a bit like the subtleties of the autoallocate extent sizing algorithm in that respect.

Regards
HJR "Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote in message news:b0ph3a$njv$1$8300dec7_at_news.demon.co.uk...
>
> I wonder if it can be affected by how busy smon is
> on other tasks when the call for a new undo segment
> occurs.
>
> --
> 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
> ____USA_(CA, TX)_August
>
>
> The Co-operative Oracle Users' FAQ
> http://www.jlcomp.demon.co.uk/faq/ind_faq.html
>
>
>
>
>
> Howard J. Rogers wrote in message ...
> >Oh well, that wasn't my experience last night. 10 undo segments
> created at
> >startup, in an 8GB undo tablespace. 10 transactions each allocated to
> a
> >separate segment, The 11th transaction caused a new segment to be
> created.
> >The twelfth was shared. The 13th created a new segment; the 14th was
> shared.
> >
> >I didn't pursue it much further, but now perhaps I will.
> >
> >Regards
> >HJR
> >
>
>
>
Received on Thu Jan 23 2003 - 14:11:54 CST