Re: question about automatic undo management

"Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote in message news:b0kdrf$1cc$1$8300dec7_at_news.demon.co.uk...
>
> I did notice the smiley - on the other hand
> I advise people without OCP to put a comment
> like: "I do not consider OCP to be a relevant
> qualification" on their CVs (resumes) so that the
> automatic scanner looking for "OCP" passes it.
> Proximity is proof to many people in this trade -
> whether or not the word NOT intervenes.

OK, but the sense of the sentence was "you do not need a brain the size of the planet to work this out". I thought of you (it could have been Steve) as the arch representative of brains the size of a planet. You could take that as a compliment. That's all. I did indeed think of writing "you don't need the sense of humour of the Marx brothers". But then I realised that most people find the Marx brothers deeply unfunny, and humour has nothing to do with sizing your undo tablespace in any case.

 > Two problems with smon - first it doesn't seem to
> clear up all the mess when it should

So that's a bug then. I never advise on the basis of bugs. Next version, or next patchset, they'll be sorted.

>, sometimes
> leaving stuff around for the second or third pass.
> Secondly, why run inefficiently for 12 hours when
> you don't need to ?

because (1) you'll have to explain why large rollback segments imply more I/O than small ones. I know that's your seminar material, so feel free to not respond, but Steve has stuff on his site which says, basically, and simplifying woefully, 'who cares about the size of rollback segments'. And for the life of me I can't think of any mechanics that require large rollback segments to induce more I/O than small... or shall we say 'optimal'.... ones.

And (2) the whole idea of automatic undo is that you don't have to worry about things. Oracle sorts it for you. If your recommendation is 'don't use automatic undo', then that's something worth listening to. But if your recommendation is 'use it, but be prepared to fiddle', then I have qualms about that.

I suspect we are going to go off into a deep, dark hole at this point. Because as far as I can make out, flashback *requires* you to hold on to whatever undo you think is useful. Now you're saying that doing so (which means bigger-than-strictly-required segments) is an I/O nightmare. Maybe. But then it's a question of a very useful feature versus (questionable) performance impacts. (questionable only because I haven't seen your seminar). In the great scheme of things, I can't believe that an undo segment of 200MB instead of 20MB is going to induce a 10x performance drop. Yet it makes flashback 10x more useful. So I know which side I would prefer to bat on.

Without giving away your seminar secrets, this whole issue comes down (I think) to 'do big rollback segments cause unnecessary I/O'. And, of so, how much.

I'm all ears.

Regards
HJR Received on Tue Jan 21 2003 - 17:28:21 CST