Discussion :

[VITALTH]

Bonjour,
Voilà deux jours qu'une tache d'un travail SQL Agent qui normalement tourne sans problème reste bloquée.
Lorsque je regarde le moniteur d'activité de SQL Server sur la base en question j'ai un processus et état RUNNING sur une commande SELECT sur une application SSIS (qui correspond à ma tache) qui a un type d'attente à "ASYNC_NETWORK_IO". En regardant le détail il s'agit d'une requête SELECT avec potentiellement un LEFT JOIN sur une des tables.
En faisant une recherche sur le net je m'aperçois que ce problème peut soit venir du réseau (et j'aurai tendance à vouloir exclure dans un premier temps cette hypothèse) soit de la requête qui semble trop couteuse en matière de données (problème de mémoire ??).
Enfin bref, je ne peux évidemment pas lancer la requête maintenant car la requête en cours bloque toute la base.
De plus, lorsque le problème s'est produit la première fois (il y a deux jours) j'ai relancé toutes les taches du SQL Agent manuellement avec le même utilisateur et je n'ai pas eu de problème.
La différence entre les deux cas est que dans le premier cas c'est le service de SQL Agent qui a lancé la travail et les taches et dans le deuxième cas, (même si c'est le même utilisateur) c'est l'utilisateur via une session qui a lancé la tache.
Peut il y avoir un problème d'allocation de mémoire et comment je peux le vérifier ?

Merci pour vos réponses

[mikedavem]

Le type d'attente ASYNC_NETWORK_IO correspond plus à une application qui consomme lentement des données arrivant de SQL Server et ce dernier doit attendre. La 2ème cause potentielle est effectivement le réseau.

Ceci dit es tu vraiment sûr que ton problème vienne bien de là? Est-ce le seul type d'attente que tu remarques pendant toute la durée d'exécution de ta requête? Combien de temps met ta requête pour s'exécuter normalement et lorsque cela pose problème? N'y a t'il pas des processus qui bloquent ta requête également? As-tu regardé du côté d'un mauvais plan d'exécution aussi?

++

[VITALTH]

Ce que je sais c'est que je ne suis sur de rien. Mon intuition me dit que cela vient de cette fameuse requête car il y avait un package SSIS qui attendait depuis plus de 8 heures (aujourd'hui j'ai killé le process) une même requête qui habituellement prend 2 minutes maximum. Dans le moniteur d'activité c'était la seule qui était en état RUNNING (tous les autres étaient SUSPENDED). Et plus moyen de faire une pauvre requête sur le serveur de n'importe quel table : elles étaient lockées.
J'ai soupçonné que cela venait de ce type d'attente car avec le moniteur d'activité la seule requête qui tournait c'était cette fameuse requête avec des temps dans le champs de time_wait_ms de la table sys.dm_os_waiting_task astronomique pour ce processus.
J'ai aussi constaté que bizarrement lorsque je lance les packages SSIS de la tache de SQL Agent manuellement je n'ai pas de problème. J'ai pu constaté aussi que lorsque je lance le SQL Agent en cours de journée avec le seul package (et non pas un ensemble de package avec lequel il était associé) après avoir redémarrer le serveur je n'ai pas eu de problème non plus. Ce qui revient à ce que je dis au tout début : je ne suis sur de rien car je n'ai pas pu reproduire le problème.
Mon intuition en lisant ce qui se trouve sur Internet me fait penser à la brique de fusion employé juste après la requête. En effet : comme la requête retourne énormément de données, ces données sont ensuites, je suppose stockés dans un buffer pour être traité juste après par la brique de fusion. J'aurai tendance à ne pas vouloir utiliser une requête de fusion mais directement soit une table temporaire, soit géré la fusion dans une reqête de jointure pour ne pas avoir un buffer trop volumineux. Mais rien ne me prouve que ce que je dis est véridique.