Utiliser sp_whoisactive pour voir les requêtes actives
sp_WhoIsActive est la procédure stockée d’Adam Machanic qui montre ce qui s’exécute sur une instance à l’instant présent. Pour chaque session active, elle donne le texte de la requête, l’attente en cours, la session qui la bloque, le CPU consommé et les lectures, sous une forme bien plus lisible que sp_who2.
Installation
Le script sp_WhoIsActive.sql se télécharge sur le dépôt GitHub. Prenez la version qui correspond à votre instance : le fichier à la racine du dépôt vise SQL Server 2022 et les versions suivantes, celui du dossier 2019 couvre SQL Server 2012 à 2019, celui du dossier 2008 les versions 2005 à 2008.
Le script crée la procédure dans la base de la connexion courante. Installez-la dans master : grâce au préfixe sp_, vous pourrez l’appeler depuis n’importe quelle base de l’instance.
L’utilisateur qui l’exécute a besoin de la permission VIEW SERVER STATE. Certaines options, comme la collecte des verrous, accèdent aussi aux bases concernées pour retrouver le nom des objets. Si l’utilisateur n’y a pas de droits, la procédure affiche le message d’erreur à la place du nom.
Paramètres utiles
Les paramètres suivants ajoutent des colonnes que la procédure ne collecte pas par défaut.
| Paramètre | Type | Défaut | Effet |
|---|---|---|---|
@get_plans | tinyint | 0 | 1 ajoute la colonne query_plan avec le plan de l’instruction en cours ; 2 donne le plan complet du lot ou de la procédure. |
@find_block_leaders | bit | 0 | 1 ajoute la colonne blocked_session_count, le nombre total de sessions bloquées en aval de chaque session, sur toute la chaîne de blocage. |
@get_memory_info | bit | 0 | 1 ajoute les colonnes requested_memory, granted_memory et max_used_memory, ainsi que memory_info, un XML qui détaille l’octroi de mémoire, le sémaphore de ressource et les réglages de Resource Governor qui le limitent. |
@get_avg_time | bit | 0 | 1 ajoute la colonne dd hh:mm:ss.mss (avg), la durée moyenne des exécutions passées de la requête active, lue dans sys.dm_exec_query_stats. |
Le plan renvoyé par @get_plans est celui qui est en cours d’exécution. Il ne contient pas les nombres de lignes réels d’un plan d’exécution réel, qui ne sont connus qu’à la fin de la requête. Les plans de grosses requêtes pèsent parfois plusieurs mégaoctets de XML, et c’est la raison pour laquelle la procédure ne les collecte pas par défaut.
Les colonnes de mémoire de @get_memory_info sont exprimées en pages de 8 Ko : sur SQL Server 2025, une requête de tri qui avait obtenu 1 024 Ko affichait 128 dans granted_memory, et 1024 dans le granted_memory_kb du XML memory_info. Les sessions sans octroi de mémoire affichent NULL.
Vous pouvez combiner les paramètres :
EXEC sp_WhoIsActive
@get_plans = 1,
@get_memory_info = 1;
La tête d’une chaîne de blocage
La colonne blocking_session_id ne montre que le bloqueur direct d’une session. Quand une session en bloque une autre, qui en bloque elle-même d’autres, les sessions du bas de la chaîne semblent bloquées par une session qui attend elle aussi. Le problème vient de la session en tête de chaîne, et c’est elle qu’il faut trouver.
@find_block_leaders = 1 parcourt la chaîne et compte, pour chaque session, toutes les sessions bloquées en aval. Triez sur cette colonne pour voir la tête de chaîne en premier :
EXEC sp_WhoIsActive
@find_block_leaders = 1,
@sort_order = '[blocked_session_count] DESC';
Voici le résultat sur SQL Server 2025, avec quatre sessions qui lancent la même mise à jour dans une transaction. La session 79 a modifié les lignes puis garde sa transaction ouverte, la session 78 attend ses verrous, et les sessions 68 et 80 attendent la session 78.
session_id | blocking_session_id | blocked_session_count | wait_info |
|---|---|---|---|
| 79 | NULL | 3 | (7439ms)WAITFOR |
| 78 | 79 | 2 | (5389ms)LCK_M_U |
| 68 | 78 | 0 | (3435ms)LCK_M_U |
| 80 | 78 | 0 | (3331ms)LCK_M_U |
Les sessions 68 et 80 indiquent 78 comme bloqueur, mais la session 79 bloque trois sessions au total : c’est la tête de la chaîne. Dans cette démonstration, elle exécutait un WAITFOR. En production, la tête de chaîne est souvent une session inactive qui a laissé une transaction ouverte. La procédure l’affiche quand même, car @show_sleeping_spids vaut 1 par défaut et remonte les sessions inactives qui ont une transaction ouverte.
L’aide intégrée
La procédure documente elle-même tous ses paramètres et toutes ses colonnes de sortie :
EXEC sp_WhoIsActive @help = 1;
La documentation complète, rédigée par l’auteur, se trouve sur whoisactive.com.