Problem z SQL Azure.

Mam problem, który występuje jako następujący wyjątek w naszej witrynie (asp.net):

Limit czasu upłynął. Limit czasu, który upłynął przed zakończeniem operacji lub serwer nie odpowiada. Oświadczenie zostało zakończone.

Powoduje również aktualizację i wstawianie instrukcji nigdy nie kończących się w SMSS. Podczas zapytania nie ma żadnych blokad X lub IX:sys.dm_tran_locks i nie ma żadnych transakcji podczas kwerendysys.dm_tran_active_transactions lubsys.dm_tran_database_transactions.

Problem występuje dla każdej tabeli w bazie danych, ale inne bazy danych w tej samej instancji nie powodują problemu. Czas trwania problemu może wynosić od 2 minut do 2 godzin i nie występuje o określonej porze dnia.

Baza danych nie jest pełna.

W pewnym momencie ten problem sam się nie rozwiązał, ale udało mi się rozwiązać ten problem, wysyłając zapytaniesys.dm_exec_connections znalezienie najdłuższej działającej sesji, a następnie zabicie jej. Dziwne jest to, że połączenie miało 15 minut, ale problem blokady był obecny przez ponad 3 godziny.

Czy mogę jeszcze coś sprawdzić?

EDYTOWAĆ

Zgodnie z odpowiedzią Pawła poniżej. Właściwie wyśledziłem problem, zanim odpowiedział. Poniżej zamieszczę kroki, które posłużyły mi do rozwiązania tego problemu, na wypadek, gdyby pomogły komuś innemu.

Następujące zapytania zostały uruchomione, gdy obecny był „limit czasu”.

select *  from sys.dm_exec_requests

Jak widzimy, wszystkie żądania WAIT czekają na sesji 1021, która jest żądaniem replikacji! TheTM Request wskazuje transakcję DTC i nie korzystamy z transakcji rozproszonych. Możesz także zobaczyć typ wait_tySE_REPL_COMMIT_ACK co ponownie implikuje replikację.

select * from  sys.dm_tran_locks

Ponownie czeka na sesję 1021

SELECT * FROM sys.dm_db_wait_stats ORDER BY wait_time_ms desc

I tak,SE_REPL_CATCHUP_THROTTLE ma łączny czas oczekiwania 8094034 ms, czyli 134,9 minut !!!

Zobacz także następujące forum, aby uzyskać szczegółowe informacje na temat tego problemu.http://social.technet.microsoft.com/Forums/en-US/ssdsgetstarted/thread/c3003a28-8beb-4860-85b2-03cf6d0312a8

W mojej komunikacji z Microsoftem otrzymałem następującą odpowiedź (widzieliśmy ten problem w 4 z naszych 15 baz danych w centrum danych UE):

Pytanie: Czy w ciągu ostatnich trzech tygodni nastąpiły zmiany w tych ograniczeniach miękkiego dławienia, tj. Od kiedy zaczęły się moje problemy?

Odpowiedź: Nie, nie ma.

Pytanie: Czy istnieją sposoby zapobiegania lub ostrzegania, że ​​zbliżamy się do limitu?

Odpowiedź: Nie. Problem może nie być spowodowany przez aplikację, ale może być spowodowany przez innych najemców, którzy korzystają z tego samego sprzętu fizycznego. Innymi słowy, aplikacja może mieć bardzo małe obciążenie i nadal napotykać problem. Innymi słowy, własny ruch może być przyczyną tego problemu, ale równie dobrze może być spowodowany przez innych najemców, którzy polegają na tym samym fizycznym sprzęcie. Nie ma możliwości wcześniejszego dowiedzenia się, że problem wkrótce wystąpi - może wystąpić w dowolnym momencie bez ostrzeżenia. Zespół operacyjny SQL Azure nie monitoruje tego typu błędów, więc nie spróbuje automatycznie rozwiązać problemu. Więc jeśli napotkasz na to, masz dwie opcje:

Utwórz kopię swojej bazy danych i użyj jej, i miej nadzieję, że db zostanie umieszczony na innym serwerze z mniejszym obciążeniem.

Skontaktuj się z pomocą techniczną Windows Azure i poinformuj o problemie i pozwól im wykonać dla Ciebie opcję 1