Certains utilisateurs oublient de fermer leurs requêtes d'accès qui utilisent nos bases de données SQL 2014. Lorsque cela se produit, il empêche les tables auxquelles elles accèdent d'être reconstruites pendant la nuit. Est-il possible de tuer ces utilisateurs et ne pas tuer les processus du système. De ce que j'ai lu, les processus système ne sont pas limités à SPID> 50.Supprimer uniquement les processus utilisateur dans SQL Server
La suppression des processus utilisateur basés sur spid>=50 ne semble pas fiable.
D'Adam Machanic: Smashing a DMV Myth: session_id > 50 == User Process
Une récente conversation sur une liste de diffusion MVP a révélé que ce chiffre magique, alors peut-être une fois un filtre légitime, est certainement pas sûr à utiliser dans SQL Server 2005 ou SQL Server 2008 Plusieurs caractéristiques du système peuvent - et vont - utiliser des identifiants de session supérieurs à 50, car il n'y a tout simplement pas assez de place.
Voici quelques exemples:
Et il peut y avoir d'autres cas aussi bien. Le fait est que le numéro 50 n'est plus un moyen valide de filtrer les ID de session système.
afin que vos options sont
SELECT *
FROM sys.dm_exec_sessions
WHERE
is_user_process = 1
SELECT *
FROM sys.sysprocesses
WHERE
hostprocess > ''
Vous pouvez utiliser ci-dessus requêtes pour obtenir spids/autre session que le système et utiliser la commande kill pour les tuer
Je pense que la combinaison de l'utilisation sp_who et KILL devrait être possible, en regardant le nom de connexion, le nom d'hôte, etc. de sp_who
Nous avons des utilisateurs qui oublient de fermer leurs requêtes d'accès qui utilisent notre SQL 2014 bases de données. Lorsque cela se produit, il empêche les tables d'être reconstruites pendant la nuit.
Vous pouvez mettre votre base de données en mode single user (avec rollback immédiat), puis à multi user avant de commencer votre entretien. Toutes les transactions de l'utilisateur seront annulées.
Je pense qu'une procédure stockée avec cela fera l'affaire? – user3352326
Oui, bien sûr, nous avons cela comme la première étape de la maintenance de nuit, mais vous pouvez envelopper dans la procédure stockée, pourquoi pas – sepupic
Cette procédure stockée fonctionne et tue les requêtes d'accès suspendu et ne tue pas les processus système.
DECLARE @v_spid INT
DECLARE c_Users CURSOR
FAST_FORWARD FOR
SELECT SPID
FROM master..sysprocesses (NOLOCK)
WHERE spid>50
AND status='sleeping'
AND DATEDIFF(mi,last_batch,GETDATE())>=60
AND spid<>@@spid
OPEN c_Users
FETCH NEXT FROM c_Users INTO @v_spid
WHILE (@@FETCH_STATUS=0)
BEGIN
PRINT 'KILLing '+CONVERT(VARCHAR,@v_spid)+'...'
EXEC('KILL '[email protected]_spid)
FETCH NEXT FROM c_Users INTO @v_spid
END
CLOSE c_Users
DEALLOCATE c_Users
Cela semble bon ... – DanielG
Ceci est déjà disponible dans le Moniteur d'activité et totalement impossible pour les tâches de maintenance. –
En quoi est-ce que c'est impraticable? – DanielG
Est-ce que vous allez vous lever à 1 heure du matin, retourner au bureau et commencer à fermer les connexions une à une, tous les jours? –