La requête est lente pour certains utilisateurs

11

J'ai quelques requêtes appelées à partir d'une application Web C # .NET qui sont toujours rapides pour moi (je suis un administrateur local sur SQL Server) mais pour un groupe d'utilisateurs (groupe de domaine avec les autorisations requises), la requête est incroyablement lente à le point qu'il expire dans l'application.

Qu'est-ce qui ferait que la même requête exacte s'exécuterait différemment pour différents utilisateurs?

Plus d'informations:

  • La requête est SQL en ligne dans le code C #, pas une procédure stockée
  • L'application utilise l'authentification de domaine et l'utilisateur et moi-même exécutons la requête via l'application
  • Il semble que le problème réside dans différents plans et que l'un ait été mis en cache, c'est pourquoi il était différent pour différents utilisateurs. Quelque chose affecte le cache car maintenant la requête est lente pour moi via l'application et rapide dans SQL Server Management Studio.
Supergibbs
la source
2
Vérifiez les questions suivantes . Vous pourriez trouver que vous êtes dans la même situation. Disons d'abord essayer celui-ci et cet autre .
Marian
3
Quels sont les types d'attente (sys.dm_os_waiting_tasks) sur la ou les requêtes lentes, et quels sont également les plans d'exécution réels de chacun (votre rapide, leur lent)?
Thomas Stringer
2
D'accord avec les commentaires précédents. Ma première pensée serait de renifler les paramètres aussi. Vérifier si les plans sont différents devrait être la première étape.
Martin Smith
4
Si les paramètres sont les mêmes (je suppose que c'est ce que l'on veut dire exact same query), cela ne devrait pas être un reniflement de paramètres (les utilisateurs obtiennent un mauvais plan pour le ou les mauvais paramètres), mais les utilisateurs obtiennent plutôt des plans différents pour le même paramètre (s). Cela peut être dû à des paramètres tels que quoted_identifieret arithabort, que vous pouvez comparer sys.dm_exec_sessionspour l'utilisateur rapide et l'utilisateur lent, ou cela peut être dû au fait qu'ils ont différents schémas par défaut et que les objets sont référencés sans le préfixe de schéma. Le reniflage de paramètres peut encore être impliqué (d'où la raison pour laquelle l'un d'eux a un mauvais plan).
Aaron Bertrand
1
RE: Votre édition avez-vous le même schéma par défaut que les autres utilisateurs? Avez-vous déjà capturé les plans d'exécution pour les exécutions lentes et rapides?
Martin Smith

Réponses:

5

Si les paramètres sont les mêmes (je suppose que c'est ce que l'on veut dire exact same query), cela ne devrait pas être un reniflement de paramètres (les utilisateurs obtiennent un mauvais plan pour le ou les mauvais paramètres), mais les utilisateurs obtiennent plutôt des plans différents pour le même paramètre (s). Cela peut être dû à des paramètres tels que quoted_identifieret arithabort, que vous pouvez comparer sys.dm_exec_sessionspour l'utilisateur rapide et l'utilisateur lent, ou cela peut être dû au fait qu'ils ont différents schémas par défaut et que les objets sont référencés sans le préfixe de schéma. Le reniflage de paramètres peut encore être impliqué (d'où la raison pour laquelle l'un d'eux a un mauvais plan).

Aaron Bertrand
la source
3

j'ai vu deux raisons à cela: 1, reniflement des paramètres 2, les paramètres de connexion sont différents. Si vous exécutez whoisactive , il vous montrera les différentes propriétés de connexion. J'ai en fait un article de blog à ce sujet, mais je n'ai pas nettoyé les informations spécifiques à l'entreprise. (je n'ai pas encore activé mon blog);)

rottengeek
la source
0

Essayez: Spécifiez le schéma sur chaque EXEC et référence de table. Par exemple, EXEC dbo.MyProc

Il pourrait y avoir des conflits (comme le suggère Martin Smith - «même schéma par défaut»?) Ou des recompilations

Kip Bryan
la source
0

Cela semble être un bogue dans SQL Server. Je rencontre ce bogue avec SQL Server 2008. Je n'ai pas testé de nouvelles versions. Je peux me connecter en tant qu'administrateur et exécuter cette requête et obtenir une réponse en 0 secondes:

select ROUTINE_NAME from INFORMATION_SCHEMA.ROUTINES ORDER BY ROUTINE_NAME

Ensuite, je me connecte en tant qu'utilisateur avec moins d'autorisations, exécute exactement la même requête et la réponse prend 45 secondes.

C'est constant encore et encore. Si je rebondis entre mes deux fenêtres de requête, une pour l'administrateur et une pour le non-administrateur, le non-administrateur prend toujours environ 45 secondes et l'administrateur prend 0 seconde.

Rob Kraft
la source
Comme demandé dans les commentaires de la question - les deux utilisateurs ont-ils la même base de données par défaut et les requêtes sont-elles exécutées dans la même base de données? Et, pouvez-vous indiquer une sorte de documentation qui indique qu'il s'agit d'un bogue, ou est-ce votre opinion? Ne pas dire que vous vous trompez, juste chercher quelque chose au-delà d'une anecdote.
RDFozz
Le problème que vous avez identifié dans votre réponse ne semble pas reproductible sur SQL Server 2008. select ROUTINE_NAME from INFORMATION_SCHEMA.ROUTINES ORDER BY ROUTINE_NAMErenvoie systématiquement des données immédiatement pour une connexion non SA sans aucun droit explicitement accordé.
Max Vernon