Allereerst, select statement vergrendelt nooit iets in Oracle, maar gebruikt alleen de laatst beschikbare consistente versie van gegevens. Het is niet het geval voor select ... for update die gegevens vergrendelt zoals update sinds Oracle 9i, maar er zijn geen for update clausule in de query van vraag.
Resource Name process session holds waits process session holds waits
TM-000151a2-00000000 210 72 SX SSX 208 24 SX SSX
Sessie #72 heeft een lock op tafelniveau (TM) met het type "Row Exclusive" (SX) en wil een "Share Row Exclusive" (SSX) -vergrendeling op dezelfde tafel verkrijgen. Deze sessie is geblokkeerd door Sessie #24 die al een vergrendeling op tafelniveau van hetzelfde type (SX) bevat en wacht terwijl SSX-vergrendeling beschikbaar zou zijn.
Resource Name process session holds waits process session holds waits
TM-000151a2-00000000 208 24 SX SSX 210 72 SX SSX
Deze (tweede rij) toont exact dezelfde situatie, maar in tegengestelde richting:sessie #24 wacht tot SSX-lock beschikbaar komt, maar wordt geblokkeerd door sessie #72 die al SX-lock op dezelfde tafel heeft.
Dus Sessies #24 en Sessie #72 blokkeren elkaar:er treedt een impasse op.
Beide soorten sloten (SX en SSX) zijn sloten op tafelniveau.
Om de situatie te begrijpen raad ik aan dit artikel van Franck Pachot te lezen.
Hieronder vindt u een citaat uit dit artikel, dat direct relevant is voor uw situatie (merk op dat de afkortingen SSX en SRX equivalent zijn):
Referentiële integriteit verwerft ook TM-sloten. Het veelvoorkomende probleem met niet-geïndexeerde externe sleutels leidt bijvoorbeeld tot S-locks op de onderliggende tabel wanneer u een verwijdering of update van de sleutel op de bovenliggende tabel uitvoert. Dit komt omdat Oracle zonder index geen enkele resource op een lager niveau heeft om te vergrendelen om te voorkomen dat gelijktijdige insertie de referentiële integriteit kan schenden.
Als de kolommen met de refererende sleutel de leidende kolommen zijn in een reguliere index, dan is de eerste indexvermelding met de parentvalue kan worden gebruikt als een enkele bron en worden vergrendeld met een TXlock op rijniveau.
En wat als referentiële integriteit een cascade bij verwijderen heeft? Naast de S-modus is het de bedoeling om rijen in de onderliggende tabel bij te werken, zoals bij Rij X (RX)-modus. Hier komt de share rowexclusive (SRX) voor:S+RX=SRX.
De meest waarschijnlijke variant is dus dat Sessie #72 en Sessie #24 enkele rijen verwijderen in EMPLOYEE tafel tegelijkertijd, en er zijn on delete cascade beperking voor EMPSAL_EMP_ID in combinatie met afwezigheid van index op EMPLOYEE_SALARY tabel waarin EMPSAL_EMP_ID kolom als eerste vermeld.