Re: question about automatic undo management

I would put the percentage of systems where it won't cause any observed performance problems much higher - somewhere in the 90's probably. Replacing an 'effectively untuned' rollback space with an 'effectively untunable' undo space shouldn't do anything for anyone - but there might be a demand for more space when the change is introduced.

I think you are over-rating flashback. Bear in mind the undulate my data' is restricted to a five minute granularity, even if you quote the exact SCN (not that the typical end-user tends to check the SCN before starting a transaction ;). As a very specialised tool for the extremely careful DBA, I can see it that it could be used as a replacement for a recovery. But then we have to move to a different area of argument - we ALWAYS have to trade between performance, recovery and cost. If you want to argue for UNDO because it reduces recovery time despite impacting performance, that's not the same as arguing UNDO because it avoids 1555 and is easier to administer.

By the way - 1555's aren't necessarily a performance problem. It's perfectly reasonable to ask an end-user questions like:

    Should report X be run in the afternoon, or do you     want to stuff the system all morning long so that     you can have it at lunch-time.
If they tell you they want to stuff the system, you get it in writing and fax it to everyone that complains. If they say the afternoon is okay, then it's fine for them to get a 1555 if they try to sneak it into the queue at 9:30.

Good point about the reduction in UNDO I/O being 30% - the perceived impact on the system was that throughput was doubled. (Counterintuitive perhaps, but that's queueing theory for you when the system is close to the stress point). In fact, given that the doubling of throughput generated twice the UNDO - which didn't get written to disk, the saving on I/O due to the reduction in the UNDO size was actually double the apparent saving.

Please note - this message has been tuned to maximise the OCR; an effectively meaningless metric in this environment. Any rationale metric would be designed to measure reader comprehension time.

--
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 ...


>"Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote in message

news:<b0lomg$3ph$1$8302bc10_at_news.demon.co.uk>...


>> The most important point to make is that I think

>> that many systems won't notice the difference

>> between manual and automatic undo.

>

>Agreed. But there are always going to be the exceptions, as you point

>out, and then not being in configuration control is definitely going

>to be a problem, absolutely. Can we say that about 75% of databases

>should have no problem with automatic undo?

>

>>