Discussion :

[zooffy]

Salut

Je suis confronté à un souci que je n'ai pas l'habitude de traiter.
J'ai des SPID sur mon serveur que je n'arrive pas à tuer.
J4afais avec leEnterprise Manager "Terminer le processus", mais ils sont toujorus là.
J'ai fait déconnecter tout le monde, mais ça n'a pas marché
J'ai utiliser la comande KILL 119 (numéro par exemple) rien n'y fait.

Je cherche donc le moyen de ture ces processus, je sais qu'ils ne servent à rien et je voudrias un truc qui ne fait pas dans la dentelle, ces processus sont véritablement mort et font que pénaliser le serveur.

Merci pour votre aide.

[Ptit_Dje]

Tu as pensé à faire un refresh de l'activité du serveur une fois que tu as fait un kill ?
Ici, si je ne le fais pas, je continue à voir les process...

[zooffy]

Oui, j'ai fait ça, mais rien, ils sont toujours là.

[kagemaru]

il est possible que ces threads soient en rollback, il faut donc peut-être attendre que l'annulation de la transaction soit terminée.

pour avoir la dernière commande lancée par un spid :
dbcc inputbuffer(spid)
go

sinon, la commande sp_who vous permettra de voir leur état (awaiting command, insert, select, ...).

il est également possible que ces spid soient bien supprimés mais recréés dans la foulée par le programme à l'origine. Il se peut que les même spid soient réutilisés.

[zooffy]

OK, merci pour ces infos.
Effectiement ils sont tous en rollback, mais rien n'arrive à les supprimer. isl font des opérations qui ne devraient plus avoir cours.

En fait, la violence a parlé et le chef a décidé de rebooter le serveur, donc plus de souci.

Toutefois, je reste curieux de savoir comment on pourrait faire pour shotter ces SPID récalcitrant, si jamais le problème se reposait, le reboot ne me parait pas être une bonne solution, surtout pour un serveur de prod en WEB.

Je n'arraive pas non plus a déterminer le programme qui lance ces SPID. Dans le cas qui m'a occupé hier, c'est une page ASP qui les a lancé, mais à partir du Serveur WEB je n'ai rien trouvé de persistant. De plus, la page en question à été interompue à chaque fois.

[kagemaru]

il faut attendre que les processus en rollback se terminent d'eux-même. Je suis même un peu étonné pour le reboot (vraiment extrême comme solution)
car dans tous les cas, c'est SQL Server qui effectuera ce rollback lors de la récupération de la base à l'ouverture.
En fait le vrai problème est de savoir pourquoi il y a ces rollback et pourquoi semblent-ils aussi longs (très souvent lié à la durée de la transaction avant le kill).

pour connaître le host et qq infos utiles sur les threads, vous pouvez faire
select spid, hostname, login, program_name, cmd, status from master.dbo.sysprocesses where spid=<le spid>

[SQLpro]

C'est vraiment pas une bonne idée que de rebooter un serveur SQL... Outre le risque de casse matérielle qui est maximal dans les phases de démarrage et d'arrêt, vous ne faites que reporter le problème car le Rollback va à nouveau être entrepris dès le redémarrage.
Un rollback est bien souvent plus long que la finalisation d'un traitement.

Comme on vous l'a dit, l'essentiel est de savoir pourquoi il y a des transactions qui sont énormes : COMMIT oublié, mauvaise stratégie de développement, niveau d'isoaltion incohérent sont autant de choses qui peuvent entraîner des transactions trop lourdes...

A +

[zooffy]

Bon, je clorture car je n'ai toujorus pas trouvé pourquoi ça l'avais fait et vu que ça été rebooté, ben maintenant ça roule.

Merci à tous