Zapytanie jest powolne dla niektórych użytkowników

11

Mam kilka zapytań wywoływanych z aplikacji sieci Web C # .NET, które są dla mnie zawsze szybkie (jestem lokalnym administratorem na serwerze SQL), ale dla grupy użytkowników (grupa domen z wymaganymi uprawnieniami) zapytanie jest bardzo wolne moment, w którym upływa limit czasu w aplikacji.

Co spowodowałoby, że dokładnie to samo zapytanie działałoby inaczej dla różnych użytkowników?

Więcej informacji:

Zapytanie to wbudowany SQL w kodzie C #, a nie procedura składowana
Aplikacja korzysta z uwierzytelniania domeny, a ja i użytkownik uruchamiamy zapytanie za pośrednictwem aplikacji
Wygląda na to, że problem dotyczy różnych planów i jeden został zapisany w pamięci podręcznej, dlatego był inny dla różnych użytkowników. Coś wpływa na pamięć podręczną, ponieważ teraz zapytanie jest dla mnie wolne przez aplikację i szybkie w SQL Server Management Studio.

— Supergibbs
źródło

2

Sprawdź następujące pytania . Może się okazać, że jesteś w tej samej sytuacji. Powiedzmy, że najpierw spróbuj tego i tego drugiego .

— Marian

3

Jakie są typy oczekiwania (sys.dm_os_waiting_tasks) dla powolnego zapytania (zapytań), a także jakie są rzeczywiste plany wykonania każdego (twojego postu, ich powolności)?

— Thomas Stringer

2

Zgadzam się z poprzednimi komentarzami. Moją pierwszą myślą było też wąchanie parametrów. Pierwszym krokiem powinno być sprawdzenie, czy plany są różne.

— Martin Smith

4

Jeśli parametry są takie same (zakładam, że o to chodzi exact same query), nie powinno to być wąchanie parametrów (użytkownicy otrzymują zły plan dla niewłaściwych parametrów), ale użytkownicy otrzymują różne plany dla tego samego parametru (s). Może to być spowodowane ustawieniami, takimi jak quoted_identifieri arithabort, które można porównać sys.dm_exec_sessionsdla szybkiego i powolnego użytkownika, lub może to być spowodowane tym, że mają różne domyślne schematy, a obiekty są przywoływane bez prefiksu schematu. Wciąż może być zaangażowane wąchanie parametrów (dlatego dlaczego jeden z nich ma zły plan).

— Aaron Bertrand

1

RE: Czy w swojej edycji masz taki sam domyślny schemat, jak inni użytkownicy? Czy uchwyciłeś już plany wykonania dla wolnych i szybkich przebiegów?

— Martin Smith

5

Jeśli parametry są takie same (zakładam, że o to chodzi exact same query), nie powinno to być wąchanie parametrów (użytkownicy otrzymują zły plan dla niewłaściwych parametrów), ale użytkownicy otrzymują różne plany dla tego samego parametru (s). Może to być spowodowane ustawieniami, takimi jak quoted_identifieri arithabort, które można porównać sys.dm_exec_sessionsdla szybkiego i powolnego użytkownika, lub może to być spowodowane tym, że mają różne domyślne schematy, a obiekty są przywoływane bez prefiksu schematu. Wciąż może być zaangażowane wąchanie parametrów (dlatego dlaczego jeden z nich ma zły plan).

— Aaron Bertrand
źródło

3

Widziałem dwa powody tego: 1, wąchanie parametru 2, ustawienia połączenia są różne. Jeśli uruchomisz whoisactive , pokażą ci różne właściwości połączenia. Mam blog na ten temat, ale nie wyczyściłem z niej informacji specyficznych dla firmy. (nie mam jeszcze włączonego mojego bloga);)

— rottengeek
źródło

0

Spróbuj: Określ schemat dla każdego EXEC i odwołania do tabeli. Np. EXEC dbo.MyProc

Mogą wystąpić konflikty (jak sugeruje Martin Smith - „ten sam domyślny schemat”?) Lub rekompilacja

— Kip Bryan
źródło

0

To wydaje się być błędem w SQL Server. Ten błąd występuje w SQL Server 2008. Nie testowałem nowych wersji. Mogę zalogować się jako administrator i uruchomić to zapytanie i uzyskać odpowiedź w 0 sekund:

select ROUTINE_NAME from INFORMATION_SCHEMA.ROUTINES ORDER BY ROUTINE_NAME

Następnie loguję się jako użytkownik z mniejszą liczbą uprawnień, uruchamiam dokładnie to samo zapytanie, a odpowiedź trwa 45 sekund.

Jest to konsekwentne w kółko. Jeśli odbijam się między moimi dwoma oknami zapytania, jednym dla administratora i jednym dla nie-administratora, nie-administrator zawsze zajmuje około 45 sekund, a administrator 0 sekund.

— Rob Kraft
źródło

Jak zadano w komentarzach do pytania - czy obaj użytkownicy mają tę samą domyślną bazę danych i czy zapytania są wykonywane w tej samej bazie danych? I czy możesz wskazać jakąś dokumentację stwierdzającą, że jest to błąd, czy to Twoja opinia? Nie mówię, że się mylisz, po prostu szukasz czegoś poza anegdotą.

— RDFozz

Problem zidentyfikowany w odpowiedzi wydaje się nie być powtarzalny w SQL Server 2008. select ROUTINE_NAME from INFORMATION_SCHEMA.ROUTINES ORDER BY ROUTINE_NAMEkonsekwentnie zwraca dane natychmiast dla logowania innego niż SA, które nie ma żadnych praw do przyznania jawności.

— Max Vernon