J'exécute une procédure stockée à l'aide du travail SQL Server Agent dans SQL Server 2005.
Ce travail fonctionnait vite jusqu'à hier. Depuis hier, ce travail prend plus d'une heure au lieu de 2 minutes.
J'ai exécuté la procédure stockée dans SSMS, elle a juste pris moins de 1 minute pour exécuter.
Je ne pouvais pas comprendre pourquoi il prend plus d'une heure lorsqu'il est exécuté en tant qu'objet d'agent SQL Server?
4 Réponses :
Après quelque temps commentaire et en supposant que le SP fonctionne avec les mêmes paramètres d'entrée et les mêmes paramètres d'entrée lorsqu'il est exécuté dans SSMS, je pense que je peux donner un dernier conseil:
Selon quelles actions sont effectuées dans le SP (par exemple Insertion / mise à jour / Suppression / Suppression de nombreuses données dans une boucle ou un curseur), vous devez définir Nocount au début de votre code. Si ce n'est pas le cas ou ne vous aide pas, veuillez ajouter plus d'informations, déjà mentionnées dans les commentaires (par exemple, tous les paramètres du travail et chaque emploi du travail et de chaque emploi et de chaque emploi, ce qui a été Connecté, qu'est-ce qui se trouve dans le jobhistoire, vérifiez SQLERRORLOGS, EventLogs, ....).
Regardez également les «journaux SQL Server», vous pouvez peut-être rassembler des informations ici. De plus, un aperçu de l'application / système EventLo du BasePaseServer est toujours une bonne idée.
Pour obtenir une vue d'ensemble de base, vous pouvez utiliser l'ActivityMonitor dans SSMS, en sélectionnant les bases de donnéesServer et en sélectionnant "Moniteur d'activité" à partir du contextMenu et en recherchant l'agent SQL. Mon dernier essai serait d'essayer d'exécuter une trace SQL pour l'agent. Dans ce cas, vous commencerez une trace et un filtre. par l'utilisateur que le service SQLAgent fonctionne. Il y a tellement d'options que vous pouvez définir pour des traces. Je vous recommanderais donc à Google pour cela, de rechercher sur MSDN ou de poser une autre question sur Stackoverflow.
J'ai remarqué que les tâches de l'agent SQL ignorent le paramètre MaxDop du serveur et exécutent tout avec un maximum de 1. Si j'exécute une procédure stockée dans une fenêtre de requête, il obéit les paramètres du serveur et utilise 4 processus. Si j'utilise SQL Agent, toute procédure stockée I utilise un seul processus.
J'ai un problème similaire avec un script qui appelle un certain nombre de UDF que j'ai créés. Les UDF eux-mêmes fonctionnent normalement sous la sous-position sous SSMS. De même, l'exécution des rapports que je génère avec eux est supportable sous SSMS (données 30D en 8s, 365D de données dans 22s). J'ai toujours fait Nocount avec mes emplois SQL Agent lorsqu'ils génèrent normalement des fichiers texte pour la prise en charge par d'autres processus ou Excel et je ne veux pas les données supplémentaires à la fin, ce n'était donc pas une solution pour moi.
Dans ce cas, lorsque nous exécutions exactement le même script sous agent SQL en tant que travail, mon temps augmente de manière exponentielle. Mon script 8S prend 2m30 et mon script 22S prend 2h20m. C'est la même chose que je l'exécute à midi avec une autre activité utilisateur et des travaux ou après des heures sans activité utilisateur, ni des travaux ni de sauvegarde en cours d'exécution. Notre serveur est inactif et au mieux, je reçois l'un des 8 noyaux utilisés lors de la course. DB est que d'environ 10 Go fonctionnant sur SSD avec une carte RAID mis en cache et 16 de 32 Go de RAM est gratuite. Étant donné que mon SQL fonctionne efficacement dans SSMS, je suis assez bonne de la conviction que je frappe une limite de filetage de quelque sorte. J'ai des recherches et j'ai essayé de régler MaxDop juste avant les scripts de l'agent SQL sans chance. P>
Comme il s'agit d'une activité que je veux planifier, elle doit être automatisée d'une manière ou d'une autre. Je pourrais laisser ces scripts prendre les heures dont ils ont besoin pour courir en tant que étapes SQL dans les emplois SQL Agent, mais j'ai décidé de courir à partir de la ligne de commande et d'obtenir la même performance que je vois dans SSMS. P>
sqlcmd -S SQLSRVRHost -i "C:\My Script Loc With Spaces.sql" -v MyVar="VarValue" >"C:\MyOutputFile.txt"
Nous avons un grand processus qui fonctionne en 88 secondes dans SSMS et 30 à 45 minutes en agent SQL Server. J'ai ajouté le DBO. Préfixe sur tous les noms de table et il est maintenant aussi rapide que SSMS.
Si vous exécutez le même SP dans SSMS et cela fonctionne, peut-être un réglage du travail modifié, par exemple. son exécuté sur la mauvaise base de données. Sinon, vérifiez l'activité de l'activité ce que l'agent effectue ou démarre une trace pour obtenir les commandes exécutées. Peut-être qu'il y a un problème de verrouillage. Le problème se produit-il toujours si vous exécutez manuellement le travail?
@Bernhard, merci pour votre réponse. J'ai vérifié le travail et j'ai recréé. Toujours le même problème. Oui si j'exécute manuellement le travail, il faut toujours beaucoup de temps
@Preteek Pouvez-vous poster les paramètres du travail? La seule raison de ce comportement que je peux penser, est une exécution différente de la SP. Étant donné que les paramètres, etc. sont les mêmes que lorsqu'ils sont exécutés manuellement, le SQLServer doit utiliser les mêmes plans d'exécution, etc. Peut-être que vous pouvez consulter le journal SQL - peut-être que cela nous donnera un indice.
@ Bernhard- dans les propriétés du poste, propriétaire = SA; en étapes, type = t-SQL; Commande = EXEC DBO.STORDEDPODEDURENAME
@Berrnard - Aucune raison de supposer qu'ils utiliseront le même plan. Peut-être un problème de reniflement du paramètre Voir lent dans l'application, rapide dans SSMS? Comprendre les mystères de performance
@Martin merci pour le lien, mais je pensais que l'exécution de la même déclaration de SQLAgent doit être identique à celle de SSMS, car elle utilise ADO.NET LIEK SSMS, la même requête, etc. Dans ce cas, je pense que je ne peux fournir aucun aide utile. Encore une fois, j'essaierais de vérifier si tous les paramètres du travail (vérifiez les paramètres des étapes du travail unique ainsi que les paramètres du travail). Si cela ne fonctionne pas, j'utiliserais un moniteur d'activité ou commenceriez à tracer l'exécution, pour savoir s'il existe un exemple différent. Bonne chance.
Quelqu'un a un autre commentaire ou conseil ??
@ Bernhard- Pouvez-vous me dire comment créer une trace pour surveiller un travail particulier
@Prateek, je viens d'ajouter une réponse, peut-être que cela aide. Sinon, veuillez suivre les conseils mentionnés dans ma réponse. Googling for SQL Trace ou SQL Profiler devrait vous aider à trouver des informations sur la manière d'effectuer une trace. Je suis désolé de Cannto vous donner quelque chose de liek une solution de 5 étapes à cela.
@ Bernhard- Merci pour votre réponse. Je vous en suis reconnaissant
J ai exactement le même problème. Un script qui prend 20 secondes dans SSMS prend 8 minutes lors d'une utilisation en tant que travail.