Identyfikowanie i rozwiązywanie Oracle ITL Deadlock

Question

Mam pakiet Oracle DB, który jest rutynowo przyczyną impasu ITL (Zainteresowana lista transakcji). Odpowiednia część pliku śledzenia znajduje się poniżej.

Deadlock graph: 
         ---------Blocker(s)-------- ---------Waiter(s)--------- 
Resource Name   process session holds waits process session holds waits 
TM-0000cb52-00000000  22  131   S  23  143   SS 
TM-0000ceec-00000000  23  143 SX    32  138 SX SSX 
TM-0000cb52-00000000  30  138 SX    22  131   S 
session 131: DID 0001-0016-00000D1C session 143: DID 0001-0017-000055D5 
session 143: DID 0001-0017-000055D5 session 138: DID 0001-001E-000067A0 
session 138: DID 0001-001E-000067A0 session 131: DID 0001-0016-00000D1C 
Rows waited on: 
Session 143: no row 
Session 138: no row 
Session 131: no row 

Brak bit-mapa indeksy na tym stole, więc to nie jest przyczyną. O ile mogę powiedzieć, brak "czekanych wierszy" i "S" w kolumnie oczekiwania Kelnera wskazuje, że jest to zakleszczenie ITL. Ponadto, tabela jest napisana dość często (około 8 wstawek lub aktualizacji jednocześnie, tak często, jak 240 razy na minutę), więc impasu ITL wydaje się być silną możliwością.

Zwiększyłem parametr INITRANS tabeli i jego indeksy do 100 i zwiększyłem wartość PCT_FREE na tabeli z 10 do 20 (następnie przebudowałem indeksy), ale zakleszczenia nadal występują. Zakleszczenie zdarza się najczęściej w trakcie aktualizacji, ale to może być tylko zbieg okoliczności, ponieważ udało mi się to tylko kilka razy.

Moje pytania są dwojakie:
1) Czy to rzeczywiście jest zakleszczenie ITL?
2) Jeśli jest to zakleszczenie ITL, co jeszcze można zrobić, aby tego uniknąć?

---

Okazuje się, że nie był to impas ITL problem w ogóle, ale raczej problem z kluczy obcych un indeksowane. Odkryłem to dzięki odpowiedzi dpbradleya, która przekonała mnie, że to nie był problem z ITL i skłonił mnie do odkrycia, jakie mogą być inne przyczyny impasu z "bez wierszy".

Answer 1

Najlepszym wskaźnikiem ciśnienia ITL jest od poglądów wydajności:

select event, total_waits, time_waited, average_wait 
from v$system_event 
where event like 'enq: TX%' 
order by 2 desc; 

pokazuje TX rywalizacją czeka, a

select OBJECT_NAME, SUBOBJECT_NAME, TABLESPACE_NAME, 
     OBJECT_TYPE, STATISTIC_NAME, VALUE 
    from v$segment_statistics 
    where statistic_name = 'ITL waits' 
    and value > 0 
    order by value desc; 

pokazuje tabele i indeksy związane.

(jak wszystkie v$ poglądów, wyniki są z punktu w czasie, gdy instancja została rozpoczęta.)

Jeśli ta pokazuje, że rzeczywiście mają ITL czeka, to INITRANS i parametry PCTFREE są głównymi gałki do skrętu (ale INITRANS = 100 brzmi dosyć wysoko, a one zajmują dużo miejsca).

Jeśli oczekiwania ITL nie stanowią problemu, należy sprawdzić kod aplikacji.

Answer 2

Najlepszym rozwiązaniem jest zwiększenie jej w razie potrzeby (rozpocznij od wartości domyślnej 10 i zwiększ wartość o 10). Jeśli widzisz zmniejszenie ITL czeka, jesteś ustawiony. Zazwyczaj te powiązane parametry są korygowane metodą prób i błędów zarówno w Oracle, jak i SQL Server. Dostosowanie tych parametrów w czasie rzeczywistym nie będzie stanowiło problemu, chyba że zasób jest bardzo zajęty. Można użyć następującej kwerendy, aby zobaczyć po każdym przyroście, jeśli ITL czeka albo odejdzie lub zostanie znacznie zredukowana:

SELECT t.OWNER, t.OBJECT_NAME, t.OBJECT_TYPE, t.STATISTIC_NAME, t.VALUE 
    FROM v$segment_statistics t 
    WHERE t.STATISTIC_NAME = 'ITL waits' AND t.VALUE > 0 
    ORDER BY t.value desc; 

Przeprowadziliśmy kilka strojów dla scenariuszy Oracle martwym powodu ITL czeka przy użyciu tej metody. UWAGA: Upewnij się, że indeks jest przebudowany, jeśli initrans jest zmodyfikowany dla indeksów. Upewnij się także, że statystyki nie są nieaktualne.

Aby uzyskać szybki przegląd, można skorzystać z Doradcy tuningu SQL, aby zobaczyć pełny stan kwerendy/indeksu i statystyk.