GoldenLine
Zaloguj się
Sławomir Bryś

Sławomir Bryś Software Developer /
Solution Architect

Temat: MS SQL Server 2008 R2 - deadlocks

Witam,

Czy ktoś zna może jakieś sprytne podejście do deadlock'ów na bazie danych MS SQL Server 2008 R2? Oczekuję konkretów, nietuzinkowych pomysłów, wszystko poza:
#1. zmianą poziomu izolacji na read uncommitted ("brudne" dane nie są akceptowalne)
#2. brakiem lock'ownia obiektów przy czytaniu/aktualizacji (j.w.)
#3. łapaniem wyjątku i obsługa procedury raz jeszcze (coś a la "za drugim razem się uda)
#4. blokowaniem na wyłączność obiektów (system online'owy, nie da rady)
#5. przepisaniem całego kodu od początku (duży system, nie da rady)

Temat nie jest prosty, to chyba każdy wie. Jestem świadomy, że deadlock'ów zupełnie się nie pozbędę, ale chciałbym je wyeliminować w jak największym stopniu. Oprócz tego, co znalazłem w MSDN i na necie, mam inne pomysły:
#1. update lock - nie blokować na wyłączność, aczkolwiek i tak shared lock'a nie założę, ale może jest jakaś 'luka', która pozwoli blokować do aktualizacji, ale nie do odczytu (wada to możliwość odczytania nieaktualnych danych)
#2. brak blokad przy czytaniu, ale nie mogą to być "brudne" dane (snapshot isolation level?)
#3. zagnieżdżone transakcje - jak wpłyną na blokady na poszczególnym poziomie transakcji i jak poprawnie zarządzać wyjątkami -> do sprawdzenia
#4. osobna tabela z identyfikatorami blokowanych wierszy (coś a la bariery/semafory), w celu analizy, czy można założyć blokadę IS na dane, które w późniejszych krokach będziemy aktualizowali
#5. zmiana podejścia w logice - najpierw wszystkie select'y, na koniec wszystkie update'y (logicznie trudne do realizacji -> zagnieżdżone procedury)
#6. procedury CLR -> powinny mieć ten sam poziom izolacji, w dodatku pewnie hit na wydajności

Jak ktoś coś wie, proszę o komentarze.

Pozdrawiam
Link do wypowiedziLink
Paweł B.

Paweł B. architekt baz danych
/ SQL Developer /BI
Developer

Temat: MS SQL Server 2008 R2 - deadlocks

Z Twoich pomysłów
#2 jest najtańszy do sprawdzenia, pstryk i masz. Ale może mieć ogólny negatywny wpływ na wydajność.
Jeśli wiesz gdzie powstają deadlocki to sprawdź #3 i zapoznaj się z marked transaction.

Nic nie napisałeś o aplikacji a to tam może tkwić problem.
Link do wypowiedziLink

konto usunięte

Temat: MS SQL Server 2008 R2 - deadlocks

Sławomir Bryś:
Witam,

Czy ktoś zna może jakieś sprytne podejście do deadlock'ów na bazie danych MS SQL Server 2008 R2? Oczekuję konkretów, nietuzinkowych pomysłów

Nic tylko... zatrudnić konsultanta. Się płaci - ma się oczekiwania.
Link do wypowiedziLink

konto usunięte

Temat: MS SQL Server 2008 R2 - deadlocks

Nic tylko... zatrudnić konsultanta. Się płaci - ma się oczekiwania.

:)

Myślę, że taka 'Loża ekspertów Golden Line' mogła by zarobić dużo pieniążków pomagać osobom które nikomu wcześniej nie pomogły (brak wartościowych wypowiedzi albo w ogóle wypowiedzi).

Hm ... Chyba założę nowe forum ;)
Link do wypowiedziLink

konto usunięte

Temat: MS SQL Server 2008 R2 - deadlocks

Witam,

Czy ktoś zna może jakieś sprytne podejście do deadlock'ów na [...]

Jak ktoś coś wie, proszę o komentarze.


Eh... znowu doradzam konsultantom :)

1. Wykorzystaj w selektach WITH (ROWLOCK / HOLDLOCK)

2. Przyspiesz bazę danych (szybsze dyski, więcej pamięci, mocy obliczeniowej, maszyn), ogranicz ilość zapytań do bazy w jednostce czasu, zoptymalizuj zapytania / schemat.

3. Musisz zrozumieć, że nie istnieje nieblokujący mechanizm lock który pozwalałby na pobieranie zawsze aktualnych danych. Ostatecznie wszystkie dane jakie pobierasz z bazy są z przeszłości (ostatecznie - nie dotrą one do klienta szybciej niż światło ;) a więc potencjalnie są nieaktualne w momencie ich wyświetlania.Jakub Wojt edytował(a) ten post dnia 28.01.12 o godzinie 14:22
Link do wypowiedziLink

konto usunięte

Temat: MS SQL Server 2008 R2 - deadlocks

Jakub Wojt:
Ostatecznie wszystkie dane jakie pobierasz z bazy są z przeszłości (ostatecznie - nie dotrą one do klienta szybciej niż światło ;) a więc potencjalnie są nieaktualne w momencie ich wyświetlania.

To jest piękne... myślę, że taki konsultant powinien dostać bonus.
Link do wypowiedziLink

konto usunięte

Temat: MS SQL Server 2008 R2 - deadlocks

Michał Z.:
Jakub Wojt:
Szymon Guz:

Trzy posty o kompletnie Niczym (Jakub się obronił bo jednak dał odpowiedź :-) ) tylko dlatego że kolega ma w dośw wpisane że jest konsultantem... wstyd :p (to pokazuje dlaczego pytania powinny być kierowane na Stack Overflow, a nie tutaj).

Co do odpowiedzi:

1. Podejście #2 wydaje się ok, jeśli nie chcesz mieć brudnych danych wykorzystaj (HOLDLOCK, ROWLOCK), z tym że należy pamiętać że jeśli będzie to operacja na wielu rekordów to Server i tak zablokuje stronę, bądź co gorsza założy bardzo wiele pojedynczych blokad na rekord.

2. #4 ok pod warunkiem że zaimplementujesz mechanizm czekania, w zależności od potrzeby może to być mechanizm w samej bazie danych jak i poza nią -> Podejście jest nie łatwe do zrobienia poprawnie, i często kończy się tym że w całej bazie danych mamy logiczne blokady i każdy czeka na każdego.

3. Podejście z formalizacją operacji (najpierw selecty, potem operacje zapisu), zazwyczaj pomaga ograniczyć blokady.

4. Ograniczyć do minimum moment blokady, co wiąże się z analizą oraz przebudową systemu bądź części systemu, inaczej się nie da.
Link do wypowiedziLink

konto usunięte

Temat: MS SQL Server 2008 R2 - deadlocks

Bartosz Adamczewski:
Michał Z.:
Jakub Wojt:
Szymon Guz:

Trzy posty o kompletnie Niczym (Jakub się obronił bo jednak dał odpowiedź :-) ) tylko dlatego że kolega ma w dośw wpisane że jest konsultantem... wstyd :p (to pokazuje dlaczego pytania powinny być kierowane na Stack Overflow, a nie tutaj).
Jakie informacje się podaje - takiej odpowiedzi można oczekiwać.
To po pierwsze. Jak ktoś sobie nie radzi z podstawowym problemem,
do tego ma jeszcze oczekiwania - niech komuś zapłaci. I to jest
odpowiedź o niczym?

Całość dyskusji jest o wróżeniu z fusów. Równie dobrze system
może być optymalnie skonfigurowany i trzeba poprawić hardware -
co nieoptymalny kod psuje wszystko. Nawet nie wiadomo, czy
jakaś logika jest po stronie bazy.

Na tym poziomie abstrakcji, zakładając, że chodzi o software:
- skrócenie czasu trwania transakcji,
- zagwarantowanie wykonywania operacji w dokładnie takiej
samej kolejności.
No, ale miały być konkrety, nie oczywistości.

Co do locków - ciekawe jak się ma clustered index do tego...
Link do wypowiedziLink
Bartosz Ślepowronski

Bartosz Ślepowronski Problem? Jaki
problem?

Temat: MS SQL Server 2008 R2 - deadlocks

Dla mnie bez sensu jest pytanie o rozwiązanie bez przeprowadzania analizy problemu. Deadlocki skąś się biorą, zależnie od tego skąd metody radzenia sobie z nimi będą takie lub inne.

To trochę jak rozwiązywanie problemów z wydajnością bazy za pomocą upgradu hardwaru. Jasne, można, ale czy trzeba?

Więc może prościej sprawdzić jaki kod powoduje deadlocki i po prostu go poprawić?
Link do wypowiedziLink

konto usunięte

Temat: MS SQL Server 2008 R2 - deadlocks

Bartosz Ślepowronski:
Więc może prościej sprawdzić jaki kod powoduje deadlocki i po prostu go poprawić?

ale to jest o rząd wielkości trudniejsze niże proponowane rozwiązania, a tu nie chodzi o finezję tylko o to żeby działało, później to niech się martwi ktoś inny
Link do wypowiedziLink
Adam Blada

Adam Blada Senior IT Specialist

Temat: MS SQL Server 2008 R2 - deadlocks

Nie wiem czy to jeszcze Cie interesuje ale jeśli to możliwe to czytanie danych np raportowych ze Snapshot-a bazy było by jakimś rozwiązaniem może takim jakiego szukasz :)
Link do wypowiedziLink
Krzysztof Raczkowski

Krzysztof Raczkowski Stała współpraca,
Logifact-Systems Sp.
z o.o.

Temat: MS SQL Server 2008 R2 - deadlocks

Dorzucę parę swoich przemyśleń http://proitsoft.com.pl/deadlocks_postgresql_mssql.html

Nie wyczerpuje to tematu pewnie bo deadlocks w ms sql były są i będą ze względu na taką a nie inną architekturę tego silnika

Temat trudny i proponuję też zaprzyjaźnić się z SQL Profiler
Link do wypowiedziLink
Marek Dziekański

Marek Dziekański Consultant /
Developer, Consafe
Logistics Sp. z o.
o.

Temat: MS SQL Server 2008 R2 - deadlocks

Być może to banały, ale dorzucę, być może komuś się przyda...

unikanie deadlockow:
1). Krótkie transakcje - oczywistość, im krócej tym...krócej a więc mniejsze prawdopodobnienstwo deadlocka.

2). Kolejność operacji: jeżeli w jednej transakcji najpierw wykonujem operacje na tabeli A a potem na tabeli B to jeżeli to możliwe dobrze jest się tej konwencji trzymać we wszystkich transakcjach - unikając kolejności B A. Wtedy unikamy sytuacji ze jedna transakcja blokuje tabele A a druga podobna w tym czasie tabele B. Niby mala rzecz a może ucieszyć.

3). Warto też się zastanowić nad poziomem izolacji transakcji. Być może czasami trzeba sięgnąć do REPETEABLE READ czy SERIALIZABLE zamiast domyślnej READ COMMITED.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy





Wyślij zaproszenie do
Anuluj