Lors d’une investigation d’un problème de performance avec D365 for Finance and Operations, j’ai exécuté le script
Find Most Expensive Queries Using DMV de Pinal Dave et j’ai trouvé ceci:
Étant donné que le processus était toujours en cours d’exécution dans l’application, j'ai utilisé mon
script qui me retourne toute les requêtes en cours d’exécution et j’ai vu le résultat ci-dessous. Il faut dire que ce fut par chance parce que comme vous pouvez le voir, c’est une petite requête qui ne consomme pas de CPU, reads, writes et logicial reads, donc elle passe vite. J’ai dû exécuter mon script plusieurs fois avant avant de la voir.
Afin de voir la requête derrière le curseur, l’article mentionner plus haut propose la requête suivante (il faut remplacer le chiffre 53 par le SPID):
SELECT c.session_id, c.properties, c.creation_time, c.is_open, t.text
FROM sys.dm_exec_cursors (53) c
CROSS APPLY sys.dm_exec_sql_text (c.sql_handle) t
Celle-ci fonctionne bien si le SPID reste le même pour une longue durée. Pour ma part, j’ai fait une modification au script afin de voir tous les curseurs ouverts en ordre de worker_time, read and writes afin de facilement identifier le curseur qui consomme le plus de ressource.
SELECT c.session_id, c.properties, c.creation_time, c.is_open, t.text, worker_time, reads, writes
FROM sys.dm_exec_cursors (0) c
CROSS APPLY sys.dm_exec_sql_text (c.sql_handle) t
ORDER BY
worker_time DESC,
reads DESC,
writes DESC
Voilà, je peux maintenant voir les requêtes en question.
