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