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.
Qu’est-ce que FETCH_API ? C’est bien expliquer dans l’article suivant: Hunting down the origins of FETCH API_CURSOR and sp_cursorfetch. En résumé, le curseur est défini au début de la transaction et SQL travaille a l’intérieur de ce curseur.
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.