Przede wszystkim select Instrukcja nigdy nie blokuje niczego w Oracle, po prostu używa ostatniej dostępnej spójnej wersji danych. To nie jest przypadek, gdy select ... for update który blokuje dane, takie jak update od Oracle 9i, ale nie ma for update klauzula w zapytaniu z pytania.
Resource Name process session holds waits process session holds waits
TM-000151a2-00000000 210 72 SX SSX 208 24 SX SSX
Sesja nr 72 utrzymuje blokadę na poziomie tabeli (TM) z typem „Row Exclusive” (SX) i chce uzyskać blokadę „Share Row Exclusive” (SSX) na tej samej tabeli. Ta sesja została zablokowana przez Sesję #24, która już posiada blokadę na poziomie tabeli tego samego typu (SX) i czeka, aż blokada SSX będzie dostępna.
Resource Name process session holds waits process session holds waits
TM-000151a2-00000000 208 24 SX SSX 210 72 SX SSX
Ten (drugi rząd) pokazuje dokładnie tę samą sytuację, ale w przeciwnym kierunku:Sesja #24 czeka, aż blokada SSX stanie się dostępna, ale zablokowana przez Sesję #72, która już posiada blokadę SX na tej samej tabeli.
Tak więc Sesje #24 i Sesja #72 blokują się nawzajem:następuje impas.
Oba typy blokad (SX i SSX) są blokadami na poziomie tabeli.
Aby zrozumieć sytuację, polecam przeczytać ten artykuł Francka Pachota.
Poniżej znajduje się cytat z tego artykułu, który bezpośrednio odnosi się do Twojej sytuacji (zauważ, że skróty SSX i SRX są równoważne):
Integralność referencyjna uzyskuje również blokady TM. Na przykład częsty problem z nieindeksowanymi kluczami obcymi prowadzi do blokad S w tabeli podrzędnej po wydaniu usunięcia lub aktualizacji klucza w tabeli nadrzędnej. Dzieje się tak, ponieważ Oracle bez indeksu nie ma do zablokowania pojedynczego zasobu niższego poziomu, aby zapobiec jednoczesnemu wstawianiu, które może naruszyć integralność referencyjną.
Kiedy kolumny kluczy obcych są kolumnami wiodącymi w zwykłym indeksie, wówczas pierwszy wpis indeksu z wartość parentvalue może być używana jako pojedynczy zasób i zablokowana za pomocą funkcji TXlock na poziomie wiersza.
A co jeśli integralność referencyjna ma kaskadę usuwania? Oprócz trybu S istnieje zamiar aktualizacji wierszy w tabeli podrzędnej, tak jak w trybie Row X (RX). W tym miejscu występuje wyłączność na akcje (SRX):S+RX=SRX.
Tak więc najbardziej prawdopodobnym wariantem jest to, że Sesja #72 i Sesja #24 usuwają niektóre wiersze w EMPLOYEE tabeli w tym samym czasie i są on delete cascade ograniczenie dla EMPSAL_EMP_ID w związku z brakiem indeksu na EMPLOYEE_SALARY tabela, w której EMPSAL_EMP_ID kolumna wymieniona jako pierwsza.
