J'essaie de comprendre pourquoi un appel de procédure stocké prend des secondes dans une fenêtre de requête SQL Server Express, mais lorsque j'exécute appeler la procédure stockée dans le code de la requête Times Out. Nous utilisons SQL Server 2008. Je sais qu'il est difficile de dire exactement ce qui se passe sans voir la procédure stockée. J'espère que c'est un problème connu. Toute directive est très appréciée.
requête SQL qui appelle "stocké_procedure_x" et fonctionne en 2 secondes dans la fenêtre de requête SQL Server Express: p> code qui appelle "stocké_procedure_x" et Times Out: P> System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
11 Réponses :
Utilisez-vous des transactions dans votre procédure stockée? Les transactions non engagées provoqueront ce message d'erreur exacte.
Essayez d'essayer de réorganiser votre code, et b) augmenter le délai d'attente: le En outre, je voudrais sqldataaadapter ouvrira et fermez la connexion elle-même - pas besoin de faire qui explicitement.
lancer et non jette ex (si vous utilisez jette ex , vous êtes essentiellement Briser la trace de la pile et ne peut pas comprendre où l'exception est venue de)
Oui, ces conversions de type de Nvarchar peuvent également entraîner des problèmes en utilisant également des indices.
En supposant que vous transmettez les mêmes paramètres de votre code comme lorsque vous testez dans SSMS et que votre test SSMS est exactement identique en termes d'utilisation de type de données que j'aurais pensé que cela devrait être un problème de reniflement du paramètre.
Avez-vous accès à SQL Profiler (ne vient pas avec Edition Express) pour obtenir les deux plans d'exécution réels? Sinon, vous pouvez suivre le conseil Dans cette réponse pour obtenir les plans.
J'ai eu un problème similaire avec les procédures stockées fonctionnant plus lentement que la même requête dans la fenêtre de la requête. J'avais tout essayé de coder pour le reniflement des paramètres (variables locales), en supprimant des index en cluster et en utilisant uniquement des non-clusters, etc. Il a toujours pris 22 secondes minimum pour récupérer un champ Varchark, à l'aide d'un paramètre NVARCHAR.
Je pensais à l'origine que c'était juste la différence entre Nvarchar et Varchar et modifié le champ de base de données vers Nvarchars. J'ai perdu une autre journée complète, déplaçant 50 millions d'enregistrements à une nouvelle table et à la réindexation. Toujours pris plus de 22 secondes.
Enfin, j'ai changé de champs clés dans les tables de Nvarchar à Varchar, plus tous les paramètres et wow; retour dowen à moins de 1 seconde.
Je crois fermement que c'est un bogue dans SQL Server, qui n'a jamais été corrigé. Comment exécuter une requête directement dans la fenêtre de requête ou appelez SQL de VB.NET ou C # CODE et obtenez des résultats en moins de 1 seconde; puis exécutez la même requête, en utilisant des paramètres, dans une procédure stockée et obtenez des résultats aussi horrifiés?
Réponse courte: Éloignez-vous des types de données NvarchaRar à tout prix.
Aussi, apprenez à utiliser la déclaration de fusion pour déplacer les données en grandes tables pour éviter les délais d'attente. Définissez le mode de récupération sur simple, tout en exécutant une grande requête de fusion; puis remis à la récupération complète.
Garçon, ai-je appris beaucoup cette semaine. Plus de 80 heures d'éducation que je n'avais pas besoin. Mais, linktumeet.com, compte maintenant plus de 150 millions de membres et tout va bien.
Assurez-vous que les paramètres étant passés à SP correspondent à ceux de la base de données [qui est sensible à la casse]
Ainsi, en cours d'exécution d'un processus stocké qui a renvoyé 30 enregistrements m'a pris 00:00 secondes dans la console de gestion, mais lorsque vous le chargez dans .NET m'a pris environ 40 secondes, plus que le délai d'attente de 30 secondes par défaut.
Je viens de modifier le procédé stocké et revenir sur le code alter ... Code sans changer et le problème a été résolu instantanément. Je n'ai pas plus de détails sur la source de cette erreur, mais au moins c'est une solution très rapide
Modifier la procédure m'a sauvé aussi ..... Intéressé de voir pourquoi? Toute opinion d'expert?
On dirait que la SproC compilée était corrompue d'une certaine manière.
Cela m'a sauvé aussi! SP a pris 1 seconde dans SSMS mais a expiré en code, très étrange. Modifier la procédure sans modification corrigée.
La magie!!! Cela a vraiment fonctionné .. @> @
Qu'est-ce qui m'a toujours aidé, c'était d'ajouter le "
Cela peut améliorer les performances de traitement de la procédure. directement de la source. Bon sur Ya ', mate.
En outre, c'est essentiellement quelle est la meilleure réponse votée, non?
@Gibraltertop Oui, sauf que "avec recompilation" empêche le paramètre reniflant afin que vous n'ayez pas à laisser tomber et recréer chaque fois que vous rencontrez des problèmes
Merci. Dans mon cas, SQL a pris 6 secondes pour 2000 rangées. Mais, EF a été expiré. Maintenant, "avec recompilation", cela fonctionne plus rapidement sans aucun problème. J'ai presque passé 5 heures sans indice. Tu m'as sauvé !!
Modifier le CommandTimeOut = 0
sqlCmd.CommandTimeout = 0;
Comment sur Terre concluez-vous que c'est une meilleure solution que ce qui était déjà suggéré ici?
Monsieur dans notre code, nous pouvons définir le délai de commande à 0 afin que le code ne donne aucune erreur avant la fin de la procédure stockée.
Merci Monsieur. Cela a effectivement travaillé pour moi. J'ai dû l'essayer BC, je suis désespéré de trouver une solution rapide. Mais je dois savoir pourquoi le SP est soo lent à exécuter lorsqu'il fonctionne à l'extérieur de l'outil de requête. Tout essayé ci-dessus et rien ne semble fonctionner ..
@ MHMDAN01 Veuillez mettre à niveau ma solution.
J'ai eu le même problème. Mon procédé stocké est exécuté de MSSMS ou de DBForgestudio, mais pas du code C # (SQLCommand). J'ai résolu ce problème en modifiant le ProC stocké dans SQL Server (sans aucune modification).
Après quelques jours, j'ai de nouveau cette exception si possible n'est pas une solution.
J'ai essayé avec "avec recompilation", avec "Arithabort OFF", pour changer le code, etc, etc., mais à la fin, le redémarrage de SQL Server j'ai résolu le problème.
Nous avions ce même problème et que nous avons pensé que le paramètre reniflant également, mais après avoir essayé de nombreuses choses, notamment de changer de paramètre reniflant, en utilisant avec recompilement, en utilisant des statistiques de mise à jour, libérant le cache, nous n'avons trouvé aucun de ces fonctionnalités. Nous l'avons suivi à un seul index qui devait être ajouté. Nous venions de passer de l'estimateur de cardinalité hérité à l'estimateur après-2014. Retour à l'estimateur hérité résolue le problème, ou en utilisant le nouvel estimateur et en ajoutant l'index.
Je ne sais pas si cela vous aiderait, mais je construirais complètement la commande avant d'ouvrir la connexion.
@Alleng: plus je mettais
sqlconnection etSQLCOMMAND dansen utilisant (...) {......} blocs, aussiUn Thign Je remarque: lorsque vous exécutez à partir de SSMS, vous ne fournissez pas une chaîne Unicode - de votre code, vous êtes. Qu'est-ce que le Proc stocké s'attend à ce que ?? Varchar ou Nvarchar ?? Aussi: pourquoi ne spécifiez-vous pas maxa longueurs pour vos paramètres NvarcharN dans votre code ??