MS SQL - proirytety przy deadlock

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.

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.

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ć?

0

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

0

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

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


 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)

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0