RE: Deadlock inserting into same rowid (different block)
Date: Wed, 17 Apr 2013 08:49:37 -0400
Message-ID: <C1117B1AA0340645894671E09A7891F714F98A6EBA_at_EIHQEXVM2.ei.local>
Update: I have been Following up with oracle support on this - but... I sent the analyst Jonathan Lewis's url posted on Apr 13th http://jonathanlewis.wordpress.com/2013/04/13/deadlocks/ -- but believe it or not, based on his response so far, I do not believe he read it. So I essentially sent the following.
The blocks in the deadlock graph below refer to a FK index, SCHEDULEDL_CONTRACT_FK, and a COSAUDIT table. The Index for SCHEDULEDL_CONTRACT_FK is on table SCHEDULEDLINEITME, and the foreign key is between the SCHEDULEDLINEITEM table and the CONTRACT table.
COSAUDIT in the deadlock graph isn't even involved anywhere; in the foreign key index, or the related tables in the FK constraint -- yet there it is in the deadlock graph, block 276654. Hence I am starting to understand - nothing like a picture.
The next step would be to try and dump the blocks - but one is an index block, and the other is not related to the two insert statements attempting to insert into SCHEDULEDLINEITEM.
So: Is would a dump of the FK block be of value? Is such a dump in any event also be left over garbage just like the COSAUDIT block making it untrustworthy even if there was useful information there, (I can't think of when it would be useful, I'm just asking for theoretical reasons)?
DBMON _at_ cosacc> select tablespace_name, segment_type, owner,
2 segment_name
3 from dba_extents where file_id = 6 and 433952 between block_id AND block_id + blocks-1;
TABLESPACE_NAME SEGMENT_TYPE OWNER SEGMENT_NAME ------------------------------ ------------------ ------------------------------ -------------------------- DATA1 TABLE COS COSAUDIT
DBMON _at_ cosacc> select tablespace_name, segment_type, owner,
2 segment_name
3 from dba_extents
4 where file_id = &file_num
5 and &block_num between block_id AND block_id + blocks-1;
Enter value for file_num: 6
Enter value for block_num: 276654
TABLESPACE_NAME SEGMENT_TYPE OWNER SEGMENT_NAME ------------------------------ ------------------ ------------------------------ -------------------------- DATA1 INDEX COS SCHEDULEDL_CONTRACT_FK
Joel Patterson
Database Administrator
904 928-2790
From: Patterson, Joel
Sent: Thursday, April 11, 2013 12:01 PM
To: 'jonathan_at_jlcomp.demon.co.uk'
Cc: 'oracle-l_at_freelists.org'
Subject: RE: Deadlock inserting into same rowid (different block)
Hello Jonathan,
I had created an SR on this issue, which is about to run its course.
In midst of it I asked if the slot #'s being zero is expected behavior in this situation. The response was why would it not be expected -- we start the number with 0,1,2 ... etc. It is the slot on the ITL it is waiting for.
Is there some elaboration which would help me discuss it further?
I plan to close out the SR as it has basically run its course at this point and the problem was identified and fixed - and I believe the forum was updated as well. Essentially two batch jobs running at the same time, however I wanted to explore this before I close taking advantage of the fact that the SR is open already.
Best Regards,
2013/3/20 Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk<mailto:jonathan_at_jlcomp.demon.co.uk>>
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_at_entint.com<mailto:jpatterson_at_entint.com>>Received on Wed Apr 17 2013 - 14:49:37 CEST
|
| 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)
|
|
|
-- http://www.freelists.org/webpage/oracle-l -- Bien Respectueusement Mohamed Houri -- http://www.freelists.org/webpage/oracle-l
