La procédure stockée échoue sur un utilisateur spécifique

Question

J'ai une procédure stockée qui échoue constamment avec le message d'erreur "Timeout expired" sur un utilisateur spécifique.

Tous les autres utilisateurs peuvent invoquer le sp très bien, et même je suis capable d'invoquer le sp normalement en utilisant l'Analyseur de requêtes - il se termine en seulement 10 secondes. Toutefois, avec l'utilisateur en question, les journaux montrent que l'ASP se bloque toujours pendant environ 5 minutes, puis interrompt avec un délai d'expiration.

j'invoque la page ASP comme si « EXEC SP_TV_GET_CLOSED_BANKS_BY_USERS '006111' »

Tout le monde sait comment diagnostiquer le problème? J'ai déjà essayé de regarder les blocages dans la DB, mais je n'en ai trouvé aucun.

Merci,

Answer 1

Je pense que pour répondre à votre question, nous pourrions avoir besoin d'un peu plus d'informations.

Par exemple, utilisez-vous Active Directory pour authentifier vos utilisateurs? Avez-vous utilisé le profileur SQL pour enquêter? Il semble que cela puisse être un problème d'authentification où SQL Server rencontre des problèmes pour authentifier cet utilisateur particulier.

Answer 2

me semble un problème de verrouillage mort ..

Assurez-vous également que cet utilisateur a les droits d'exécution et droits de lecture dans SQL Server

Mais si à l'information du temps est écrit comme essayer d'être lire vous verrouillez, car la transaction n'a pas encore été validée.

Jeff a fait un excellent article sur son expérience avec ça et stackoverflow. http://www.codinghorror.com/blog/archives/001166.html

Answer 3

Couple de choses à vérifier:

1. Cela se produit uniquement sur la machine de l'utilisateur spécifique? Peut-il l'essayer à partir d'une autre machine ? - Il pourrait s'agir d'un problème de configuration client.
2. Pouvez-vous capturer la chaîne réelle que cet utilisateur spécifique exécute et l'exécuter à partir d'une page ASP? Il se peut que l'utilisateur exécute le SP d'une manière qui génère une boucle ou une charge massive de données.
3. Enfin, si vous utilisez une application intra-organisationnelle, il se peut que les autorisations de votre utilisateur particulier soient différentes de celles des autres. Vous pouvez les comparer au niveau Active Directory.

Maintenant, je peux vous recommander un logiciel commercial qui va définitivement résoudre votre problème. Il enregistre les transactions de bout en bout et analyse les défaillances particulières. Mais je ne veux pas faire de publicité dans ce forum. Si vous le souhaitez, envoyez-moi une note et je vous expliquerai plus.

Answer 4

Eh bien, je pourrais vous suggérer d'utiliser SQL Server Profiler et d'ouvrir une nouvelle session. Appelez votre procédure stockée à partir de votre page ASP et voir ce qui se passe. Bien que cela ne puisse pas résoudre votre problème, il peut certainement vous fournir un point de départ pour mener à bien votre «enquête».

Answer 5

Quelques réflexions ...

La lecture des commentaires suggère que renifler des paramètres est l'origine du problème.

• Pour les autres utilisateurs, le plan mis en cache est assez bon pour le paramètre qu'ils envoient
• Pour cet utilisateur, le plan mis en cache est probablement faux

Cela pourrait se produire si cet utilisateur a beaucoup plus de lignes que d'autres utilisateurs, ou a des lignes dans une autre table (donc une table/index différent recherche/balayage serait mieux)

pour tester la détection des paramètres:

• utilisez RECOMPILE (temporairement) sur l'appel ou dans le def. Cela peut être lent pour une requête complexe
• Reconstruisez les index (ou seulement les statistiques) après le délai et réessayez. Cela invalidera tous les plans mises en cache

Pour résoudre: masque le paramètre

DECLARE @MaskedParam varchar(10) 
SELECT @MaskedParam = @SignaureParam 

SELECT...WHERE column = @MaskedParam 

Juste google « renifler Paramètre » et « masquage Paramètre »