When you alter the INITRANS value for the table, it will not affect
blocks already too tightly packed to permit the itl list to grow. In
such cases, you will have to recreate the table with the INITRANS value
set to the higher value. And, 100 seems an awfully high value. It only
needs to be high enough to cover concurrent transactions per block.
Moreover, if you also set pctfree to a somewhat higher value, the new
itl list will have more room to grow if it needs to.
Samuel Becker wrote:
>
> Hello,
>
> executing a multi-threaded application, i get puzzling deadlocks.
> Indeed, each thread works on the same tables but not on same rows !
>
> Notes :
> - I have tried to put INITRANS value of all tables and index to 100 instead
> of 1 but it did not change anything.
>
> - I use Oracle sequences, and sequence name appears in Oracle log. Can Oracle
> sequence induce deadlock ? I don't think so but..
>
> Here's a sample of Oracle log:
>
> *** 2001-11-28 16:54:45.280
> *** SESSION ID:(16.2237) 2001-11-28 16:54:45.270
> DEADLOCK DETECTED
> Current SQL statement for this session:
> DELETE FROM TRK_ELEMENTARYTRANSPORT WHERE TRK_ELEMENTARYTRANSPORT_ID=:1
> The following deadlock is not an ORACLE error. It is a
> deadlock due to user error in the design of an application
> or from issuing incorrect ad-hoc SQL. The following
> information may aid in determining the deadlock:
> Deadlock graph:
> ---------Blocker(s)-------- ---------Waiter(s)---------
> Resource Name process session holds waits process session holds waits
> TM-000067fb-00000000 18 16 SX SSX 23 20 SX SSX
> TM-000067fb-00000000 23 20 SX SSX 18 16 SX SSX
> session 16: DID 0001-0012-00000002 session 20: DID 0001-0017-00000002
> session 20: DID 0001-0017-00000002 session 16: DID 0001-0012-00000002
> Rows waited on:
> Session 20: no row
> Session 16: no row
>
> Thanks.
Received on Fri Nov 30 2001 - 22:00:10 CST
