Kod przyczyny 68 informuje już, że jest to spowodowane przekroczeniem limitu czasu blokady (zakleszczenie to kod przyczyny 2) Może to być spowodowane tym, że inni użytkownicy uruchamiają zapytania w tym samym czasie, w którym używają tych samych danych, do których użytkownik uzyskuje dostęp, lub własne wiele aktualizacji.
Zacznij od uruchomienia db2pd -db locktest -locks show detail z wiersza komend db2, aby zobaczyć, gdzie znajdują się blokady. Następnie należy uruchomić coś takiego:
select tabschema, tabname, tableid, tbspaceid
from syscat.tables where tbspaceid = # and tableid = #
wypełnieniu # symboli z numerem identyfikacyjnym można uzyskać z wyjścia polecenia db2pd.
Po zobaczyć, gdzie są zamki, oto kilka wskazówek:
częstotliwość ◦Deadlock może być czasami zmniejszone poprzez zapewnienie, że wszystkie wnioski o dostęp do swoich wspólnych danych w tej samej kolejności - sposób, na przykład, że dostęp (i dlatego zablokuj) wiersze w tabeli A, a następnie w tabeli B, a następnie w tabeli C i tak dalej.
zaczerpnięte z: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.trb.doc/doc/t0055074.html
zalecana literatura: http://www.ibm.com/developerworks/data/library/techarticle/dm-0511bond/index.html
Addendum: jeśli serwlet lub inny winny aplikacja jest przy użyciu znalezionych być zaangażowane w impasu select wypowiedzi, można spróbować dołączanie with ur do wybranych wypowiedzi jeśli dokładność nowo zaktualizowanych (lub wstawionych) danych nie jest ważna.
Należy zauważyć, że artykuł mówi o ** zmniejszeniu ** częstotliwości występowania zakleszczeń, a nie ** zapobieganiu ** ich całkowicie. Zgodnie z http://stackoverflow.com/a/112256/14731 konsekwentna kolejność blokowania nie zapobiega zakleszczeniom. Możemy maksymalnie ograniczyć ich częstotliwość. – Gili