Först av allt, select uttalande lås aldrig något i Oracle, använder bara den senaste tillgängliga konsekventa versionen av data. Det är inte ett fall för select ... for update som låser data som update sedan Oracle 9i, men det finns ingen for update klausul i frågan från frågan.
Resource Name process session holds waits process session holds waits
TM-000151a2-00000000 210 72 SX SSX 208 24 SX SSX
Session #72 har tabellnivålås (TM) med "Row Exclusive" typ (SX) och vill skaffa "Share Row Exclusive" (SSX) lås på samma bord. Denna session blockerad av session #24 som redan har tabellnivålås av samma typ (SX) och väntar medan SSX-lås skulle vara tillgängligt.
Resource Name process session holds waits process session holds waits
TM-000151a2-00000000 208 24 SX SSX 210 72 SX SSX
Detta (andra raden) visar exakt samma situation, men i motsatt riktning:Session #24 väntar på att SSX-låset blir tillgängligt, men blockeras av SX-låset på samma bord.
Så, Session #24 och Session #72 blockerar varandra:dödläge inträffar.
Båda låstyperna (SX och SSX) är lås på bordsnivå.
För att förstå situationen rekommenderar jag att du läser den här artikeln av Franck Pachot.
Nedan finns citat från denna artikel, som är direkt relevant för din situation (observera att SSX- och SRX-förkortningar är likvärdiga):
Referensintegritet förvärvar också TM-lås. Till exempel leder det gemensamma problemet med oindexerade främmande nycklar till S-lås på den underordnade tabellen när du utfärdar en radering, eller uppdatering av nyckeln, på den överordnade tabellen. Detta beror på att Oracle utan ett index inte har någon enskild resurs på lägre nivå att låsa för att förhindra en samtidig infogning som kan bryta mot dess referensintegritet.
När kolumnerna för främmande nyckel är de ledande kolumnerna i ett vanligt index, då den första indexposten med föräldravärdet kan användas som en enskild resurs och låsas med en radnivå TXlock.
Och vad händer om referensintegritet har en på raderingskaskad? Utöver S-läget finns det avsikten att uppdatera rader i den underordnade tabellen, som i Row X-läget (RX). Det är här share rowexclusive (SRX) förekommer:S+RX=SRX.
Så den mest troliga varianten är att session #72 och session #24 tar bort några rader i EMPLOYEE tabell samtidigt, och det finns on delete cascade begränsning för EMPSAL_EMP_ID i samband med frånvaro av index på EMPLOYEE_SALARY tabell i vilken EMPSAL_EMP_ID kolumnen listad först.