Znalezienie przyczyny błędu zakleszczenia z pliku śledzenia oracle

Question

Otrzymuję ten błąd "ora-00060 wykryty podczas oczekiwania na zasoby" często w mojej aplikacji, gdy wielu użytkowników korzysta z aplikacji. Mam plik śledzenia od administratora wyroczni, ale potrzebuję pomocy w jego odczytaniu. Poniżej znajdują się fragmenty danych z pliku śledzenia, które, mam nadzieję, pomogłyby w zlokalizowaniu przyczyny.

*** 2013-06-25 09:37:35.324 
DEADLOCK DETECTED (ORA-00060) 

[Transaction Deadlock] 

The following deadlock is not an ORACLE error. It is a deadlock due 
to user error in the design of an application 
or from issuing incorrect ad-hoc SQL. The following 
information may aid in determining the deadlock: 

Deadlock graph: 
        ---------Blocker(s)-------- ---------Waiter(s)--------- 
Resource Name   process session holds waits process session holds waits 
TM-000151a2-00000000  210  72 SX SSX  208  24 SX SSX 
TM-000151a2-00000000  208  24 SX SSX  210  72 SX SSX 

session 72: DID 0001-00D2-000000C6 session 24: DID 0001-00D0-00000043 
session 24: DID 0001-00D0-00000043 session 72: DID 0001-00D2-000000C6 

Rows waited on: 
Session 72: no row 
Session 24: no row 

----- Information for the OTHER waiting sessions ----- 
Session 24: 
sid: 24 ser: 45245 audsid: 31660323 user: 90/USER 
    flags: (0x45) USR/- flags_idl: (0x1) BSY/-/-/-/-/- 
    flags2: (0x40009) -/-/INC 
pid: 208 O/S info: user: zgrid, term: UNKNOWN, ospid: 2439 
    image: oracle@xyz.local 
client details: 
    O/S info: user: , term: , ospid: 1234 
    machine: xyz.local program: 
current SQL: 
    delete from EMPLOYEE where EMP_ID=:1 

----- End of information for the OTHER waiting sessions ----- 

Information for THIS session: 

----- Current SQL Statement for this session (sql_id=dyfg1wd8xa9qt) ----- 
delete from EMPLOYEE where EMP_ID=:1 
=================================================== 

Byłbym wdzięczny, gdyby ktoś mógł mi powiedzieć, co mówi "Zakleszczenie wykresu ::". Również wiersze oczekujące w sekcji nie zawierają wierszy.

Czytałem również na niektórych blogach, że sekcja "sqltxt" z pliku śledzenia może zasugerować przyczynę. Poniżej znajduje się zapytanie, które widzę w tej sekcji.

select /*+ all_rows */ count(1) from "USERS"."EMPLOYEE_SALARY" where EMPSAL_EMP_ID=:1 

Tabela employee_salary zawiera ograniczenie obcości w kolumnie EMPSAL_EMP_ID.

Wskazówka sql mówi "all_rows", więc czy to oznacza, że ​​ta tabela pobiera blokadę poziomu tabeli podczas kasowania rekordów z tabeli pracowników? Obecnie nie mam indeksu na kolumnie klucza obcego. Czy dodanie indeksu do tej kolumny pomogłoby?

Uprzejmie post, na wypadek, gdyby potrzebne były dodatkowe informacje.

Dzięki

Answer 1

Przede wszystkim select oświadczenie nigdy zablokować coś w Oracle, tylko korzysta z ostatnią dostępną spójną wersję danych. Nie jest to przypadek dla select ... for update, który blokuje dane takie jak update od Oracle 9i, ale nie ma klauzuli for update 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 posiada blokadę na poziomie tabeli (TM) z "Rz Exclusive" typu (SX) i chcą nabyć "Poleć Row exclusive" (SSX) blokady na tej samej tabeli. Ta sesja została zablokowana przez sesję # 24, która już posiada blokadę na poziomie stołu tego samego typu (SX) i czeka, aż będzie dostępna blokada SSX.

Resource Name   process session holds waits process session holds waits 
TM-000151a2-00000000  208  24 SX SSX  210  72 SX SSX 

to (drugi wiersz) pokazuje dokładnie tę samą sytuację, ale w przeciwnym kierunku: Session # 24 czeka na SSX zamek stają się dostępne, ale zablokowane przez Session # 72, który już posiada blokadę SX na tym samym stole.

Tak więc, sesje nr 24 i sesja nr 72 blokują się wzajemnie: występuje problem.

Oba rodzaje zamków (SX i SSX) to blokady na poziomie stołu.
Aby zrozumieć sytuację, polecam przeczytanie this article przez Francka Pachota.

Poniżej cytat z tego artykułu, które bezpośrednio odnoszą się do danej sytuacji (zauważ, że SSX i SRX skróty są równoważne):

Więzy integralności nabywa również TM zamki. Na przykład, wspólny błąd z nieindeksowanymi kluczami obcymi prowadzi do blokad S w tabeli podrzędnej, gdy użytkownik wydaje usunięcie lub aktualizację klucza w tabeli nadrzędnej. Jest to , ponieważ bez indeksu, Oracle nie ma pojedynczego zasobu niższego poziomu do blokady, aby zapobiec współbieżnej wstawce, która może naruszać integralność referencyjną .
Gdy kolumny klucza obcego są wiodącymi kolumnami w indeksie regularnym, wówczas pierwszy wpis indeksu z wartością nadrzędną może być używany jako pojedynczy zasób i zablokowany z blokadą TX na poziomie wiersza TX .
A co jeśli integralność referencyjna ma kaskadę kasowania? W trybie dodawania istnieje zamiar aktualizacji wierszy tabeli podrzędnej , tak jak w trybie Wiersz X (RX). W tym miejscu pojawia się rząd akcji (SRX): S + RX = SRX.

Tak, najbardziej prawdopodobny wariant jest to, że sesja nr 72 i Session # 24 usuwa niektóre wiersze w EMPLOYEE stole w tym samym czasie, a są on delete cascade ograniczeniem dla EMPSAL_EMP_ID w połączeniu z braku indeksu na EMPLOYEE_SALARY tabeli, w której EMPSAL_EMP_ID kolumna wymienione na pierwszym miejscu.