Discussion :

[Monstros Velu]

Code :

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

select 1 from tempdb..sysobjects where name = '##LOCK_BSI_VALIDATION' and type = 'U'

a pris 30% des 5 minutes du temps d'execution. Il y en a 2 autres comme ça.

(##LOCK_BSI_VALIDATION est une table temporaire associée à la connetion sql, créée lors de l'exécution de la procédure, pour éviter que celle-ci s'execute plusieurs fois en même temps et renvoie un message adéquat)

Ce que je trouve étrange, c'est que parfois, la procédure stockée se termine totalement en moins de 10s, et parfois, il lui faut 5 minutes...

[Yanika_bzh]

Code :

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

select 1 from tempdb..sysobjects where name = '##LOCK_BSI_VALIDATION' and type = 'U'

a pris 30% des 5 minutes du temps d'execution. Il y en a 2 autres comme ça.

(##LOCK_BSI_VALIDATION est une table temporaire associée à la connetion sql, créée lors de l'exécution de la procédure, pour éviter que celle-ci s'execute plusieurs fois en même temps et renvoie un message adéquat)

Ce que je trouve étrange, c'est que parfois, la procédure stockée se termine totalement en moins de 10s, et parfois, il lui faut 5 minutes...

Si vous jouez cette requete seule, vous observez le meme comportement ?
comment est configuré votre tempdb (device, logique, pages ...) ?

[Monstros Velu]

La requête seule est quasi-instantanée.

En dev, tout est sur le même disque dur, DB, log, temp...

Mon chef de projet vient de me passer un script de nettoyage de la base écrit par mon prédécesseur, peut-être pour ce genre de problème (BSI contient 10 millions de lignes)

[pacmann]

(##LOCK_BSI_VALIDATION est une table temporaire associée à la connetion sql, créée lors de l'exécution de la procédure, pour éviter que celle-ci s'execute plusieurs fois en même temps et renvoie un message adéquat)

Et elle sert à quoi plus précisément ? Elle fait combien de lignes (c'est elle qui fait 10 Millions) ?
Les 30% du temps, c'est une seule occurence de la requête ?
Vous avez un moyen (commen en Oracle) d'avoir les "wait events" ?

[Monstros Velu]

Et elle sert à quoi plus précisément ? Elle fait combien de lignes (c'est elle qui fait 10 Millions) ?
Les 30% du temps, c'est une seule occurence de la requête ?
Vous avez un moyen (commen en Oracle) d'avoir les "wait events" ?

Cette table ne contient rien, elle sert juste à vérifier que la requête ne tourne pas déjà. C'est une table temporaire qui dure jusqu'à la fin de la connexion: Au début de la requête, son existence est vérifiée : Si elle existe, on remonte une erreur et on s'arrête, si elle n'existe pas, on la crée et on continue. A la fin de la connexion, elle est détruite, et la boucle suivante (C#) ouvre une nouvelle connectin pour relancer la requête.

Les 30% du temps, c'est sur une seule occurence. Et je n'a aucune idée de comment voir les "wait events".

[pacmann]

Ca veut donc dire qu'une partie de ton problème de perf n'est pas due à des indexes, des plans d'exécution foireux, ... mais à ?

Et c'est justement ça le but des wait events chez "nous" :
Au lieu de se focaliser sur les problématiques d'accès disque ou de plan d'exécution, on se demande "qu'est ce qui a pris du temps".

Typiquement ici, est-ce un quelconque lock / latch qui fait attendre ?
Dur de t'en dire plus juste comme ça... (mais tu as peut être un moyen d'approfondir l'analyse ?)

[elsuket]

Bonjour,

Méfiez-vous de l'utilisation des tables temporaires

Vous avez tout intérêt à créer de vraies tables dans une base de données autre que les bases de données système

@++

[Monstros Velu]

L'historisation et la vidange de la table BSI (9 millions de lignes) ont entrainé la hausse de performance espérée. Je n'ai donc eu qu'à exécuter les scripts déjà existants pour régler ce problème déjà connu par mon prédécesseur sur ce projet, et tout se fait désormais en quelques secondes.

Merci à tous pour l'aide !