Identifying deadlocked resources in graph with 1 row lock and 1 table lock

Question

Hi, I have run into repeated occurrences of the deadlock graph at the bottom of this post and have a few questions about it:
1. It appears that proc 44, session 548 is holding a row lock (X). Is the waiter, proc 30, session 542, trying to acquire a row lock (X) also or an exclusive table lock (X) on the table containing that row?
2. Under what circumstances would something hold a row exclusive table lock (SX) and want to upgrade that to a share row exclusive table lock (SSX)?
3. Our table cxml_foldercontent has a column 'structuredDataId' with a FK to cxml_structureddata.id and an ON DELETE SET NULL trigger. Would this help explain why an "update" to one table (i.e.g cxml_foldercontent) would also need to acquire a lock in a foreign table, cxml_structureddata?
4. What is the difference between "Current SQL statement:" and "Current SQL statement for this session:"? That terminology is confusing. Is session 542 executing the "update" or the "delete"?
5. In the "Rows waited on:" section is it saying that Session 542 is waiting on on obj - rowid = 0000BE63 - AAAL5jAAGAAA6tZAAK or that it is has the lock on that row and other things are waiting on it?
A couple of notes:
- the cxml_foldercontent.structuredDataId FK column has an index on it already
Deadlock graph:
                       ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name                    process session holds waits  process session holds waits
TX-003a0011-000003d0        44       548     X               30        542             X
TM-0000be63-00000000       30       542     SX              44        548     SX    SSX
session 548: DID 0001-002C-000002D9     session 542: DID 0001-001E-00000050
session 542: DID 0001-001E-00000050     session 548: DID 0001-002C-000002D9
Rows waited on:
Session 542: obj - rowid = 0000BE63 - AAAL5jAAGAAA6tZAAK
  (dictionary objn - 48739, file - 6, block - 240473, slot - 10)
Session 548: no row
Information on the OTHER waiting sessions:
Session 542:
  pid=30 serial=63708 audsid=143708731 user: 41/CASCADE
  O/S info: user: cascade, term: unknown, ospid: 1234, machine:
            program: JDBC Thin Client
  application name: JDBC Thin Client, hash value=2546894660
  Current SQL Statement:
update cascade.cxml_foldercontent set name=:1 , lockId=:2 , isCurrentVersion=:3 , versionDate=:4 , metadataId=:5 , permissionsId=:6 , workflowId=:7 , isWorkingCopy=:8 , parentFolderId=:9 , relativeOrder=:10 , cachePath=:11 , isRecycled=:12 , recycleRecordId=:13 , workflowComment=:14 , draftUserId=:15 , siteId=:16 , prevVersionId=:17 , nextVersionId=:18 , originalCopyId=:19 , workingCopyId=:20 , displayName=:21 , title=:22 , summary=:23 , teaser=:24 , keywords=:25 , description=:26 , author=:27 , startDate=:28 , endDate=:29 , reviewDate=:30 , metadataSetId=:31 , expirationNoticeSent=:32 , firstExpirationWarningSent=:33 , secondExpirationWarningSent=:34 , expirationFolderId=:35 , maintainAbsoluteLinks=:36 , xmlId=:37 , structuredDataDefinitionId=:38 , pageConfigurationSetId=:39 , pageDefaultConfigurationId=:40 , structuredDataId=:41 , pageStructuredDataVersion=:42 , shouldBeIndexed=:43 , shouldBePublished=:44 , lastDatePublished=:45 , lastPublishedBy=:46 , draftOriginalId=:47 , contentTypeId=:48  where id=:49
End of information on OTHER waiting sessions.
Current SQL statement for this session:
delete from cascade.cxml_structureddata where id=:1

Answer 1

Mohamed Houri wrote:
What is important for a foreign key is to be indexed (of course if the parent table is deleted/merged/updated, or if a performance reason imposes it). Wether this index is unique or not doesn't matter (as far as i know).But, you should ask your self the following question : what is the meaning of having a 1 to 1 relationship between a parent and a child table ? if you succeed to create a unique index on your FK then this means that for each PK value corresponds at most one FK value!! Isn't it? is this what you want to have?Thanks, as I mentioned above, cxml_structureddata is actually the child table of cxml_foldercontent with 1 or more records' owningEntityId referring to rows in cxml_foldercontent. The reason for the FK on cxml_foldercontent.structuredDataId is a little ambiguous but it explained above.
Will a TX-enqueue held on mode X always be waited on by another TX-enqueue row lock X? Or can it be waited on by an Exclusive (X) table lock?Not really clear. Sorry, are you saying my question is unclear or it's not clear why type of eXclusive lock session 542 is trying to acquire in the first line of the trace? Do you think that the exclusive lock being held by session 548 in the first line is on rows in cxml_foldercontent (due to the ON DELETE SET NULL on these child rows) or rows in the cxml_structureddata that it's actually deleting?
Is there any way for me to tell for certain?
The first enqueue is a TX (Transaction Enqueue) held by session 548 on mode X (exclusive). This session represents the blocking session. At the same time the locked row is waited on by the blocked session (542) and the wait is on mode X (exclusive). So put it simply, we have here session 542 waiting for session 548 to release it lock (may be by commiting/roll backing). At this step we are not in presence of a deadlock.
The second line of the deadlock graph shows that session 542 is the blocking session and it is doing a TM enqueue (DML lock) held on SX(Shared eXclusive). While session 548(which is the waiting session) is blocked by session 542 and is waiting on SSX mode.
Here we see that 548 is blocking session 542 via a TX enqueue and session 542 is blocking session 548 via a TM enqueue ---> That is the deadlock. Oracle will then immediately choose arbitrarlly a victim session (542 or 548) and kill its process letting the remaining session continuing its work.
That is your situation explained here.Thanks, any idea why session 542 (the DELETE from cxml_structureddata) would be trying to upgrade it's lock to SSX? Is this lock mode required to update a child tables foreign key columns when using an ON DELETE SET NULL trigger? Having read more about SSX, I'm not sure I understand in what cases it's used. Is there a way for me to confirm with 100% certainty specifically which tables in the TM enqueue locks are being held on? Is session 548 definitely trying to acquire an SSX mode on my cxml_foldecontent table or could it be cxml_structureddata table?
(a) Verify that all your FK are indexed (be carreful that the FK columns should be at the leading edge of the index)Thanks, we've done this already. When you say the "leading edge" you mean for a composite index? These indexes are all single column.
(b) Verify the logic of the DML against cxml_foldercontentCan you be more specific? Any idea what I'm looking for?