Discussion :

[Pozzo]

Bonjour,

Je fais du monitoring par SQL d'un traitement qui utilise une base de données SQL server 2016.
J'utilise les magasins de requêtes pour tracer les requêtes et déterminer ensuite des actions d'optimisation
=> Ca à l'air de fonctionner: J'ai bien mes requêtes, plein de stats, des plan d'exécution...

J'aimerais maintenant synchroniser au sein d'un rapport les actions enregistrées dans le magasin de requêtes d'une part, et les journaux du traitement en question d'autre part, qui sont horodatées.

Journal du traitement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
15:28:02 Debut de traitement
15:30:25 Entrée dans le module bidule
15:32:28 Avertissement il y a blabla
...
15:50:25 Fin du traitement

Cependant dans les tables du magasins de requêtes les stats stockées dans sys.query_store_runtime_stats donnent deux dates:
first_execution_time
last_execution_time
=> PAS de date d'exécution de la requête elle même.
La clé unique de cette table est d'ailleurs composée de plan_id, execution_type, runtime_stats_interval_id, ce dernier champ faisant référence à un INTERVALLE de statistiques.

>>>Ma question est: Est-il possible de connaître chaque date d'exécution d'une requête particulière dans sql server ?<<<

Même sans les stats cela me permettrait de synchroniser les différentes traces sur la date d'exécution.

Si ça parle à quelqu'un...

Pozzo.

[SQLpro]

Non.... Imaginez une requête qui tourne 3 millions de fois par heure !

A +

[Pozzo]

Merci SQLpro de cette réponse.
Je marque la demande à résolue.

Bonne journée,
Pozzo

[hmira]

Non.... Imaginez une requête qui tourne 3 millions de fois par heure !

A +

Bonjour SQLPro,

Oui, tout à fait, c'est ce que l'on observe parfois avec les fonctions scalaires basées sur des requêtes (SELECT ... FROM .. JOIN etc.) pour retourner une valeur atomique.
Les dites fonction scalaires sont ensuite utilisées dans des clauses WHERE, mal goupillées, générant ainsi des expressions NON-SARG.
Les expressions NON-SARG génèrent à leur tour des FULL SCAN sur des tables volumineuses contenant parfois plusieurs millions, voire même, plusieurs dizaines de millions de lignes !
Et c'est donc comme cela que l’on observe des requêtes qui s'exécutent 3 millions de fois par heure, voire même, beaucoup plus !

A+,