MS SQL - proirytety przy deadlock

MS SQL - proirytety przy deadlock
AN
  • Rejestracja:około 19 lat
  • Ostatnio:około 9 godzin
0

Czasami przy próbie wykonania polecenia update zdarza się taki komunikat od serwera MS SQL 2008 R2
Transaction (Process ID 99) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Rozumiem, że żeby było zakleszczenie, to muszą być co najmniej dwa procesy, jeżeli serwer MS SQL wykryje zakleszczenie, to zabija przynajmniej jeden proces, żeby zakleszczenie przestało zachodzić.

Oczywiście najlepiej jest jeszcze raz zaprojektować bazę danych i logikę biznesową, żeby nie zachodziły warunki, w których dochodzi do zakleszczeń.

Czy w zapytaniach SQL istnieje jakaś klauzula lub parametr, który określa wyższy lub niższy priorytet?

Chodzi o to, że mam zapytanie A i zapytanie B, które często są uruchamiane naraz i mogą powodować zakleszczenie. Chodzi o to, żeby za każdym razem bez wyjątku serwer SQL przy zakleszczeniu zabijał zapytanie B, a zapytanie A zostało wykonane. W tym przypadku zapytannie A ma jakby wyższy priorytet niż B. Oczywiście, jak nie wystąpi zakleszczenie, to wykonają się oba zapytania.

ML
  • Rejestracja:prawie 20 lat
  • Ostatnio:około 17 godzin
  • Postów:858
0

Przy selektach można dodawać WITH(NOLOCK), co eliminuje takie zakleszczenia. Istnieje wtedy ryzyko pobrania nie do końca poprawnych danych ale jest ono znikome. Jeżeli nie robisz krytycznego systemu bankowego to to powinno pomóc.

AN
  • Rejestracja:około 19 lat
  • Ostatnio:około 9 godzin
0
MiL napisał(a):

Przy selektach można dodawać WITH(NOLOCK), co eliminuje takie zakleszczenia. Istnieje wtedy ryzyko pobrania nie do końca poprawnych danych ale jest ono znikome. Jeżeli nie robisz krytycznego systemu bankowego to to powinno pomóc.

Nie robię systemu bankowego ani kosmicznego. Select, to jeszcze nie problem. Gorzej, jeżeli oba procesy chcą zrobić update/insert/delete. Czy wtedy można coś podobnego z tym zrobić?

abrakadaber
abrakadaber
  • Rejestracja:ponad 12 lat
  • Ostatnio:8 miesięcy
  • Postów:6610
0

Chcesz pomocy - pokaż kod - abrakadabra źle działa z techniką.
ML
  • Rejestracja:prawie 20 lat
  • Ostatnio:około 17 godzin
  • Postów:858
0

Dla update możesz użyć WITH (ROWLOCK). To spowoduje że zablokowany zostanie tylko wiersz updatowany a nie cała tabela.

Zobacz pozostały 1 komentarz
ML
Domyślne nie jest, ale silnik bazy danych może sam zdecydować o użyciu takiej blokady. Tak samo użycie tego hintu to tylko sugestia dla silnika że powinien używać takich blokad, ale nie zawsze musi tego posłuchać.
WL
@abrakadaber Nie do końca; LockManager sam decyduje o tym, czy blokada ma być na poziomie wiersza, strony czy tabeli. Dodanie wskazówki WITH (ROWLOCK) to jedynie sugestia dla LockManagera, aby blokował na poziomie strony - ale i tak sam zdecyduje o poziomie ziarnistości blokad. Domyślnie jest tak, że LockManager decyduje o eskalacji blokad i jeśli np. polecenie UPDATE blokuje więcej niż 25 wierszy, to następuje eskalacja blokady na stronę - bo tak jest szybciej.
bielaPL
A co z forceorder?
ML
A co to ma wspólnego z blokadami?
bielaPL
Fakt, myślałem, że można forcem wymusić ale on raczej na indeksy działa... mój błąd
woolfik
  • Rejestracja:ponad 17 lat
  • Ostatnio:około 16 godzin
  • Postów:1597
0

Nie jestem pewien jak na MS SQL ale na oraclu możesz użyć klauzuli

Kopiuj
FOR UPDATE, FOR UPDATE NOWAIT lub FOR UPDATE WAIT xxx

gdzie podajesz określony czas. Z insertrem raczej problemu nie powinno być (przeważnie bo też się da uzyskać deadlocka) ale dla update robisz wcześniej select * from tabela for update wait 10

Kopiuj
 i jeśli inna transakcja przez 10 sekund nie zwolni rekordu to update z aktualnej transakcji się nie wykona dzięki czemu nie będzie deadlocka. Nie mniej jednak widziałem bazy danych gdzie nawet takie zabezpieczenie nie pomoże (ale niestety jest to przykład źle zaprojektowanej bazy)

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.