J'ai un problème avec un pendentif en utilisant xp_cmdshell.
L'exécutable est appelé, effectue son travail et sort. Ce n'est pas suspendu à cause d'une invite d'interface utilisateur dans l'EXE. L'EXE n'est pas suspendu du tout. L'EXE disparaît de la liste de processus dans le gestionnaire de tâches et la journalisation interne de l'EXE confirme qu'il exécutait la dernière ligne de la fonction principale
L'appel à xp_cmdshell ne renvoie pas le contrôle dans SQL. Il se bloque sur cette ligne (c'est la dernière ligne du lot). Tuer le processus est inefficace. Cela nécessite en fait un redémarrage de SQL Server pour se débarrasser du processus suspendu (UGH)
Le hangive ne se produit que la première fois qu'il est exécuté. Les appels ultérieurs à la procédure avec des paramètres identiques fonctionnent et sortent correctement tant que le premier est suspendu. Une fois que SQL est redémarré, le premier appel ultérieur se bloquera à nouveau.
Si cela fait une différence, j'essaie de recevoir la valeur de retour de l'EXE - Ma procédure SQL se termine par:
exec @i = xp_cmdshell @cmd; retour @i;
Activité Monitor marque le processus à bloquer sur un type d'attente de Preemptif_OS_Processops (ce que l'autre développeur a vu) ou Preemptif_os_pipeops (ce que je vois sur mes tests actuels)
Des idées?
3 Réponses :
Nous avions le même problème, avec SQL Server 2008, également avec des appels impliquant XP_CMDSHELL et BCP. Tuer l'ID de processus SQL n'a pas aidé, il resterait simplement bloqué dans le statut "tué / Rollback".
seul moyen de tuer était de tuer le processus BCP.EXE dans Windows Task Manager.
En fin de compte, nous avons suivi la question à la mauvaise position SQL dans SproC appelant le XP_CMDSHELL. C'est par erreur ouvrant plusieurs transactions dans une boucle et ne les fermez pas. Après début / commit, les problèmes trans ont été réparés, Preemptive_OS_Processops n'a jamais revenu.
Je viens de tomber sur cette situation moi-même où je gère un commentaire non valide via XP_CMDSHELL.
J'ai réussi à le tuer sans redémarrer SQL, ce que j'ai fait était d'identifier le processus qui exécute la commande et de le tuer à partir du gestionnaire de tâches.
Supposons que votre SQL fonctionnait dans Windows 2008 à la hausse: Sous Task Manager, onglet Processus. J'ai activé la colonne d'afficher la ligne de commande de chaque processus (E.g.: Affichage -> Sélectionner des colonnes ..).
Si vous ne savez pas quelle commande vous avez exécutée via XP_CMDSHELL, DBCC INPUTBUFFER (
Nous avons finalement finalement compris le problème ici. L'application étant appelée a été utilisée pour vider automatiquement certains documents à une imprimante lorsque certaines conditions sont arrivées.
Il s'avère qu'un pilote d'impression particulier a parcouru une petite fenêtre étrange dans le plateau de notification sur un travail d'impression. Donc, c'était suspendu à cause d'une fenêtre d'interface utilisateur qui saute - mais notre application quittait correctement parce que ce n'était pas notre fenêtre, c'était une fenêtre déclenchée par le pilote d'impression.
Ce pilote comprenait une option pour désactiver cette fenêtre d'affichage. Notre problème est parti lorsque cette option a été définie.
Que se passe-t-il lorsque vous ne vous inquiétez pas avec le
@i , par ex. Justexec xp_cmdshell @cmd; ?N'ont pas essayé ça. J'ai besoin d'attendre une fenêtre dans laquelle nous pouvons redémarrer SQL Server. Avez-vous une idée sur la façon de tuer ce processus unique afin de ne pas avoir à prendre une étape aussi drastique?