Re: optimal size for rollback

"Karen Abgarian" <abvk_at_ureach.com> wrote in message news:3D8C16C5.A32308F8_at_ureach.com...
> >
> >
> > You must be another one working with an App. that doesn't permit data to
be
> > altered unless it automatically throws in a 'commit', huh?
> >
> > I think you're in a minority on that one. A "proper" app. should allow
the
> > user to modify data, look at it, check it, re-check it, and when they're
> > ready, click a 'save' button or something similar to issue the commit.
Any
> > app. that doesn't do that is waltzing all over the transactional model.
> >
>
> Hmm, you certainly have the point that such design is legitimate. But I
cannot
> agree that this is the only "proper" design possible. For every such
> implementation
> there should exist a way to implement this without leaving a transaction
hanging
>
> around. I think there are reasons they don't use this approach, and, by
doing
> so,
> misuse the transactional model. Reasons could be web-related issues,
locking
> issues, or mentioned rollback segment problems.
>
> I actually think that I am in the majority, whether I care about it or
not.
>
> >
> > > I do not think that it really suffers.
> >
> > I'm afraid that what you think and what actually happens are, in this
case,
> > two different things. And .. the cost of a shrink does indeed come
mainly
>
> > from the data dictionary manipulations required to give it effect. So
>
> in LMT, that cost is hugely reduced. But it's not nothing, even so.
>
>
> I would like to see some performance-related numbers or some theoretical
proof.
> Something more than just "because I say so". It is obvious that it will
have
> some
> effect when it is present and transactions will be faster when it is
absent. I
> question
> the existence of the performance hit. You are welcome to prove me wrong.
>
>
> >
> > This is complete horse-manure too.
>
> Please try to control yourself ...

The difference between us, Karen, is that when I post I'm in control enough to make sure that what I post is comprehensible. And you do not.

For example, you say "It is obvious that it will have some effect when it is present and transactions will be faster when it is absent". (I presume, incidentally, that we are talking about the existence of the "optimal" clause -only it's not entirely clear from your post what "it" actually is).

So you appear to concede that "it will have some effect".

Only in the next breath we have "I question the existence of the performance hit".

Well, you can't have it both ways. Either there's an effect, or there isn't. If there is, there's a performance hit. If there isn't an effect, then there's no performance hit, and (by logical extrapolation) Oracle's just invented a way of doing data dictionary lookups and extent allocations and deallocations for free.

Or are you saying that whilst the "effect" is there, it isn't serious enough to warrant being called a "performance hit"?? In which case, you're on your own debating such semantics.

To perform a shrink to optimal, even in LMT, requires visits to the data dictionary, and those don't come for free.

HJR
>
>
> Regs
> AK
>
>
Received on Sat Sep 21 2002 - 09:53:16 CDT