Først og fremmest select sætning lås aldrig noget i Oracle, bruger bare den sidste tilgængelige konsistente version af data. Det er ikke en sag for select ... for update som låser data som update siden Oracle 9i, men der er ingen for update klausul i forespørgslen fra spørgsmålet.
Resource Name process session holds waits process session holds waits
TM-000151a2-00000000 210 72 SX SSX 208 24 SX SSX
Session #72 har bordniveaulås (TM) med "Row Exclusive" type (SX) og ønsker at erhverve "Share Row Exclusive" (SSX) lås på samme bord. Denne session er blokeret af session #24, som allerede har bordniveaulås af samme type (SX) og venter, mens SSX-lås er tilgængelig.
Resource Name process session holds waits process session holds waits
TM-000151a2-00000000 208 24 SX SSX 210 72 SX SSX
Denne (anden række) viser nøjagtig samme situation, men i modsat retning:Session #24 venter på, at SSX-låsen bliver tilgængelig, men blokeret af session #72, som allerede har SX-lås på samme bord.
Så Session #24 og Session #72 blokerer for hinanden:dødvande sker.
Begge låsetyper (SX og SSX) er låse på bordniveau.
For at forstå situationen anbefaler jeg at læse denne artikel af Franck Pachot.
Nedenfor er citat fra denne artikel, som er direkte relevant for din situation (bemærk, at SSX- og SRX-forkortelser er ækvivalente):
Referenceintegritet erhverver også TM-låse. F.eks. fører det almindelige problem med uindekserede fremmednøgler til S-låse på den underordnede tabel, når du udsteder en sletning eller opdatering på nøglen på den overordnede tabel. Dette skyldes, at Oracle uden et indeks ikke har en enkelt ressource på et lavere niveau, der skal låses for at forhindre en samtidig indsættelse, der kan krænke deres referentielle integritet.
Når fremmednøglekolonnerne er de førende kolonner i et almindeligt indeks, så er den første indeksindgang med forældreværdien kan bruges som en enkelt ressource og låses med en rækkeniveau TXlock.
Og hvad nu hvis referenceintegritet har en på slette-kaskade? Ud over S-tilstanden er der hensigten at opdatere rækker i den underordnede tabel, som med Row X (RX)-tilstand. Det er her share rowexclusive (SRX) forekommer:S+RX=SRX.
Så den mest sandsynlige variant er, at session #72 og session #24 sletter nogle rækker i EMPLOYEE tabel på samme tid, og der er on delete cascade begrænsning for EMPSAL_EMP_ID i forbindelse med fravær af indeks på EMPLOYEE_SALARY tabel, hvori EMPSAL_EMP_ID kolonne angivet først.