If I were to take a guess from the above, session 123 inserted into the child table (or modified a row) and is attemping to insert into the parent table, but was blocked by session 122. Session 122 modified another row in the parent table, but the child table has a missing foreign key index, so the modification of the parent table tried to generate a mode 4 share lock on the child table, but is blocked due to the mode 6 exclusive row lock on the child table acquired by session 123. The mode 4 share lock may be caused by other problems including potential duplicate values in a primary/unique column (should the other session commit), a problem with initrans, bitmap indexes, a session trying to modify a row already modified by another session, or a handful of other problems.

If you search the forum, I have previously posted a couple different deadlock graphs and the SQL code that I used to generate those deadlock graphs. You might find an exact match for the above pattern.

Well, I have to disagree w/ Charles. If the deadlock was due to unindexed foreign keys, that would be a TM enqueue. This deadlock graph indicates two TX enqueues.

The current session, 446, is executing the insert on PS_BI_ACCT_ENTRY. The second line of the deadlock graph indicates that the session is waiting on a TX in 'S' mode.

The other session, 404, is executing the update on PS_BI_LOADGL_PROC. The first line of the deadlock graph indicates that the session is waiting on a TX in 'X' mode.

The insert waiting on TX in 'S' mode is almost certainly a case of a session (446) trying to insert a value for a primary or unique key, where another session (404) has already inserted that value and no yet committed. This session will wait for the other session to either commit or rollback.

The update waiting on TX in 'X' mode is almost certainly a case of a session (404) trying to update (lock) an existing row that another session (446) has already selected for update or updated or deleted that same row and not yet committed.

No problem with you disagreeing with me, and I agree that an unindexed foreign key would result in a TM lock on the child table. The setup that I was trying to describe was one in which the TM lock could not be obtained due to another session already holding a TX lock on the child, something like this: