Re: Free space not re-used

Hi Mark,

No, a wait to reuse an in-use ITL entry because of insufficient free space to dynamically create another one is shown as an 'enqueue' wait. The waiter waits for a shared mode lock on the TX enqueue for the transaction using the ITL that it has chosen to wait for.

In general, you should not use a non-default INITRANS setting, and particularly in this case, because it would compromise data density severely. In general, that risk is adequately managed by ensuring that PCTFREE is non-zero, but in some cases it is neccessary to allow PCTFREE to be slightly larger than the average row length.

Regards,
Steve Adams

http://www.ixora.com.au/

http://www.oreilly.com/catalog/orinternals/

http://www.christianity.net.au/

On Sat, 19 Feb 2000 20:59:33 GMT, markp7832_at_my-deja.com wrote:

>In article <38b0d39c.25364763_at_news.remarq.com>,
> dcowles_at_i84.net (Doug Cowles) wrote:
>> You wouldn't care to elaborate on the different problem would you?
>> The buffer busy waits?
>>
>> - Dc.
>>
>> On Fri, 18 Feb 2000 00:17:43 GMT, steve.adams_at_ixora.com.au (Steve
>> Adams) wrote:
>>
>> >Hi Oliver,
>> >
>> >Having PCTFREE + PCTUSED = 100 does not cause free space to go
>unused,
>> >as in your case, but it does increase the risk of 'buffer busy waits'
>> >against the segment header block if the table is modified by multiple
>> >concurrent sessions. However, that is a different problem.
>> >
>Steve can correct me if I am wrong, but I believe he is saying that by
>having pctfree + pctused = 100 you are increasing the odds that they
>will not be space left in a block, to allocate transaction work areas
>from, if multiple sessions attempt updates against rows in the block
>after it is filled.
>
>You can help prevent that problem by preallocating transaction work
>areas via initrans when you create the table.
Received on Tue Feb 22 2000 - 22:01:16 CST