Bases de sys.dm_exec

La surveillance des performances et le dépannage dans SQL Server sont un vaste sujet. Dans SQL Server 2005, des vues de gestion dynamiques, également appelées DMV, ont été introduites et sont devenues un outil d'aide essentiel pour diagnostiquer les problèmes de performances de SQL Server. Dans le même temps, nous pouvons utiliser des vues de gestion dynamiques pour Azure SQL Database. Certains d'entre eux peuvent différer de la base de données sur site SQL Server, mais la logique de travail est toujours la même. Microsoft a une très bonne documentation sur les vues de gestion dynamiques. La seule chose, vous devez faire attention à la version et à la validation du produit des vues de gestion dynamiques. Par exemple, sys.dm_exec_request est disponible pour SQL Server 2008 et les versions ultérieures et pour la base de données Azure SQL, mais sys.dm_db_wait_stats n'est valide que pour la base de données Azure SQL.

Dans cet article, nous parlerons des bases de sys.dm_exec_request. sys.dm_exec_requests est une vue de gestion dynamique qui renvoie uniquement les demandes en cours d'exécution. Cela signifie que lorsque vous exécutez la requête sys.dm_exec_requests, elle prend un instantané de la requête en cours d'exécution à ce moment-là et n'inclut aucune donnée historique. Par conséquent, cette vue est très pratique pour surveiller les requêtes en temps réel. En d'autres termes, il donne la réponse à "que se passe-t-il sur mon serveur en ce moment ?" Cette vue comprend de nombreux détails, mais nous aborderons les plus importants.

session_id :Cette valeur définit un numéro d'identification de session. Dans SQL Server, les ID de session inférieurs ou égaux à 50 sont dédiés au processus d'arrière-plan.

start_time :Cette valeur définit la date et l'heure de début de la requête.

statut :Cette valeur définit un statut de la requête. Les statuts disponibles sont :

contexte
courir
exécutable
dormir
suspendu

SELECT DISTINCT status
FROM sys.dm_exec_requests
WHERE session_id <>@@SPID

contexte :Ce type d'état définit les processus d'arrière-plan. Certains d'entre eux sont LAZY WRITER, CHECKPOINT et LOG WRITER.

select session_id, command, os_thread_id from sys.dm_exec_requests as r
 join sys.dm_os_workers as w on r.task_address = w.task_address
 join sys.dm_os_threads as t on t.thread_address = w.thread_address
 where session_id <= 50
 order by session_id

courir :Ce type d'état définit que la requête est en cours de traitement par le processeur.

 select * from sys.dm_exec_requests where status='running'
 and session_id <>@@SPID

exécutable :Ce type d'état peut être simplement défini comme une requête en attente d'exécution dans la file d'attente de la CPU. Si vous détectez un grand nombre de processus exécutables dans sys.dm_exec_requests, cela peut être un symptôme de pression du processeur. Cette métrique n'est pas suffisante pour diagnostiquer ce problème de performances du processeur. Pour cette raison, nous devons étayer cette affaire avec plus de preuves. C'est important pour nous de prouver notre théorie. La vue de gestion dynamique sys.dm_os_wait_stats inclut une colonne qui est signal_wait_time_ms. Cette valeur de colonne peut être une aide pour déterminer le problème de CPU. La requête suivante nous montre le pourcentage de Signalwait. Si cette métrique a une valeur élevée, vous êtes probablement confronté à un problème de performances du processeur. Vous pouvez ainsi approfondir votre examen.

---https://sqlserverperformance.wordpress.com/page/146/
---Glenn Berry's SQL Server Performance 

SELECT signal_wait_time_ms=SUM(signal_wait_time_ms)
              ,'%signal (cpu) waits' = CAST(100.0 * SUM(signal_wait_time_ms) / SUM (wait_time_ms) AS NUMERIC(20,2))
              ,resource_wait_time_ms=SUM(wait_time_ms - signal_wait_time_ms)
              ,'%resource waits'= CAST(100.0 * SUM(wait_time_ms - signal_wait_time_ms) / SUM (wait_time_ms) AS NUMERIC(20,2))
FROM sys.dm_os_wait_stats;

suspendu :Ce type de statut définit le processus d'attente de certaines ressources. Cela peut être I/O, LOCK et LATCH etc. Comme mentionné ci-dessus, nous pouvons utiliser le sys.dm_os_wait_stats vue de gestion dynamique pour détecter wait_time_ms.

dormir :Cela signifie que la requête est connectée à SQL Server mais qu'aucune commande n'est actuellement en cours d'exécution.

commande :Cette colonne définit un type de commande en cours d'exécution. En même temps, nous pouvons trouver des informations supplémentaires pour des commandes particulières qui sont un taux d'achèvement. Selon les livres en ligne, ce sont :

ALTER INDEX REORGANIZE

Option AUTO_SHRINK avec ALTER DATABASE

SAUVEGARDE DE LA BASE DE DONNÉES

DBCC CHECKDB

DBCC CHECKFILEGROUP

TABLE DE VÉRIFICATION DBCC

DBCC INDEXDEFRAG

DBCC SHRINKDATABASE

DBCC SHRINKFILE

RÉCUPÉRATION

RESTAURER LA BASE DE DONNÉES

ROLLBACK

CHIFFREMENT TDE

Démo :

Connectez la base de données principale et démarrez la sauvegarde de n'importe quelle base de données.
```
BACKUP DATABASE WideWorldImporters TO DISK ='NUL'
```
Astuce :Lorsque vous effectuez la sauvegarde de la base de données sur le périphérique "NUL", SQL Server n'écrit aucun fichier de sauvegarde nulle part et vous évitez la suppression d'un fichier de sauvegarde de test. Mais n'utilisez pas cette commande dans votre environnement de production. Cela peut entraîner la rupture de la chaîne LSN.

Exécutez la requête suivante :

SELECT command,percent_complete ,*
FROM sys.dm_exec_requests
WHERE session_id <>@@SPID
and session_id>50 and command='BACKUP DATABASE'

sql_handle :Cette valeur définit l'instruction SQL de la requête. Mais cette valeur est au format bitmap. Pour cette raison, nous devons utiliser la fonction table sys.dm_exec_sql_text pour convertir la valeur en texte significatif.

select session_id ,command , sqltxt.text ,database_id
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
where session_id<>@@SPID AND session_id>50

database_id :Cette valeur définit quelle base de données effectue la requête. Nous pouvons joindre ce champ à sys.databases pour obtenir le nom de la base de données.

select session_id ,command , sqltxt.text ,db.name
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
inner join sys.databases db on db.database_id = req.database_id
where session_id<>@@SPID AND session_id>50

type_attente :Cette valeur définit le type d'attente actuel de la requête. Si la durée d'exécution de la requête prend plus de temps que prévu, vous pouvez vérifier et déterminer le type d'attente de la requête.

transaction_isolation_level :Cette valeur définit le niveau de transaction de la requête soumise :

0=Non spécifié

1=Lire non validé

2=LireCommis

3=Répétable

4=Sérialisable

5=Instantané

select session_id ,command , sqltxt.text ,db.name,req.status,wait_type ,transaction_isolation_level,
CASE transaction_isolation_level
WHEN 0 THEN 'Unspecified'
WHEN 1 THEN 'ReadUncomitted'
WHEN 2 THEN 'ReadCommitted'
WHEN 3 THEN 'Repeatable'
WHEN 4 THEN 'Serializable'
WHEN 5 THEN 'Snapshot'
END
AS isolation_level_name
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
inner join sys.databases db on db.database_id = req.database_id
where session_id<>@@SPID AND session_id>50

blocking_session_id :C'est l'identifiant de la session qui bloque la requête. Si cette colonne est NULL, la requête n'a bloqué aucune session.

Démo :

Ouvrez SQL Server Management Studio et exécutez la requête suivante.

DROP TABLE IF EXISTS TestPerfomon
GO
CREATE TABLE TestPerfomon
(ID INT ,
Nm VARCHAR(100))

INSERT INTO TestPerfomon
VALUES(1,1)
GO
BEGIN TRAN
UPDATE TestPerfomon SET Nm='2'
WHERE ID=1

SELECT @@SPID AS blocking_session_id

Ouvrez une nouvelle fenêtre de requête et exécutez la requête suivante.

SET TRANSACTION ISOLATION LEVEL Serializable
BEGIN TRAN
UPDATE TestPerfomon SET Nm='3'
WHERE ID=1

Ouvrez une autre nouvelle fenêtre de requête et exécutez cette requête DMV.

select session_id ,command , sqltxt.text ,db.name,req.status,wait_type ,transaction_isolation_level,
CASE transaction_isolation_level
WHEN 0 THEN 'Unspecified'
WHEN 1 THEN 'ReadUncomitted'
WHEN 2 THEN 'ReadCommitted'
WHEN 3 THEN 'Repeatable'
WHEN 4 THEN 'Serializable'
WHEN 5 THEN 'Snapshot'
END
AS isolation_level_name ,
blocking_session_id
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
inner join sys.databases db on db.database_id = req.database_id
where session_id<>@@SPID AND session_id>50

Avec cette démonstration, nous avons découvert la raison pour laquelle la deuxième requête est bloquée et quelle session est bloquée la requête. Lorsque vous exécutez sp_BlitzWho 65, vous pouvez connaître les détails du blocage et les détails de la session bloquée.

sp_BlitzWho 65

Dans cette démonstration, nous avons récupéré les détails des sessions bloquantes et bloquées et en même temps, nous avons obtenu les détails de ces sessions. Il s'agit d'une démonstration très basique, mais elle montre comment le problème peut être résolu.

Dans cet article, nous avons parlé de sys.sys.dm_exec_requests. Cette vue de gestion dynamique nous donne la flexibilité d'obtenir un instantané pendant l'échelon actuel d'une demande. De plus, ces données détaillées peuvent nous aider ou nous guider tout au long du processus de découverte du problème.

Références

sys.dm_exec_requests (Transact SQL)
Surveillance d'Azure SQL Database à l'aide de vues de gestion dynamiques
sys.dm_db_wait_stats (base de données SQL Azure)

Outil utile :

dbForge Monitor - complément pour Microsoft SQL Server Management Studio qui vous permet de suivre et d'analyser les performances de SQL Server.

Bases de sys.dm_exec_requests

Outil utile :