Re: TX locks
- From: "Jonathan Lewis" <jonathan@xxxxxxxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 27 May 2004 20:50:47 +0100
Other common causes of TX/4 waits on a TX/6
Bitmap indexes on OLTP tables - with updates to
the bitmapped column, or inserts/delete of rows.
Updates colliding on rows in IOTs.
Several variations of pk/fk activity split across
two sessions.
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/seminar.html
Optimising Oracle Seminar - schedule updated May 1st
----- Original Message -----
From: "Adams, Matthew (GE Consumer & Industrial)" <MATT.ADAMS@xxxxxx>
To: <oracle-l@xxxxxxxxxxxxx>
Sent: Thursday, May 27, 2004 7:45 PM
Subject: RE: TX locks
The blocker has the TX enqueue with lmode=3D6, the requestor=20
is requesting a shared lock (lmode=3D4). =20
I've narrowed the issue down to two the same two possibilities
you mentioned:
1) The blocked transaction is attempting to insert the same PK/UK
values and is waiting to see if the first one commits or rolls back.
2) Lack of an available ITL slot in either the table or index. =20
Since maxtrans is set to 255, I'm leaning away from this, although
I am aware of the fact that if there is not enough space in the block=20
to increase the ITL from the default of one, it will wait rather than
expand the ITL, eventually timing out with this 2049 error. I think it =
would
be happening a little less frequently if this were the problem.
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
