Właśnie tego nauczyłem się do tej pory z moich badań.
.NET wysyła ustawienia połączenia, które nie są takie same, jak te, które otrzymujesz po zalogowaniu się do Management Studio. Oto, co zobaczysz, jeśli podsłuchasz połączenie za pomocą Sql Profiler:
-- network protocol: TCP/IP
set quoted_identifier off
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls off
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read committed
Teraz wklejam te ustawienia powyżej każdego zapytania, które uruchamiam po zalogowaniu się do serwera sql, aby upewnić się, że ustawienia są takie same.
W tym przypadku wypróbowałem każde ustawienie osobno, po rozłączeniu i ponownym połączeniu, i stwierdziłem, że zmiana arithabortu z wyłączonego na włączony zmniejszyła problem z 90 sekund do 1 sekundy.
Najbardziej prawdopodobne wyjaśnienie dotyczy sniffingu parametrów, który jest techniką używaną przez Sql Server do wybierania tego, co uważa za najbardziej efektywny plan zapytań. Gdy zmienisz jedno z ustawień połączenia, optymalizator zapytań może wybrać inny plan, aw tym przypadku najwyraźniej wybrał zły.
Ale nie jestem o tym do końca przekonany. Próbowałem porównać rzeczywiste plany zapytań po zmianie tego ustawienia i jeszcze nie widziałem, aby różnica zawierała jakiekolwiek zmiany.
Czy jest coś jeszcze w ustawieniu algorytmu arithabor, które w niektórych przypadkach może powodować powolne działanie zapytania?
Rozwiązanie wydawało się proste:po prostu umieść zestaw arithabort na górze procedury składowanej. Ale może to prowadzić do odwrotnego problemu:zmienić parametry zapytania i nagle działa szybciej z 'off' niż 'on'.
Na razie uruchamiam procedurę „z rekompilacją”, aby upewnić się, że plan zostanie za każdym razem zregenerowany. W przypadku tego konkretnego raportu jest OK, ponieważ ponowna kompilacja może zająć sekundę, a nie jest to zbyt widoczne w przypadku raportu, który zwraca 1-10 sekund (to potwór).
Ale nie jest to opcja dla innych zapytań, które są uruchamiane znacznie częściej i muszą powrócić tak szybko, jak to możliwe, w ciągu zaledwie kilku milisekund.
