Re: optimal size for rollback

"Karen Abgarian" <abvk_at_ureach.com> wrote in message news:3D8AA7C2.D0013322_at_ureach.com...
> Sorry for breaking into the conversation. I cannot read the thread up
> because some articles expired. Do you folks remember what you started
with
> anyway?
>
>
> "Howard J. Rogers" wrote:
>
> >
> > Any tool that encourages its own misuse is probably intrinsically bad.
>
> Right: for example, an Oracle database server :)
>
>
> >
> > 5 is not 58. You can manage 5 full-time, and properly. 10, even. More
than
> > that, some databases usually turn out to be rather more important to
manage
> > right than others.
>
> This is theory, not practice. The number of databases a DBA can manage
depends
> on how much work these databases require. I have seen 10 DBAs manage a
> single database and 2 DBAs managing a hundred.
>

Ah, the dangers of snipping. Since you prefaced your own reply with the line:

> "Howard J. Rogers" wrote:

...then be aware that I didn't write the above.

> >
> > You can tune the number of transactions per rollback segment to your
heart's
> > content, and arrive at a "perfect" ratio. And you'll *still* have
trouble
> > when one transaction out of thousands gets left uncommitted.
>
> I am not sure this is an administration problem. I hardly see a scenario
in
> which
> a properly designed application would leave an uncommitted transaction for
an
> unlimited time. If you spot such a thing, you can have your developers
take
> care
> of it, or the vendor, and if you ARE a developer, then take care of it
yourself.
>

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.

>
> >
> > The cost of unexpected shrinkage is that performance suffers.
> >
> >
>
> 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.

>The effects should decrease with the
> number
> of extents in your rollback segment. If there is too many there is always
a
> question
> whether they were sized correctly. There should be no impact if the
tablespace
> hosting your rollback segments is an LMT.
>

This is complete horse-manure too. 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.

HJR
> Regs
>
>
Received on Fri Sep 20 2002 - 02:02:30 CDT