Re: TX locks

  • From: "Diego Cutrone" <diegocutrone@xxxxxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 27 May 2004 13:54:52 -0700

Matthew,

> Why would two transactions need the same TX enqueue? Is it because
> they are attempting to update the same row locally (which I have been=20
> unable to prove or disprove yet)?  Is it because they are=20
> both going after the same rows remotely?  Is it a lack of available =
> slots
> in the rollback segments (ie, not enough rollback segments)?

What kind of TX enqueue waits are you experiencing? TX-6 or TX-4?
TX-6 enqueue waits would indicate that a transaction is trying to lock a row
in X mode when that row is currently
being locked by another transaction in an incompatible mode. (most surely
another TX-6 lock) . This is an application issue more
than a database issue.

TX-4 is a complete different matter. I  faced TX-4 problems twice. The first
one was related to the lack of  free ITL slots
in a table (or index), I don't remember. And the second time the TX4 wait
was caused when a session was trying to insert a key value (part of an
unique index)
in a table after another session had already inserted the same value but had
not yet commited. The second session waited in a TX 4 enqueue wait
until the first one commited/rollback its transaction.


HTH.
Regards
Diego.




----- Original Message ----- 
From: "Adams, Matthew (GE Consumer & Industrial)" <MATT.ADAMS@xxxxxx>
To: <oracle-l@xxxxxxxxxxxxx>
Sent: Thursday, May 27, 2004 7:11 AM
Subject: TX locks


> I'm having a WHOLE lot of fun trying to track down
> the source of some ORA-2049 (timeout: distributed
> transaction waiting for lock) in a purchased app=20
> called Matrix.  I have a number of questions I'm hoping=20
> someone can answer.
>
> Now, according to Metalink, this occurs when a session is=20
> waiting on a TX enqueue that another session is holding AND
> the waiting session is performing a distributed operation
> via a DB link.
>
> Also, according to Metalink (in a different document), TX
> enqueues are taken on particular slots in particular rollback
> segments.
>
>
> If a new connection does, as it's first statment, a read across
> a DB link, is a TX enqueue aquired immediately on a local rollback=20
> segment (as I think it is?)
>
> Why would two transactions need the same TX enqueue? Is it because
> they are attempting to update the same row locally (which I have been=20
> unable to prove or disprove yet)?  Is it because they are=20
> both going after the same rows remotely?  Is it a lack of available =
> slots
> in the rollback segments (ie, not enough rollback segments)?
>
> None of these scenerios seem very likely in this case, but I'm=20
> grasping at straws here.
>
>
> ----
> Matt Adams - GE Appliances - matt.adams@xxxxxxxxxxx
> Just once, I wish we would encounter an
> alien menace that wasn't immune to bullets.=20
>            - The Brigadier
> ----------------------------------------------------------------
> 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
> -----------------------------------------------------------------
>


----------------------------------------------------------------
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
-----------------------------------------------------------------
  • References:
    • TX locks
      • From: Adams, Matthew (GE Consumer & Industrial)

Other related posts: