Procedura składowana wolna w przypadku wywołania z sieci WWW, szybka z Management Studio

Mam procedurę składowaną, która niesamowicie przekracza limit czasu za każdym razem, gdy jest wywoływana z aplikacji internetowej.

Uruchomiłem Sql Profiler i prześledziłem wywołania, które wygasły, i w końcu odkryłem następujące rzeczy:

1. Po wykonaniu instrukcji z poziomu MS SQL Management Studio, z tymi samymi argumentami (w rzeczywistości skopiowałem wywołanie procedury ze śledzenia profilu sql i uruchomiłem je): Kończy się średnio za 5 ~ 6 sekund.
2. Jednak wywołanie z aplikacji internetowej zajmuje ponad 30 sekund (w śledzeniu), więc moja strona internetowa faktycznie wygasa do tego czasu.

Poza tym, że moja aplikacja internetowa ma własnego użytkownika, wszystko jest takie samo (ta sama baza danych, połączenie, serwer itp.) Próbowałem również uruchomić zapytanie bezpośrednio w studio z użytkownikiem aplikacji internetowej i nie zajmuje to więcej niż 6 sek.

Jak dowiedzieć się, co się dzieje?

Zakładam, że nie ma to nic wspólnego z faktem, że używamy warstw BLL> DAL lub adapterów tabeli, ponieważ ślad wyraźnie pokazuje, że opóźnienie występuje w rzeczywistej procedurze. To wszystko, o czym mogę myśleć.

EDYCJA Dowiedziałem się z tego linku, że ADO.NET ustawia wartość ARITHABORTna true - co jest dobre przez większość czasu, ale czasami tak się dzieje, a sugerowanym obejściem jest dodanie with recompileopcji do przechowywanego proc. W moim przypadku to nie działa, ale podejrzewam, że jest to coś bardzo podobnego do tego. Czy ktoś wie, co jeszcze robi ADO.NET lub gdzie mogę znaleźć specyfikację?

W przeszłości miałem podobny problem, więc nie mogę się doczekać rozwiązania tego pytania. Komentarz Aarona Bertranda na temat OP doprowadził do przekroczenia limitu czasu Query podczas wykonywania z sieci, ale bardzo szybkiego w przypadku wykonywania z SSMS i chociaż pytanie nie jest powtórzeniem, odpowiedź może bardzo dobrze dotyczyć Twojej sytuacji.

Zasadniczo wygląda na to, że SQL Server może mieć uszkodzony plan wykonania w pamięci podręcznej. Uderzasz w zły plan ze swoim serwerem sieciowym, ale SSMS ląduje na innym planie, ponieważ jest inne ustawienie flagi ARITHABORT (która w przeciwnym razie nie miałaby wpływu na twoje konkretne zapytanie / przechowywane proc).

Zobacz ADO.NET wywołanie procedury składowanej T-SQL powoduje SqlTimeoutException dla innego przykładu z pełniejszym wyjaśnieniem i rozwiązaniem.

Doświadczam również, że zapytania działały powoli z sieci i szybko w SSMS i ostatecznie odkryłem, że problem był czymś, co nazywa się wykrywaniem parametrów.

Rozwiązaniem dla mnie była zmiana wszystkich parametrów używanych w sproc na zmienne lokalne.

na przykład. zmiana:

ALTER PROCEDURE [dbo].[sproc] 
    @param1 int,
AS
SELECT * FROM Table WHERE ID = @param1 

do:

ALTER PROCEDURE [dbo].[sproc] 
    @param1 int,
AS
DECLARE @param1a int
SET @param1a = @param1
SELECT * FROM Table WHERE ID = @param1a

Wydaje się dziwne, ale rozwiązało mój problem.

Nie po to, by spamować, ale jako miejmy nadzieję pomocne rozwiązanie dla innych, nasz system doświadczył wielu przekroczeń czasu.

Próbowałem ustawić procedurę składowaną do ponownej kompilacji przy użyciu sp_recompilei rozwiązało to problem z jednym SP.

Ostatecznie istniała większa liczba SP, które przekraczały limit czasu, z których wiele nigdy wcześniej tego nie robiło, przez używanie, DBCC DROPCLEANBUFFERSa DBBC FREEPROCCACHEwskaźnik przekroczenia czasu incydentu znacznie spadł - nadal istnieją odosobnione zdarzenia, niektóre, w których podejrzewam, że trwa regeneracja planu jakiś czas, a niektóre, w których PS są naprawdę słabe i wymagają ponownej oceny.

Czy może być tak, że niektóre inne wywołania bazy danych wykonane przed wywołaniem aplikacji internetowej, SP utrzymują transakcję otwartą? Może to być powód, dla którego ten SP musi czekać na wywołanie przez aplikację internetową. Mówię, że wyodrębnij połączenie w aplikacji internetowej (umieść je na nowej stronie), aby upewnić się, że przyczyną tego problemu jest jakieś wcześniejsze działanie w aplikacji internetowej.

Po prostu rekompilacja procedury składowanej (w moim przypadku funkcja tabeli) zadziałała

jak @Zane powiedział, że może to być spowodowane wykrywaniem parametrów. Doświadczyłem tego samego zachowania i przyjrzałem się planowi wykonania procedury i wszystkim oświadczeniom sp w wierszu (skopiowałem wszystkie instrukcje z procedury, zadeklarowałem parametry jako zmienne i przypisałem te same wartości do zmiennej jako parametry miały). Jednak plan wykonania wyglądał zupełnie inaczej. Wykonanie sp trwało 3-4 sekundy, a instrukcje z rzędu z dokładnie tymi samymi wartościami zostały natychmiast zwrócone.

Po pewnym googlowaniu znalazłem interesującą lekturę na temat tego zachowania: Wolno w aplikacji, Szybko w SSMS?

Podczas kompilowania procedury SQL Server nie wie, że wartość @fromdate się zmienia, ale kompiluje procedurę przy założeniu, że @fromdate ma wartość NULL. Ponieważ wszystkie porównania z NULL dają UNKNOWN, zapytanie nie może w ogóle zwrócić żadnych wierszy, jeśli @fromdate nadal ma tę wartość w czasie wykonywania. Jeśli SQL Server przyjmie wartość wejściową jako ostateczną prawdę, może skonstruować plan tylko ze stałym skanowaniem, które w ogóle nie ma dostępu do tabeli (uruchom zapytanie SELECT * FROM Orders WHERE OrderDate> NULL, aby zobaczyć przykład) . Ale SQL Server musi wygenerować plan, który zwraca poprawny wynik bez względu na wartość @fromdate w czasie wykonywania. Z drugiej strony nie ma obowiązku budowania planu, który jest najlepszy dla wszystkich wartości. Tak więc, ponieważ założono, że żadne wiersze nie zostaną zwrócone, SQL Server decyduje się na przeszukiwanie indeksu.

Problem polegał na tym, że miałem parametry, które można było pozostawić puste i jeśli zostałyby przekazane jako null, zostałyby zainicjalizowane z wartością domyślną.

create procedure dbo.procedure
    @dateTo datetime = null
begin
    if (@dateTo is null)
    begin
        select @dateTo  = GETUTCDATE()
    end

    select foo
    from dbo.table
    where createdDate < @dateTo
end

Po zmianie na

create procedure dbo.procedure
    @dateTo datetime = null
begin
    declare @to datetime = coalesce(@dateTo, getutcdate())

    select foo
    from dbo.table
    where createdDate < @to
end 

znowu zadziałało jak urok.