Re[2]: Secret maximum for INITRANS?

From: Robert Eskridge <bryny_at_dfweahs.net>
Date: Tue, 05 Mar 2002 05:43:18 -0800
Message-ID: <F001.0041F6C7.20020305054318@fatcity.com>

Yes, and that's exactly what I was suspecting. Thanks for the quick confirmation.

-rje

KG> I guess you are looking in 'itc' in block dumps which shows the KG> ITL Count.

KG> And yes.. There is an upper bound for number of ITLs based on the
KG> block size. The transaction slots (and other headers) can not use
KG> the more than 50% of the space available for data in the data
KG> block. Each ITL will take 24 bytes of space in variable header
KG> part of the data block.

KG> In 2K block (2048) 50 % is 1024 Bytes. In this we can not use the

KG> first 48 bytes (fixed headers in cache layer and TX data layers KG> uses them. So the space available for ITLs will be 976 bytes.

KG> So you can get round (976/24) ~41 ITL slots for 2K block size. If
KG> you set INITRANS more than 41 they are simply ignored and only 41
KG> ITLS are created in that block.



RE> I'm still messing with my enqueue waits on an insert. I'm now able to
RE> recreate it on a test database by throwing enough simultaneous inserts
RE> at my table. I was going to make sure which of the tables/indexes was
RE> actually causing the waits by individually raising the INITRANS above

RE> what they would naturally expand to, and see how the waiting sessions RE> responded.

RE> I was hitting it with 50 simultaneous inserts and usually had 10
RE> sessions go into an enqueue wait until the 40 sessions committed or
RE> rolled back.  So I was going though the indexes and then tables
RE> raising the INITRANS to 50 to see which one(s) made a difference.
RE> None of them made a difference.

RE> So I dumped blocks that had been populated only during this exercise.
RE> Invariably, there were 0x29 Itl slots.  Is there something out there
RE> that would limit the Itl entries to 41 even when MAXTRANS=255?  Is

RE> there some secret bound based on block size? Ours is 2k (which I RE> figure is part of the problem).

RE> Other vital stats: 8.0.5 on Solaris 2.7.

--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author: Robert Eskridge
  INET: bryny_at_dfweahs.net

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


--------------------------------------------------------------------


To REMOVE yourself from this mailing list, send an E-Mail message

to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). Received on Tue Mar 05 2002 - 07:43:18 CST