Re: Hard numbers for INITRANS and MAXTRANS

What would be a good way to know if you would benefit from increasing INITRANS on a table, is there a specific event, latch or wait one could look for?

-Ethan
http://www.freetechnicaltraining.com
http://www.gnumetrics.com

In article <3988018e.4199888_at_news-server>,   nsouto_at_nsw.bigpond.net.au.nospam (Nuno Souto) wrote:
> On Tue, 01 Aug 2000 13:59:55 GMT, vasarpota_at_my-deja.com wrote:
>
> >I understand that INITTRANS and MAXTRANS should be set object by
> >object. Ia also understand that the number are determined by the
 size
> >of the object and the concurrency for the object. But what hard
 values
> >are reccomended?
>
> Leave them defaulted. Works 99% of the time. they are not related to
> size of object but to concurrency.
>
> >
> >I am also assuming that indexes have a higher INITRANS and MAXTRANS
> >than data segments.
>
> Not necessarily. The default may be different, though.
>
> >
> >Do you usually put INITRANS=MAXTRNAS for the more static tables? Is
 it
> >good practive to always keep the two equal?
>
> No. And most definitely no.
>
> MAXTRANS is like a high-water mark. Only to be used if ever the
> number of transactions updating rows in a given block goes near its
> value. I don't know of any case where that has actually happened
> using the default MAXTRANS. Usually the block header ends first...
>
> INITRANS reserves "transaction slots" in the block header before they
> are really asked for. Like a sort of a "cache". One of those is used
> for every row locked in the block by a given transaction - and
> therefore for every row potentially updated. If you have many
> processes updating in the same block, you may want a higher number for
> INITRANS so the kernel doesn't have to get them dynamically.
>
> I've seen this to be useful in cases where multiple load processes are
> adding to the end of a table. And some very odd OLTP cases. Other
> than that, never seen it needed.
>
> Cheers
> Nuno Souto
> nsouto_at_nsw.bigpond.net.au.nospam
> http://www.users.bigpond.net.au/the_Den/index.html
>

--


Sent via Deja.com http://www.deja.com/
Before you buy.