Discussion :

[lerieure]

Bonjour,

J'ai trois façons de faire un Trigger l'un avec des curseurs l'autre avec une table temporaire, et un autre avec une énorme requête qui utilise les "union all" et "intersect"...
J'ai fait les trois et j'aimerais voir le gain ou la perte de performance pour chacun...

Je sais qu'il y a le "Activity Monitor" dans SQL Management studio mais je sais pas m'en servir ...

Le plus important serait de voir le temps d'exécution après s'il y a plus c'est que mieux !!!

Je spécifie que je connais déjà le résultat, soit l'énorme requête, la table temporaire et les curseurs dans l'ordre de rapidité, mais il me faudrait des preuves.

Merci de votre aide membre de développez !

[Jinroh77]

Un petit

Code :

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

1
2
3
SET statistics IO ON
....
set statistics IO OFF

pour les information d'I/O
ou encore

Code :

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

1
2
3
SET statistics TIME ON
....
set statistics TIME OFF

pour le temps CPU

[elsuket]

Bonjour,

Attention à ce que vous retourne SET STATISTICS TIME, car :

• le temps d'exécution dépend ce qui se passe dans la base de données et / ou sur le serveur. Donc soyez certain que vous êtes seul à tester sur l'instance SQL Server

• Exécutez la requête deux fois au moins puisque la première exécution comprendra la temps de compilation de la requête qui déclenche le trigger

[lerieure]

si je suis pas le seul sur l'instance ça expliquerait le fait que le résultat de mon message contient une centaine de

Code :

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

1
2
SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 2 ms.

Avec différentes valeurs...?

car j'ai fait un INSERT et je suis sur d'être le seul a utiliser la table...
Donc je comprends pas pourquoi j'aurais une centaine de message...

[elsuket]

Cela est dû aux diverses instructions qui composent l'instruction qui déclenche le trigger et a l'exécution du trigger lui-même.
Il y a je crois deux sorties par instruction ...

@++

[lerieure]

Cela est dû aux diverses instructions qui composent l'instruction qui déclenche le trigger et a l'exécution du trigger lui-même.
Il y a je crois deux sorties par instruction ...

Et c'est possible d'avoir la somme des temps des instructions qui composent l'instruction qui déclenche le trigger ?

ou il faut compter à la main xD

[elsuket]

Le mieux est pour cela d'utiliser le Profiler ou bien les statistiques du client.
Mais dans ce dernier cas, vous n'aurez que la durée totale d'exécution ...

@++

[lerieure]

Le mieux est pour cela d'utiliser le Profiler ou bien les statistiques du client.

Merci beaucoup je vais voir de ce coté alors connaissez vous un tuto sur l'utilisation du Profiler ?

(ps le lien ne marche pas pour moi "statistiques du client")

[elsuket]

Désolé pour les statistiques du client, je viens de corriger le lien.

Pour le Profiler, j'ai créé un tutoriel sur les traces côté serveur.
Dans votre cas, vous n'avez besoin que d'une trace côté client, donc vous pouvez suivre le tutoriel jusqu'au paragraphe II inclus.

Après avoir décoché tous les événements précochés, cliquez sur le bouton "Show all events", puis dans la catégorie T-SQL, cochez la colonne TextData et duration (en microsecondes) de l'événement SQL:StmtCompleted.
Ajoutez également Reads et Writes pour avoir le nombre de pages lues et écrites par chaque requête.

Cliquez enfin sur le bouton "Run".

Exécutez maintenant vos requêtes : elle vont s'afficher dans le Profiler, avec leur caractéristiques d'exécution

Si vous exécutez une trace alors que vous êtes plusieurs à exécuter des requêtes sur la base de données ou que vous êtes en production, sélectionnez toujours le minimum de colonnes et d'événements, afin de minimiser la charge.
N'oubliez également jamais d'enregistrer dans un fichier (Cochez la case portant le même nom à la 2e capture d'écran de mon tutoriel )

@++