> Tech > Etape n° 2 : Exécution de KickUserOut.sql (2)

Etape n° 2 : Exécution de KickUserOut.sql (2)

Tech - Par iTPro - Publié le 24 juin 2010
email

Bien que KickUserOut.sql utilise uniquement les informations des colonnes HostName, Login- Name et DBName, il stocke toutes les colonnes retournées par sp_who2 dans #utbSP WHO2. A la suite d’une limitation technique dans SQL Server, vous ne pouvez pas stocker uniquement certains résultats de cette procédure stockée. C’est tout ou rien.

Etape n° 2 : Exécution de KickUserOut.sql (2)

Dans le bloc C, KickUserOut.sql détermine la version de SQL Server installée sur le serveur car sp_who2 prend ce paramètre en considération. SQL Server versions 2005 et ultérieures renvoient la valeur RequestID, ce qui n’est pas le cas de SQL Server 2000. En fonction de la version installée de SQL Server, le script exécute sp_who2 et insère les résultats appropriés dans la table temporaire #utbSPWHO2.

Maintenant que les données nécessaires sont dans la table, KickUserOut.sql vérifie si l’utilisateur spécifié dans @LoginName accède actuellement à la base de données indiquée dans @Database- Name. Si ce n’est pas le cas, le script relaie ce message et se termine. Si l’utilisateur accède à la base de données, le script accède à la table #utbSP WHO2 et récupère le SPID du premier processus accédé par l’utilisateur, comme le montre le bloc D.

Il vérifie également la valeur dans la colonne HostName pour s’assurer qu’il ne s’agit pas d’un processus système interne. Dans le code du bloc E, le script utilise la commande KILL pour arrêter le processus et tous ses sous-threads. (Vous pouvez aussi employer cette commande pour arrêter des unités de travail créées par des coordinateurs de transactions distribuées ou DTC.)

Si la commande KILL termine un processus alors qu’une transaction est en cours, toute la transaction est annulée. Comme cette annulation peut être longue et consomme beaucoup de ressources de calcul (en particulier dans le contexte de transactions distribuées), la commande KILL doit être utilisée avec prudence. Notez que sp_who2 ne spécifie pas le nombre de transactions ouvertes pour un processus, ce que la table sysprocesses fait. Si un processus est au milieu d’une transaction, la valeur de la colonne open_tran correspondant à ce processus sera 1.

Après la tentative d’arrêt, le script exécute de nouveau sp_who2 pour déterminer si le processus a réellement été arrêté, ce qu’illustre le bloc F. Si le processus est toujours actif, le script attend que s’écoule le délai spécifié dans @TimeTo CheckKillInSec et contrôle de nouveau le statut du processus. Cette vérification se poursuit jusqu’à ce que le processus soit bien terminé ou jusqu’à ce que le script atteigne le nombre maximal de boucles spécifié dans la variable @NumberOfTimes ToLoop.

Si le script s’arrête après avoir atteint le seuil de bouclage défini, il informe l’utilisateur qu’il n’a pas pu arrêter le processus et quitter. Si le processus s’est terminé avec succès, KickUserOut. sql renvoie un message signalant l’arrêt réussi du processus. Comme le montre le bloc G, le script obtient le SPID du processus suivant qu’il doit arrêter et toute la boucle BEGIN…END, qui débute au bloc E et se termine au bloc G, s’exécute de nouveau. Tant qu’il existe des processus à arrêter, cette boucle poursuit son exécution.

Téléchargez gratuitement cette ressource

Endpoint Security : Etude IDC Enjeux & Perspectives

Endpoint Security : Etude IDC Enjeux & Perspectives

Quel est l'état de l'art des solutions de Endpoint Security et les perspectives associées à leur utilisation ? Comment garantir la sécurité des environnements sensibles en bloquant au plus tôt les cyber attaques sophistiquées, avant qu’elles n'impactent durablement vos environnements de travail ?

Tech - Par iTPro - Publié le 24 juin 2010