Първо, select изявлението никога не заключва нищо в Oracle, просто използва последната налична последователна версия на данните. Това не е случай за select ... for update който заключва данни като update от Oracle 9i, но няма for update клауза в заявката от въпрос.
Resource Name process session holds waits process session holds waits
TM-000151a2-00000000 210 72 SX SSX 208 24 SX SSX
Сесия #72 държи заключване на ниво таблица (TM) с тип "Изключителен ред" (SX) и искате да получите заключване "Изключително споделяне на ред" (SSX) на същата маса. Тази сесия е блокирана от сесия #24, която вече държи заключване на ниво таблица от същия тип (SX) и изчаква, докато SSX заключването ще бъде налично.
Resource Name process session holds waits process session holds waits
TM-000151a2-00000000 208 24 SX SSX 210 72 SX SSX
Това (втори ред) демонстрира точно същата ситуация, но в обратна посока:сесия #24 изчаква заключване на SSX да стане достъпна, но блокирана от сесия #72, която вече държи SX заключване на същата маса.
И така, сесии #24 и сесия #72 се блокират взаимно:възниква безизходица.
И двата типа заключване (SX и SSX) са ключалки на ниво таблица.
За да разберете ситуацията, препоръчвам да прочетете тази статия от Franck Pachot.
По-долу е цитат от тази статия, който е пряко свързан с вашата ситуация (обърнете внимание, че съкращенията SSX и SRX са еквивалентни):
Референтната цялост придобива и TM ключалки. Например, често срещаният проблем с неиндексирани външни ключове води до S заключвания на дъщерна таблица, когато издадете изтриване или актуализиране на ключа на родителската таблица. Това е така, защото без индекс Oracle няма един единствен ресурс от по-ниско ниво за заключване, за да предотврати едновременно вмъкване, което може да наруши референтната цялост.
Когато колоните с външния ключ са водещите колони в обикновен индекс, тогава първият запис в индекса с родителската стойност може да се използва като единичен ресурс и да се заключи с TXlock на ниво ред.
И какво, ако референтната цялост има каскада за изтриване? В допълнение към режима S, има намерение да се актуализират редове в дъщерната таблица, както при режим на ред X (RX). Това е мястото, където се появява изключителният ред за споделяне (SRX):S+RX=SRX.
Така че, най-вероятният вариант е, че сесия #72 и сесия #24 изтриват някои редове в EMPLOYEE таблица в същото време и има on delete cascade ограничение за EMPSAL_EMP_ID във връзка с липсата на индекс на EMPLOYEE_SALARY таблица, в която EMPSAL_EMP_ID колона, посочена първа.
