Nejprve select nikdy nic v Oracle neuzamkne, pouze používá poslední dostupnou konzistentní verzi dat. Není to případ pro select ... for update který uzamkne data jako update od Oracle 9i, ale neexistují žádné update klauzule v dotazu z otázky.
Resource Name process session holds waits process session holds waits
TM-000151a2-00000000 210 72 SX SSX 208 24 SX SSX
Relace #72 drží zámek na úrovni stolu (TM) s typem „Row Exclusive“ (SX) a chce získat zámek „Share Row Exclusive“ (SSX) na stejném stole. Tato relace je blokována relací #24, která již obsahuje zámek na úrovni tabulky stejného typu (SX) a čeká, dokud nebude k dispozici zámek SSX.
Resource Name process session holds waits process session holds waits
TM-000151a2-00000000 208 24 SX SSX 210 72 SX SSX
Tento (druhý řádek) demonstruje přesně stejnou situaci, ale v opačném směru:Relace #24 čeká, až bude dostupný zámek SSX, ale blokována relací #72, která již má zámek SX na stejném stole.
Takže relace #24 a relace #72 se vzájemně blokují:dojde k uváznutí.
Oba typy zámků (SX a SSX) jsou zámky na úrovni tabulky.
Abyste pochopili situaci, doporučuji si přečíst tento článek od Francka Pachota.
Níže je citace z tohoto článku, která se přímo týká vaší situace (všimněte si, že zkratky SSX a SRX jsou ekvivalentní):
Referenční integrita také získává zámky TM. Například společný problém s neindexovanými cizími klíči vede k zámkům S na podřízené tabulce, když provedete odstranění nebo aktualizaci klíče v nadřazené tabulce. Je to proto, že bez indexu nemá Oracle žádný jediný prostředek na nižší úrovni k zablokování, aby zabránil souběžnému vkládání, které by mohlo narušit referenční integritu.
Když jsou sloupce cizího klíče hlavními sloupci v běžném indexu, pak první položka indexu s rodičovská hodnota může být použita jako jeden zdroj a uzamčena pomocí TXlock na úrovni řádku.
A co když má referenční integrita kaskádu při mazání? Kromě režimu S je záměrem aktualizovat řádky v podřízené tabulce, jako u režimu Row X (RX). Zde se vyskytuje sdílení rowexclusive (SRX):S+RX=SRX.
Nejpravděpodobnější variantou tedy je, že relace č. 72 a relace č. 24 odstraní některé řádky v EMPLOYEE tabulky ve stejnou dobu a jsou zde on delete cascade omezení pro EMPSAL_EMP_ID ve spojení s absencí indexu na EMPLOYEE_SALARY tabulka, ve které je EMPSAL_EMP_ID sloupec uveden jako první.