Вашият пример във вашия въпрос показва, че редът на заключване зависи от метода на достъп. Този път за достъп не се определя директно от клаузата ORDER BY на заявката, има много фактори, които могат да повлияят на този път за достъп. Следователно не можете да предотвратите блокиране само чрез добавяне на ORDER BY, защото все още можете да имате два различни пътя за достъп. Всъщност, като стартирах вашия тестов случай с поръчката от и промених параметрите на сесията, успях да накарам две сесии да се сблъскат с ORA-60 със същата заявка.
Ако участващите сесии нямат друго предстоящо заключване, заключването на редовете в същия ред във всички сесии ще предотврати блокиране, но как можете надеждно да наложите тази поръчка? Имайте предвид, че това така или иначе само би предотвратило този много специален случай на безизходица. Все още можете да получите блокиране с множество заявки във всяка сесия или различни планове.
На практика този случай е наистина специален и така или иначе не трябва да се случва често:ако се притеснявате от безизходица, все пак мисля, че има по-лесни методи за предотвратяването им.
Най-лесният начин да предотвратите блокиране е да използвате или FOR UPDATE NOWAIT или FOR UPDATE WAIT X (въпреки че WAIT X все още може да задейства блокиране със стойности на X, по-добри от механизма за откриване на безизходица, понастоящем 3 секунди от 11g според мен - благодаря @APC
за корекция).
С други думи, и двете транзакции трябва да питат:дайте ми тези редове и ги заключете, но ако друг потребител вече има заключване, върне грешка, вместо да чака неограничено време. Неограниченото чакане е причината за блокиране.
На практика бих казал, че повечето приложения с реални потребители биха предпочели да получат грешка незабавно, отколкото да чакат транзакция неограничено време, докато друга транзакция завърши. Бих помислил за FOR UPDATE без NOWAIT само за некритични пакетни задачи.
