Oracle experts,
I (think) I understand how application design problems can lead to deadlocks.
E.g.,
USER1: UPDATE TABLE_A SET COLUMN_A = 'X' WHERE ID = 100;USER2: UPDATE TABLE_A
SET COLUMN_A = 'X' WHERE ID = 101;
USER2: UPDATE TABLE_A SET COLUMN_A = 'X' WHERE ID = 100; (waits for
user1)USER1: UPDATE TABLE_A SET COLUMN_A = 'X' WHERE ID = 101; (deadlocks)
To avoid this, user1 and user2 should have done their updates in the same order.
Something I never thought about before is this scenario:
USER1: UPDATE TABLE_A SET COLUMN_A = 'X' WHERE ID BETWEEN 100 AND 200;USER2:
UPDATE TABLE_B SET COLUMN_A = 'X' WHERE ID BETWEEN 100 AND 200 AND EXISTS (...
something else that throws off execution plan maybe);
I thought I understood that, as each transaction processes rows, it adds itself
to the ITL of every block it touches and flags each row as locked by that ITL
entry. If that is the case, what guarantees that both transactions touch rows
in the same order. That is, what guarantees that these two updates do not
deadlock?
I don't think I've ever encountered in 25 years two bulk update statements
deadlocking by themselves. But what exactly has been saving me?
Thanks in advance!
Matt
