Jaki może być możliwy powód tego typu zakleszczenia? (ogólnie brak impasu)
Zablokuj zasoby bufora komunikacji
Czy wskazany system ma mało pamięci i skończyła się liczba buforów?
Szczegółowy błąd:
Transakcja (ID procesu 59) została zablokowana w zasobach bufora komunikacyjnego blokady z innym procesem i została wybrana jako ofiara impasu. Uruchom ponownie transakcję
Odpowiedzi:
Pełny komunikat, który jest często widziany:
Transakcja (ID procesu 53) została zablokowana na blokadzie | zasoby bufora komunikacji z innym procesem i został wybrany jako ofiara impasu. Uruchom ponownie transakcję.
Ten typ blokady jest powszechnie postrzegany w przypadku zapytań zakleszczonych, które SQL Server wykonał równolegle, czasami nazywanych „równoległymi zakleszczeniami wewnątrz zapytania”. Widziałem kilka stwierdzeń, że to również wskazuje, że zasoby systemowe są niskie, co, jak sądzę, może być w niewielkim stopniu zaangażowane.
Ogólną wskazówką, którą zauważyłem w celu ustalenia, czy jest to impas równoległy, jest wyciągnięcie wykresu zakleszczenia XML (co można zrobić z sesją system_health w 2008 roku i wyżej), zauważysz różne identyfikatory procesów pokazujące ten sam bit kodu w stos wykonania.
Również patrząc na listę zasobów wykresu zakleszczenia i zauważając typ zdarzenia kelnera. Najczęściej będą wyświetlać „e_xxxxxx” lub coś takiego:
<waiter-list>
<waiter event="e_waitPipeGetRow" type="consumer" id="process821d828" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process8209198" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process3827c18" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process3809eb8" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process8226b08" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process9acb6d8" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process6188d7828" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process381cef8" />
</waiter-list>
Aby spróbować rozwiązać problem, różne ścieżki są dostępne online i w książkach. Zasadniczo zaczynam od spojrzenia na plan wykonania zapytania / procedury i skupiam się na obszarach pokazujących równoległe wykonywanie. Następnie przejdź najpierw do dostrojenia zapytania, a następnie w ostateczności możesz zacząć korzystać ze wskazówek dotyczących zapytań.
Najczęstszą wskazówką dotyczącą zapytań w celu rozwiązania tych zakleszczeń jest implementacja MAXDOP 1. Jednak zanim to zrobisz, możesz sprawdzić, na jakim poziomie serwera ustawiony jest MAXDOP i próg kosztów. Próg kosztów jest zazwyczaj domyślnie ustawiony na 5 i chciałbym podnieść go do 35 lub 40 na początek, jeśli dane zapytanie ma niski koszt dla tej sekcji kodu, może nie być konieczne równoległe jego uruchamianie. Nie przepadam za używaniem wskazówek do zapytań MAXDOP, ale to nie znaczy, że nie mają swojego miejsca i celu. tylko moja opinia.