Blocages SQL Server, attentes et session en tête

Une longue liste de sessions bloquées rend chaque requête suspecte. Une transaction en tête de chaîne contrôle généralement la durée et l'impact.

Pourquoi ce sujet exige une attention méthodique

Un problème de ce type existe rarement seul. Une modification qui améliore une requête peut augmenter les écritures, le journal, les blocages, la reprise ou la complexité ailleurs. Traitez le travail comme une décision d'ingénierie avec un objectif mesurable, des contraintes connues et un responsable.

Une réponse efficace restaure le service tout en conservant les preuves nécessaires pour éviter la récidive.

Ce qu'il faut mesurer

Capturez chaîne, type et ressource d'attente, début de transaction, instruction ouverte, isolation, application et plan récent. Séparez verrous, CPU, E/S, mémoire et parallélisme.

Méthode de diagnostic

• Définissez précisément symptôme, charge touchée, début, fréquence et impact visible.
• Collectez des preuves pendant les périodes normales et dégradées pour la même opération métier.
• Séparez corrélation et cause en examinant plans, attentes, ressources, blocages, configuration et changements récents.
• Testez des groupes représentatifs de bases, requêtes ou paramètres, pas seulement le cas le plus simple.
• Conservez réglage, plan, définition d'objet et compteurs actuels avant toute modification.
• Exprimez numériquement le résultat attendu : latence, CPU, lectures logiques, débit, file ou temps de reprise.

Choisir l'intervention

Préférez le changement le plus limité qui traite la cause démontrée. Une configuration serveur touche de nombreuses charges, tandis qu'une modification de requête, index, statistique ou horaire peut être ciblée. Considérez licence, version SQL Server, haute disponibilité, fenêtres de maintenance et capacité de surveillance.

Approche pratique

Trouvez la session en tête avant de terminer les suivantes, expliquez la transaction ouverte, réduisez sa portée, améliorez les accès justifiés et détectez les transactions abandonnées.

Séquence de mise en œuvre sûre

• Reproduisez le comportement dans un environnement sûr avec un volume proche de la production.
• Modifiez une variable importante à la fois et conservez la définition d'origine pour le retour arrière.
• Mesurez durée, CPU, lectures, écritures, attentes, mémoire, journal et effets en aval.
• Testez entrées normales, pics et cas limites, ainsi que redémarrage ou basculement si nécessaire.
• Déployez dans une fenêtre adaptée avec opérateur, propriétaire applicatif et décideur de retour arrière disponibles.
• Évaluez immédiatement puis pendant le prochain pic représentatif de production.

Exemple SQL Server

L'exemple suivant sert de point de départ pour l'analyse ou une mise en œuvre contrôlée. Adaptez bases, seuils, rétention et autorisations avant la production. Conservez la sortie avec la chronologie de l'incident au lieu de considérer un seul échantillon comme un diagnostic complet.

SELECT
    r.session_id,
    r.blocking_session_id,
    r.status,
    r.wait_type,
    r.wait_time,
    r.wait_resource,
    r.open_transaction_count,
    DB_NAME(r.database_id) AS database_name,
    t.text AS current_statement
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t
WHERE r.session_id <> @@SPID
ORDER BY r.blocking_session_id DESC, r.session_id;

Ce qu'il faut éviter

Ne terminez pas toutes les sessions bloquées, ne lisez pas les attentes cumulées sans fenêtre temporelle et n'utilisez pas NOLOCK sans accepter des résultats incorrects.

Surveillance après le changement

Surveillez la métrique visée et au moins deux effets secondaires possibles. Comparez des périodes et volumes équivalents. Observez assez longtemps pour inclure maintenance, sauvegardes, reporting, basculement et activités périodiques. Documentez si l'amélioration persiste et si le changement doit rester, évoluer ou disparaître.

Retour arrière et responsabilité

Le retour arrière doit préciser l'ancienne valeur ou définition, le décideur et le signal de déclenchement. Conservez le plan et le script d'origine pour les changements de plan ou métadonnées. Pour l'infrastructure, confirmez capacité et temps de maintenance avant de commencer.

Résultat opérationnel

Une réponse efficace restaure le service tout en conservant les preuves nécessaires pour éviter la récidive.

Checklist de production

Établissez une référence et définissez l'amélioration attendue. Testez avec des données et une concurrence représentatives. Conservez la configuration ou le plan d'origine, préparez un retour arrière et surveillez le prochain pic normal de charge.

Questions avant de clôturer

• Le symptôme initial s'est-il amélioré sous la même charge ?
• De nouveaux coûts d'écriture, stockage, blocage, mémoire ou disponibilité sont-ils apparus ?
• Le résultat survivra-t-il au redémarrage, basculement, statistiques et croissance ?
• Les alertes détecteront-elles une régression avant les utilisateurs ?
• La décision, le responsable et la date de révision sont-ils enregistrés ?

Pour appliquer cette méthode à un environnement SQL Server précis, utilisez le formulaire ci-dessous et indiquez la version, la taille de la base, le profil de charge et les éléments déjà collectés.