Microsoft n'a pas l'habitude de déprécier les choses ces jours-ci, mais quand ils le font, c'est pour une raison - et ce n'est certainement pas parce qu'ils veulent vous rendre la vie plus difficile. Au contraire, c'est presque toujours parce qu'ils ont développé des moyens meilleurs et plus modernes pour résoudre ces mêmes problèmes.
Mais les habitudes sont difficiles à briser; demande-moi comment je sais. Trop souvent, je vois des gens s'accrocher à une ancienne façon d'accomplir une tâche, même s'il existe une meilleure façon.
Je voudrais partager quelques exemples récents qui aident à illustrer comment l'utilisation de fonctionnalités obsolètes de SQL Server continue de nous mordre. Dans cette première partie, je veux parler de…
processus système
La table système sys.sysprocesses a été remplacé dans SQL Server 2005 par un ensemble de vues de gestion dynamiques (DMV), notamment sys.dm_exec_requests , sys.dm_exec_sessions , et sys.dm_exec_connections . La documentation officielle pour sys.sysprocesses avertit :
Un exemple récent
Récemment, l'une de nos équipes enquêtait sur un problème de latence du lecteur de journal. Nous accordons ici une grande attention à la latence, ainsi qu'aux transactions de longue durée, en raison de l'impact en aval sur les technologies qui utilisent le lecteur de journaux, comme les groupes de disponibilité et la réplication transactionnelle. Nos premiers avertissements sont généralement repérés sur un tableau de bord qui trace la latence du lecteur de journal par rapport à la durée de la transaction (j'expliquerai les moments dans le temps que j'ai étiquetés t0 et t1 sous peu):
Ils ont déterminé, disons au temps t0 , qu'une certaine session avait une transaction ouverte bloquant le processus de lecture du journal. Ils ont d'abord vérifié la sortie de DBCC INPUTBUFFER , pour essayer de déterminer ce que cette session a duré, mais les résultats ont simplement indiqué qu'ils ont également émis d'autres lots lors de leur transaction :
event_type parameters event_info -------------- ---------- --------------- Language Event 0 SET ROWCOUNT 0;
Notez que DBCC INPUTBUFFER a également un remplacement plus performant dans les versions modernes :sys.dm_exec_input_buffer . Et bien qu'il n'y ait pas d'avertissement d'obsolescence explicite, la documentation officielle de DBCC commande a ce petit coup de pouce :
Après n'avoir rien obtenu du tampon d'entrée, ils ont interrogé sys.sysprocesses :
SELECT spid, [status], open_tran, waittime, [cpu], physical_io, memusage, last_batch FROM sys.sysprocesses WHERE spid = 107;
Les résultats étaient tout aussi inutiles, du moins pour déterminer ce que la session avait fait pour garder leur transaction ouverte et perturber le lecteur de journal :
Je mets en surbrillance le physical_io car cette valeur a déclenché une discussion sur le fait de savoir s'ils voulaient ou non risquer de tuer la session de sommeil. L'idée était que, dans le cas où toutes ces E/S physiques seraient des écritures, l'arrêt de la transaction pourrait entraîner une restauration longue et perturbatrice, ce qui pourrait aggraver encore le problème. Je ne vais pas mettre les temps réels dessus, mais disons simplement que cela s'est transformé en une conversation prolongée, et cela a laissé le système dans cet état à partir du temps t0 au temps t1 sur le graphique ci-dessus.
Pourquoi c'est un problème
Le problème dans ce cas précis est qu'ils ont passé ce temps à envisager une décision fondée sur des renseignements incomplets. Ces E/S sont-elles en lecture ou en écriture ? Si l'utilisateur a une transaction ouverte et qu'il a simplement lu beaucoup de données, l'annulation de cette transaction a beaucoup moins d'impact que s'il a modifié beaucoup de données. Ainsi, au lieu de sys.sysprocesses , voyons ce que le DMV plus moderne, sys.dm_exec_sessions , peut nous parler de cette session :
SELECT session_id, [status], open_transaction_count, cpu_time, [reads], writes, logical_reads, last_request_start_time, last_request_end_time FROM sys.dm_exec_sessions WHERE session_id = 107;
Résultats :
Ici, nous voyons que sys.dm_exec_sessions décompose les E/S physiques séparément en lectures et écritures. Cela nous permet de prendre une décision beaucoup plus éclairée, beaucoup plus rapidement que t1 - t0 , à propos de l'impact potentiel d'une restauration. Si les E/S sont toutes en écriture, et selon la hauteur du nombre, nous pourrions hésiter un peu plus et peut-être passer du temps à essayer de localiser l'utilisateur (afin que nous puissions lui claquer les doigts ou lui demander pourquoi il a une transaction ouverte ). Si nous savons qu'il s'agit principalement de lectures, nous pouvons plutôt envisager de tuer la session et de forcer la transaction à revenir en arrière.
Bien sûr, sys.sysprocesses a dbid et waittime . Mais dbid n'est pas fiable et peu utile de toute façon, en particulier pour les requêtes entre bases de données ; il y a de bien meilleures informations dans sys.dm_tran_locks . Les informations d'attente (heure et type de dernière attente) peuvent être trouvées dans sys.dm_exec_requests , mais des informations beaucoup plus détaillées sont proposées dans sys.dm_exec_session_wait_stats (ajouté dans SQL Server 2016). Une excuse que j'entendais souvent était que sys.dm_exec_sessions manquait open_tran , mais open_transaction_count a été rajouté dans SQL Server 2012. Il y a donc très peu de raisons de penser à utiliser sys.sysprocesses aujourd'hui.
Si vous voulez découvrir à quelle fréquence sys.sysprocesses a été référencé depuis le dernier redémarrage de SQL Server, vous pouvez exécuter cette requête sur les compteurs de performances DMV :
SELECT instance_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE N'%:Deprecated Features%'
AND instance_name = N'sysprocesses'
ORDER BY cntr_value DESC;
Si vous voulez vraiment éviter de dormir ce soir, ou si vous aimez simplement ajouter constamment à la liste des choses qui vous inquiètent, supprimez le prédicat contre instance_name . Cela vous donnera une idée effrayante et de haut niveau du nombre de choses que vos instances exécutent et que vous devrez éventuellement modifier.
En attendant, allez télécharger sp_WhoIsActive , la procédure stockée ultra utile d'Adam Machanic pour surveiller et dépanner les processus SQL Server en temps réel. Nous avons déployé cette procédure stockée sur chaque instance de notre environnement, et vous devriez également le faire, quels que soient les autres outils de surveillance haut de gamme que vous utilisez également.
La prochaine fois
Dans la partie 2, je vais parler un peu de SQL Server Profiler, une application que les gens utilisent plus par familiarité qu'autre chose, sans se rendre compte à quel point cela peut être dangereux.
