Re: optimal size for rollback

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.

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

>
> The cost of unexpected shrinkage is that performance suffers.
>
>

I do not think that it really suffers. 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.

Regs Received on Thu Sep 19 2002 - 23:47:24 CDT