Sławomir Bryś

Software Developer / Solution Architect

Wypowiedzi

• Wszystko
• Tylko fora

• 
  Wpis na grupie Bazy Danych w temacie MS SQL Server 2008 R2 - deadlocks

  25.01.2012, 23:09

  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