RE: Deadlock inserting into same rowid (different block)

  • From: "Bobak, Mark" <Mark.Bobak@xxxxxxxxxxxx>
  • To: "jpatterson@xxxxxxxxxx" <jpatterson@xxxxxxxxxx>, mohamed houri <mohamed.houri@xxxxxxxxx>
  • Date: Wed, 20 Mar 2013 12:26:49 -0400

Hi Joel,

Based on the deadlock graph shown below, although the table(s) involved may 
have parent/child FK relationships, I don't think that's relevant.

The problem is PK/UK overlap.

This means that, for a given table with a PK or UK constraint, session one 
inserts value 'x' for the constrained column and does not commit.  Then session 
two inserts value 'y' for constrained column, still no collision, no problem.  
But, now session one (attempts to) insert value 'y' for the constrained column. 
 But, session two has inserted it first, and has not yet committed or rolled 
back.  So, session one starts waiting on TX in 'S' mode.  Now, finally, session 
two, (which is already blocking session one) tries to insert value 'x', and is 
blocked by session one.  So, there you have it, a deadlock.

This is the scenario that I think Jonathan, and others, were trying to describe.

-Mark

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Patterson, Joel
Sent: Wednesday, March 20, 2013 12:10 PM
To: mohamed houri
Cc: Jonathan Lewis; oracle-l@xxxxxxxxxxxxx
Subject: RE: Deadlock inserting into same rowid (different block)

I would try and discuss this off line, but others are telling me that it is an 
interesting discussion, and I know Jonathan would rather reply to the group 
verses offline.
So I'm not quite visualizing this.

The unique constraint that Jonathan is referencing in this case would be the 
parent table, (the primary key that the foreign key is referencing - the dead 
lock being reported in the trace file is on the FK Index for the child table).

Is the implication that the application is working on the parent table first, 
and a second session is trying to commit the same parent record -- and the 
trace file is not reporting activity on the parent, (or it is but is buried 
further below in the dump)?

Session 1
Insert/update parent row 12, insert child referencing parent row 12   (no 
commit on either yet)

Session 2
Insert/update parent row 12, insert child referencing parent row 12... (no 
commit on either yet)

Child records part of deadlock graph below:

Parent records have the unique constraint collision?   Mohamed is suggesting 
that it is a PK, UK overlapping - I am not sure what is meant by that.



Joel Patterson
Database Administrator
904 928-2790

From: mohamed houri [mailto:mohamed.houri@xxxxxxxxx]
Sent: Wednesday, March 20, 2013 11:49 AM
To: Patterson, Joel
Cc: Jonathan Lewis; oracle-l@xxxxxxxxxxxxx
Subject: Re: Deadlock inserting into same rowid (different block)

Joel,

In case of deadlock occurring on Transaction (TX) enqueue held on mode X and 
waited on mode S I can think of 3 possibilities

1.      1)  Presence of Bitmap Indexes  -->  That is not your case

2.     2)   ITL slot contention  --> That is not your case because statements 
are insert and your table is not an IOT (I believe)

3.     3)   Primary key or unique Key overlapping --> that's your case
And yes developers should in this case review their code to not allow 
unique/primary key overlapping

Best regards
Mohamed Houri

2013/3/20 Patterson, Joel <jpatterson@xxxxxxxxxx<mailto:jpatterson@xxxxxxxxxx>>
I probably shouldn't ask, but how does one session know that another session 
has uncommitted values about to be committed that would conflict with what 
itself?

But aside from that, I wish to report back to the developers that are asking 
about this that --... essentially it is an application issue... and provide 
some suggestions such as the order of tables and/or rows...  but more 
specifically in this case, from what I am reading, it is counter productive to 
report back that the trace file is incorrect... Does it imply that this could 
be an anomaly and just wait and see if it is a reoccurring issue?      This is 
probably new code; the errors are in a UAT DB.


Joel Patterson
Database Administrator
904 928-2790<tel:904%20928-2790>


--
Joel Patterson
Sr. Database Administrator | Enterprise Integration
Phone: 904-928-2790<tel:904-928-2790> | Fax: 904-733-4916<tel:904-733-4916> 
http://www.entint.com/

http://www.entint.com/

http://www.facebook.com/pages/Enterprise-Integration/212351215444231 
http://twitter.com/#!/entint http://www.linkedin.com/company/18276?trk=tyah 
http://www.youtube.com/user/ValueofIT

This message (and any associated files) is intended only for the use of the 
addressee and may contain information that is confidential, subject to 
copyright or constitutes a trade secret. If you are not the intended recipient, 
you are hereby notified that any dissemination, copying or distribution of this 
message, or files associated with this message, is strictly prohibited. If you 
have received this message in error, please notify us immediately by replying 
to the message and deleting it from your computer. Messages sent to and from us 
may be monitored. Any views or opinions presented are solely those of the 
author and do not necessarily represent those of the company. [v.1.1]
From: Jonathan Lewis 
[mailto:jonathan@xxxxxxxxxxxxxxxxxx<mailto:jonathan@xxxxxxxxxxxxxxxxxx>]
Sent: Wednesday, March 20, 2013 11:09 AM
To: Patterson, Joel
Cc: oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>
Subject: Re: Deadlock inserting into same rowid (different block)

The deadlock pattern is indicative of collisions on a unique constraint.
They're both trying to insert primary / unique key values already inserted but 
not yet committed by the other session.

Given that the slot numbers are both zero, it's likely that they're being 
reported incorrectly - Oracle doesn't clean out the wait information for every 
single wait, so these could be the file and block (with zero row) for early 
buffer busy waits, or read by other session or some such.

Regards

Jonathan Lewis
http://jonathanlewis.wordpress.com/all-postings

Author: Oracle Core (Apress 2011)
http://www.apress.com/9781430239543


--
Joel Patterson
Sr. Database Administrator | Enterprise Integration
Phone: 904-928-2790 | Fax: 904-733-4916
www.entint.com<http://www.entint.com/>

[http://i1202.photobucket.com/albums/bb367/Entint/signaturev61.jpg]<http://www.entint.com/>

[http://i1202.photobucket.com/albums/bb367/Entint/th_FaceBook1.jpg]<http://www.facebook.com/pages/Enterprise-Integration/212351215444231>
  [http://i1202.photobucket.com/albums/bb367/Entint/th_Twitter1.jpg] 
<http://twitter.com/#!/entint>   
[http://i1202.photobucket.com/albums/bb367/Entint/th_LinkedIn1.jpg] 
<http://www.linkedin.com/company/18276?trk=tyah>   
[http://i1202.photobucket.com/albums/bb367/Entint/th_YouTube1.jpg] 
<http://www.youtube.com/user/ValueofIT>

This message (and any associated files) is intended only for the use of the 
addressee and may contain information that is confidential, subject to 
copyright or constitutes a trade secret. If you are not the intended recipient, 
you are hereby notified that any dissemination, copying or distribution of this 
message, or files associated with this message, is strictly prohibited. If you 
have received this message in error, please notify us immediately by replying 
to the message and deleting it from your computer. Messages sent to and from us 
may be monitored. Any views or opinions presented are solely those of the 
author and do not necessarily represent those of the company. [v.1.1]

From: "Patterson, Joel" <jpatterson@xxxxxxxxxx<mailto:jpatterson@xxxxxxxxxx>>

|
| Deadlock graph:
|                       ---------Blocker(s)--------  ---------Waiter(s)---------
| Resource Name          process session holds waits  process session holds
waits
| TX-001a0015-00014787        34      90     X             32       3
S
| TX-00190008-0000601b        32       3     X             34      90
S
|
| session 90: DID 0001-0022-00000327      session 3: DID 0001-0020-000009E9
| session 3: DID 0001-0020-000009E9       session 90: DID
0001-0022-00000327
|
| Rows waited on:
|  Session 90: obj - rowid = 00030CE5 - AAAwzlAAGAABDiuAAA  (dictionary 
| objn - 199909, file - 6, block - 276654, slot - 0)  Session 3: obj - 
| rowid = 00030CE5 - AAAwzlAAGAABp8gAAA  (dictionary objn - 199909, file
| - 6, block - 433952, slot - 0)
|
|
|


--
//www.freelists.org/webpage/oracle-l




--
Bien Respectueusement
Mohamed Houri

--
//www.freelists.org/webpage/oracle-l




--
//www.freelists.org/webpage/oracle-l

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 03-2013