Przyczyna procesu będącego ofiarą impasu

Mam proces z Select, który zajmuje dużo czasu, w kolejności od 5 do 10 minut.
Obecnie nie używam NOLOCK jako wskazówki do silnika bazy danych MS SQL.
W tym samym czasie mamy inny proces, który dokonuje aktualizacji i wstawia do tej samej bazy danych i tych samych tabel.
Rozpoczął się pierwszy proces, który niedawno zakończył się przedwcześnie przekazem wiadomości

SQLEXCEPTION: transakcja została zablokowana na zasobach blokady z innym procesem i została wybrana jako ofiara zakleszczenia.

Ten pierwszy proces przebiega w innych witrynach w identycznych warunkach, ale z mniejszymi bazami danych, a zatem omawiana instrukcja select zajmuje znacznie krótszy okres czasu (rzędu około 30 sekund). W innych witrynach nie widzę komunikatu o zakleszczeniu w innych witrynach. Również nie dostałem tego komunikatu na stronie, na której początkowo występuje problem, ale zakładam, że wraz z rozrostem bazy danych, wydaje mi się, że przekroczyłem jakiś próg. Oto moje pytania:

1. Czy czas potrzebny na wykonanie transakcji może zwiększyć prawdopodobieństwo, że powiązany proces zostanie oflagowany jako ofiara zakleszczenia?
2. Jeśli wykonam selekcję ze wskazówką NOLOCK, czy spowoduje to usunięcie problemu?
3. Podejrzewam, że pole datetime, które jest sprawdzane jako część klauzuli WHERE w instrukcji select, powoduje powolny czas wyszukiwania. Czy mogę utworzyć indeks na podstawie tego pola? Czy to jest wskazane?

P1: Czy czas potrzebny na wykonanie transakcji może zwiększyć prawdopodobieństwo, że powiązany proces zostanie oznaczony jako ofiara zakleszczenia?

Nie. SELECT jest ofiarą, ponieważ miał tylko odczytane dane, dlatego transakcja wiąże się z niższym kosztem , więc zostaje wybrana jako ofiara:

Domyślnie aparat bazy danych wybiera jako ofiarę zakleszczenia sesję, w której odbywa się transakcja, której wycofanie jest najtańsze . Alternatywnie użytkownik może określić priorytet sesji w sytuacji zakleszczenia za pomocą SET DEADLOCK_PRIORITYinstrukcji. DEADLOCK_PRIORITY można ustawić na NISKI, NORMALNY lub WYSOKI, lub alternatywnie można ustawić dowolną wartość całkowitą w zakresie (od -10 do 10).

Q2. Jeśli wykonam selekcję ze wskazówką NOLOCK, czy spowoduje to usunięcie problemu?

Nie. Z kilku powodów:

• powinieneś najpierw spróbować właściwie wyeliminować zakleszczenie, badając pierwotną przyczynę
• brudne odczyty są niespójnymi odczytami .
• właściwym sposobem określenia brudnych odczytów jest użycie poziomów izolacji transakcji
• jest o wiele lepsze rozwiązanie: przeczytaj zatwierdzoną migawkę .

Pytanie 3. Podejrzewam, że pole datetime, które jest sprawdzane jako część klauzuli WHERE w instrukcji select, powoduje powolny czas wyszukiwania. Czy mogę utworzyć indeks na podstawie tego pola? Czy to jest wskazane?

Prawdopodobnie. Przyczyną zakleszczenia jest prawie bardzo prawdopodobne, że baza danych jest słabo zindeksowana. 10 minut zapytań jest akceptowalnych w tak wąskich warunkach, że jestem w 100% pewien, że w twoim przypadku jest to nie do przyjęcia.

Z 99% pewnością oświadczam, że zakleszczenie jest spowodowane dużym skanowaniem tabeli, które powoduje konflikt z aktualizacjami. Zacznij od uchwycenia wykresu zakleszczenia, aby przeanalizować przyczynę. Najprawdopodobniej będziesz musiał zoptymalizować schemat swojej bazy danych. Przed wprowadzeniem jakichkolwiek modyfikacji przeczytaj ten temat Projektowanie indeksów i artykuły podrzędne.

Oto, w jaki sposób ten konkretny problem z zakleszczeniem faktycznie wystąpił i jak został faktycznie rozwiązany. Jest to dość aktywna baza danych, w której codziennie występuje 130 tys. Transakcji. Indeksy w tabelach w tej bazie danych były pierwotnie zgrupowane. Klient zażądał, aby indeksy nie były klastrowane. Tak szybko, jak to zrobiliśmy, rozpoczął się impas. Kiedy ponownie ustanowiliśmy indeksy jako klastrowe, impas ustał.

Warto spróbować odpowiedzi, ale powinieneś także przejrzeć swój kod. W szczególności przeczytaj odpowiedź Polyfuna: Jak pozbyć się zakleszczenia w SQL Server 2005 i aplikacji C #?

Wyjaśnia problem współbieżności i jak użycie "with (updlock)" w zapytaniach może poprawić sytuację zakleszczenia - w zależności od tego, co dokładnie robi twój kod. Jeśli twój kod jest zgodny z tym wzorcem, jest to prawdopodobnie lepsze rozwiązanie przed uciekaniem się do brudnych odczytów itp.

Chociaż @ Remus Ruşanu „s jest już odpowiedź doskonała, w jednym przypadku oczekuje lepszy wgląd w SQL Server Deadlock przyczyn i strategie śladowe, proponuję czytać Brad McGehee ” s Jak wyśledzić zakleszczenia przy użyciu programu SQL Server 2005 Profiler