OVH Cloud OVH Cloud

Problème de performance Procédure stockée curseur

12 réponses
Avatar
Olivier
Bonjour,

j'ai une procédure stockée sur un serveur (serveur taillé pour absorber une
charge trés conséquente) qui est devenues trés lente.

Avant elle s'executait en 2 secondes, aujourd'hui elle peut mettre jusqu'a 2
minutes.

J'ai essayé de rejouter des index, mais rien n'y fait. J'ai le recalcul des
statistiques qui s'executent tous les soirs.

Cette procédure provoque des crêtes de performance.

Mon serveur est un sql sp3a.

Que faire ?

10 réponses

1 2
Avatar
SQLpro [MVP]
Olivier a écrit :
Bonjour,

j'ai une procédure stockée sur un serveur (serveur taillé pour absorber une
charge trés conséquente) qui est devenues trés lente.

Avant elle s'executait en 2 secondes, aujourd'hui elle peut mettre jusqu'a 2
minutes.

J'ai essayé de rejouter des index, mais rien n'y fait. J'ai le recalcul des
statistiques qui s'executent tous les soirs.

Cette procédure provoque des crêtes de performance.

Mon serveur est un sql sp3a.

Que faire ?



1) nous donner des infos sur la machine RAM, proc, émulation, disque,
taux d'occupation des disques
2) nous donner des informations sur la base : volume des fichiers data
et JT...
3) nous montrer le code de cette PS

A +


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Avatar
Olivier
1 serveur bi pro 3 go de ram dont 2 dédié à sql raid 10, log et temps db
séparées des data. Accès disque : pas de crête contrairement à la cpu, je
n'ai pas de fragmentation.

2 Volume 100000 lignes + des jointures sur quelques petites tables

3 Cette procédure marchait trés bien avant et elle n'a pas bougé. Par contre
j'utilise une DLL sous forme de procédure etendue qui n'a pas bougé non plus.

3 le code est trés volumineux, je ne sais pas si cela sert de le montrait
étant donné qu'il n'a pas bougé et que les perf ont chutées.

"SQLpro [MVP]" a écrit :

Olivier a écrit :
> Bonjour,
>
> j'ai une procédure stockée sur un serveur (serveur taillé pour absorber une
> charge trés conséquente) qui est devenues trés lente.
>
> Avant elle s'executait en 2 secondes, aujourd'hui elle peut mettre jusqu'a 2
> minutes.
>
> J'ai essayé de rejouter des index, mais rien n'y fait. J'ai le recalcul des
> statistiques qui s'executent tous les soirs.
>
> Cette procédure provoque des crêtes de performance.
>
> Mon serveur est un sql sp3a.
>
> Que faire ?

1) nous donner des infos sur la machine RAM, proc, émulation, disque,
taux d'occupation des disques
2) nous donner des informations sur la base : volume des fichiers data
et JT...
3) nous montrer le code de cette PS

A +


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************



Avatar
SQLpro [MVP]
Olivier a écrit :
1 serveur bi pro 3 go de ram dont 2 dédié à sql raid 10, log et temps db
séparées des data. Accès disque : pas de crête contrairement à la cpu, je
n'ai pas de fragmentation.



hyper threading ?


2 Volume 100000 lignes + des jointures sur quelques petites tables

3 Cette procédure marchait trés bien avant et elle n'a pas bougé. Par contre
j'utilise une DLL sous forme de procédure etendue qui n'a pas bougé non plus.

3 le code est trés volumineux, je ne sais pas si cela sert de le montrait
étant donné qu'il n'a pas bougé et que les perf ont chutées.

"SQLpro [MVP]" a écrit :

Olivier a écrit :
Bonjour,

j'ai une procédure stockée sur un serveur (serveur taillé pour absorber une
charge trés conséquente) qui est devenues trés lente.

Avant elle s'executait en 2 secondes, aujourd'hui elle peut mettre jusqu'a 2
minutes.

J'ai essayé de rejouter des index, mais rien n'y fait. J'ai le recalcul des
statistiques qui s'executent tous les soirs.

Cette procédure provoque des crêtes de performance.

Mon serveur est un sql sp3a.

Que faire ?


1) nous donner des infos sur la machine RAM, proc, émulation, disque,
taux d'occupation des disques
2) nous donner des informations sur la base : volume des fichiers data
et JT...
3) nous montrer le code de cette PS

A +


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************







--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Avatar
Olivier
Ht --> desactive

"SQLpro [MVP]" a écrit :

Olivier a écrit :
> 1 serveur bi pro 3 go de ram dont 2 dédié à sql raid 10, log et temps db
> séparées des data. Accès disque : pas de crête contrairement à la cpu, je
> n'ai pas de fragmentation.

hyper threading ?

>
> 2 Volume 100000 lignes + des jointures sur quelques petites tables
>
> 3 Cette procédure marchait trés bien avant et elle n'a pas bougé. Par contre
> j'utilise une DLL sous forme de procédure etendue qui n'a pas bougé non plus.
>
> 3 le code est trés volumineux, je ne sais pas si cela sert de le montrait
> étant donné qu'il n'a pas bougé et que les perf ont chutées.
>
> "SQLpro [MVP]" a écrit :
>
>> Olivier a écrit :
>>> Bonjour,
>>>
>>> j'ai une procédure stockée sur un serveur (serveur taillé pour absorber une
>>> charge trés conséquente) qui est devenues trés lente.
>>>
>>> Avant elle s'executait en 2 secondes, aujourd'hui elle peut mettre jusqu'a 2
>>> minutes.
>>>
>>> J'ai essayé de rejouter des index, mais rien n'y fait. J'ai le recalcul des
>>> statistiques qui s'executent tous les soirs.
>>>
>>> Cette procédure provoque des crêtes de performance.
>>>
>>> Mon serveur est un sql sp3a.
>>>
>>> Que faire ?
>> 1) nous donner des infos sur la machine RAM, proc, émulation, disque,
>> taux d'occupation des disques
>> 2) nous donner des informations sur la base : volume des fichiers data
>> et JT...
>> 3) nous montrer le code de cette PS
>>
>> A +
>>
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> ********************* http://www.datasapiens.com ***********************
>>


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************



Avatar
SQLpro [MVP]
taux d'occupation des disques, volume des fichiers ???

A +

Olivier a écrit :
Ht --> desactive

"SQLpro [MVP]" a écrit :

Olivier a écrit :
1 serveur bi pro 3 go de ram dont 2 dédié à sql raid 10, log et temps db
séparées des data. Accès disque : pas de crête contrairement à la cpu, je
n'ai pas de fragmentation.


hyper threading ?

2 Volume 100000 lignes + des jointures sur quelques petites tables

3 Cette procédure marchait trés bien avant et elle n'a pas bougé. Par contre
j'utilise une DLL sous forme de procédure etendue qui n'a pas bougé non plus.

3 le code est trés volumineux, je ne sais pas si cela sert de le montrait
étant donné qu'il n'a pas bougé et que les perf ont chutées.

"SQLpro [MVP]" a écrit :

Olivier a écrit :
Bonjour,

j'ai une procédure stockée sur un serveur (serveur taillé pour absorber une
charge trés conséquente) qui est devenues trés lente.

Avant elle s'executait en 2 secondes, aujourd'hui elle peut mettre jusqu'a 2
minutes.

J'ai essayé de rejouter des index, mais rien n'y fait. J'ai le recalcul des
statistiques qui s'executent tous les soirs.

Cette procédure provoque des crêtes de performance.

Mon serveur est un sql sp3a.

Que faire ?


1) nous donner des infos sur la machine RAM, proc, émulation, disque,
taux d'occupation des disques
2) nous donner des informations sur la base : volume des fichiers data
et JT...
3) nous montrer le code de cette PS

A +


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************






--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************







--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Avatar
Olivier
Occupation des disques, faible (j'ai quand même 120mo de bande passante
moyenne), volume 1 GO pour une base données et 10 go pour la seconde.

Les problèmes de lenteur sont sue la petite. les tables concernées font
100000 ligne max.

"SQLpro [MVP]" a écrit :

taux d'occupation des disques, volume des fichiers ???

A +

Olivier a écrit :
> Ht --> desactive
>
> "SQLpro [MVP]" a écrit :
>
>> Olivier a écrit :
>>> 1 serveur bi pro 3 go de ram dont 2 dédié à sql raid 10, log et temps db
>>> séparées des data. Accès disque : pas de crête contrairement à la cpu, je
>>> n'ai pas de fragmentation.
>> hyper threading ?
>>
>>> 2 Volume 100000 lignes + des jointures sur quelques petites tables
>>>
>>> 3 Cette procédure marchait trés bien avant et elle n'a pas bougé. Par contre
>>> j'utilise une DLL sous forme de procédure etendue qui n'a pas bougé non plus.
>>>
>>> 3 le code est trés volumineux, je ne sais pas si cela sert de le montrait
>>> étant donné qu'il n'a pas bougé et que les perf ont chutées.
>>>
>>> "SQLpro [MVP]" a écrit :
>>>
>>>> Olivier a écrit :
>>>>> Bonjour,
>>>>>
>>>>> j'ai une procédure stockée sur un serveur (serveur taillé pour absorber une
>>>>> charge trés conséquente) qui est devenues trés lente.
>>>>>
>>>>> Avant elle s'executait en 2 secondes, aujourd'hui elle peut mettre jusqu'a 2
>>>>> minutes.
>>>>>
>>>>> J'ai essayé de rejouter des index, mais rien n'y fait. J'ai le recalcul des
>>>>> statistiques qui s'executent tous les soirs.
>>>>>
>>>>> Cette procédure provoque des crêtes de performance.
>>>>>
>>>>> Mon serveur est un sql sp3a.
>>>>>
>>>>> Que faire ?
>>>> 1) nous donner des infos sur la machine RAM, proc, émulation, disque,
>>>> taux d'occupation des disques
>>>> 2) nous donner des informations sur la base : volume des fichiers data
>>>> et JT...
>>>> 3) nous montrer le code de cette PS
>>>>
>>>> A +
>>>>
>>>>
>>>> --
>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>>>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>>>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>>>> ********************* http://www.datasapiens.com ***********************
>>>>
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> ********************* http://www.datasapiens.com ***********************
>>


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************



Avatar
SQLpro [MVP]
Olivier a écrit :
Occupation des disques, faible (j'ai quand même 120mo de bande passante
moyenne), volume 1 GO pour une base données et 10 go pour la seconde.

Les problèmes de lenteur sont sue la petite. les tables concernées font
100000 ligne max.




Difficile de dire ce qui se passe sans auditer...

A +


"SQLpro [MVP]" a écrit :

taux d'occupation des disques, volume des fichiers ???

A +

Olivier a écrit :
Ht --> desactive

"SQLpro [MVP]" a écrit :

Olivier a écrit :
1 serveur bi pro 3 go de ram dont 2 dédié à sql raid 10, log et temps db
séparées des data. Accès disque : pas de crête contrairement à la cpu, je
n'ai pas de fragmentation.


hyper threading ?

2 Volume 100000 lignes + des jointures sur quelques petites tables

3 Cette procédure marchait trés bien avant et elle n'a pas bougé. Par contre
j'utilise une DLL sous forme de procédure etendue qui n'a pas bougé non plus.

3 le code est trés volumineux, je ne sais pas si cela sert de le montrait
étant donné qu'il n'a pas bougé et que les perf ont chutées.

"SQLpro [MVP]" a écrit :

Olivier a écrit :
Bonjour,

j'ai une procédure stockée sur un serveur (serveur taillé pour absorber une
charge trés conséquente) qui est devenues trés lente.

Avant elle s'executait en 2 secondes, aujourd'hui elle peut mettre jusqu'a 2
minutes.

J'ai essayé de rejouter des index, mais rien n'y fait. J'ai le recalcul des
statistiques qui s'executent tous les soirs.

Cette procédure provoque des crêtes de performance.

Mon serveur est un sql sp3a.

Que faire ?


1) nous donner des infos sur la machine RAM, proc, émulation, disque,
taux d'occupation des disques
2) nous donner des informations sur la base : volume des fichiers data
et JT...
3) nous montrer le code de cette PS

A +


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************





--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************






--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************







--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Avatar
Olivier
comment puis-je auditer ?

Car nous avons fait venir un dba qui n'a rien vu et nous avons encore des
problèmes (sur des requêtes bien identifiées) malgré son intervention.

J'ai fait un profiler de la procédure et il y a le deroulement du curseur
qui prend pas mal de temps. C'est quand même étrange cette perte de
performances inexpliquée.

"SQLpro [MVP]" a écrit :

Olivier a écrit :
> Occupation des disques, faible (j'ai quand même 120mo de bande passante
> moyenne), volume 1 GO pour une base données et 10 go pour la seconde.
>
> Les problèmes de lenteur sont sue la petite. les tables concernées font
> 100000 ligne max.
>

Difficile de dire ce qui se passe sans auditer...

A +


> "SQLpro [MVP]" a écrit :
>
>> taux d'occupation des disques, volume des fichiers ???
>>
>> A +
>>
>> Olivier a écrit :
>>> Ht --> desactive
>>>
>>> "SQLpro [MVP]" a écrit :
>>>
>>>> Olivier a écrit :
>>>>> 1 serveur bi pro 3 go de ram dont 2 dédié à sql raid 10, log et temps db
>>>>> séparées des data. Accès disque : pas de crête contrairement à la cpu, je
>>>>> n'ai pas de fragmentation.
>>>> hyper threading ?
>>>>
>>>>> 2 Volume 100000 lignes + des jointures sur quelques petites tables
>>>>>
>>>>> 3 Cette procédure marchait trés bien avant et elle n'a pas bougé. Par contre
>>>>> j'utilise une DLL sous forme de procédure etendue qui n'a pas bougé non plus.
>>>>>
>>>>> 3 le code est trés volumineux, je ne sais pas si cela sert de le montrait
>>>>> étant donné qu'il n'a pas bougé et que les perf ont chutées.
>>>>>
>>>>> "SQLpro [MVP]" a écrit :
>>>>>
>>>>>> Olivier a écrit :
>>>>>>> Bonjour,
>>>>>>>
>>>>>>> j'ai une procédure stockée sur un serveur (serveur taillé pour absorber une
>>>>>>> charge trés conséquente) qui est devenues trés lente.
>>>>>>>
>>>>>>> Avant elle s'executait en 2 secondes, aujourd'hui elle peut mettre jusqu'a 2
>>>>>>> minutes.
>>>>>>>
>>>>>>> J'ai essayé de rejouter des index, mais rien n'y fait. J'ai le recalcul des
>>>>>>> statistiques qui s'executent tous les soirs.
>>>>>>>
>>>>>>> Cette procédure provoque des crêtes de performance.
>>>>>>>
>>>>>>> Mon serveur est un sql sp3a.
>>>>>>>
>>>>>>> Que faire ?
>>>>>> 1) nous donner des infos sur la machine RAM, proc, émulation, disque,
>>>>>> taux d'occupation des disques
>>>>>> 2) nous donner des informations sur la base : volume des fichiers data
>>>>>> et JT...
>>>>>> 3) nous montrer le code de cette PS
>>>>>>
>>>>>> A +
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>>>>>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>>>>>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>>>>>> ********************* http://www.datasapiens.com ***********************
>>>>>>
>>>> --
>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>>>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>>>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>>>> ********************* http://www.datasapiens.com ***********************
>>>>
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> ********************* http://www.datasapiens.com ***********************
>>


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************



Avatar
SQLpro [MVP]
Olivier a écrit :
comment puis-je auditer ?



C'est une procédure assez longue....

1) obtenir les infos du serveur (machine physique) et voir ce qui est
adéquat et ne l'est pas

2) obtenir les infos du serveur OS et voir ce qui est adéquat et ne
l'est pas

perfmon / sysperfinfo


3) obtenir les infos du serveur SQL et voir ce qui est adéquat et ne
l'est pas

profiler SQL


4) analyser la structure de la base de données en cours et déterminer
les erreurs du modèles et ce qui peut être améliorer


5) analyser les statistiques de données et la volumétrie pour voir quels
sont les goulets d'étranglement

6) analyser les plans de requêtes pour les 20% des requêtes globalisées
qui consommes le plus les temps machine


7) analyser l'écriture du code Transact SQL

8) analyser le style de développement client

...

bref 5 à 8 jours de travail pour un spécialiste de la chose....




Car nous avons fait venir un dba qui n'a rien vu et nous avons encore des
problèmes (sur des requêtes bien identifiées) malgré son intervention.



Ce n'est pas un DBA qu'il vous faut mais un expert qui est capable de
réaliser un audit !


J'ai fait un profiler de la procédure et il y a le deroulement du curseur
qui prend pas mal de temps. C'est quand même étrange cette perte de
performances inexpliquée.



Tout s'explique à conditions d'employer les moyens adéquats.

A +


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************


"SQLpro [MVP]" a écrit :

Olivier a écrit :
Occupation des disques, faible (j'ai quand même 120mo de bande passante
moyenne), volume 1 GO pour une base données et 10 go pour la seconde.

Les problèmes de lenteur sont sue la petite. les tables concernées font
100000 ligne max.



Difficile de dire ce qui se passe sans auditer...

A +


"SQLpro [MVP]" a écrit :

taux d'occupation des disques, volume des fichiers ???

A +

Olivier a écrit :
Ht --> desactive

"SQLpro [MVP]" a écrit :

Olivier a écrit :
1 serveur bi pro 3 go de ram dont 2 dédié à sql raid 10, log et temps db
séparées des data. Accès disque : pas de crête contrairement à la cpu, je
n'ai pas de fragmentation.


hyper threading ?

2 Volume 100000 lignes + des jointures sur quelques petites tables

3 Cette procédure marchait trés bien avant et elle n'a pas bougé. Par contre
j'utilise une DLL sous forme de procédure etendue qui n'a pas bougé non plus.

3 le code est trés volumineux, je ne sais pas si cela sert de le montrait
étant donné qu'il n'a pas bougé et que les perf ont chutées.

"SQLpro [MVP]" a écrit :

Olivier a écrit :
Bonjour,

j'ai une procédure stockée sur un serveur (serveur taillé pour absorber une
charge trés conséquente) qui est devenues trés lente.

Avant elle s'executait en 2 secondes, aujourd'hui elle peut mettre jusqu'a 2
minutes.

J'ai essayé de rejouter des index, mais rien n'y fait. J'ai le recalcul des
statistiques qui s'executent tous les soirs.

Cette procédure provoque des crêtes de performance.

Mon serveur est un sql sp3a.

Que faire ?


1) nous donner des infos sur la machine RAM, proc, émulation, disque,
taux d'occupation des disques
2) nous donner des informations sur la base : volume des fichiers data
et JT...
3) nous montrer le code de cette PS

A +


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************





--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************





--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************






--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************





Avatar
Olivier
Bonjour,

nous avons fait tout cela mais rien n'y fait nous avons encore quelques
problèmes.

La machine est neuve, c'est une bête de course, et nous avons des problèmes,
la config sql est correcte. Les index et code ont été regardé à plusieurs
reprises.

Ce que je ne comprends pas c'est pourquoi de temps en temps le système se
met à s'affoler (essentiellement sur les procédures stockées d'une table)
alors qu'il n'y a pas de locks.

Avez vous déjà vu des cas similaires ?

"SQLpro [MVP]" a écrit :

Olivier a écrit :
> comment puis-je auditer ?

C'est une procédure assez longue....

1) obtenir les infos du serveur (machine physique) et voir ce qui est
adéquat et ne l'est pas

2) obtenir les infos du serveur OS et voir ce qui est adéquat et ne
l'est pas

perfmon / sysperfinfo


3) obtenir les infos du serveur SQL et voir ce qui est adéquat et ne
l'est pas

profiler SQL


4) analyser la structure de la base de données en cours et déterminer
les erreurs du modèles et ce qui peut être améliorer


5) analyser les statistiques de données et la volumétrie pour voir quels
sont les goulets d'étranglement

6) analyser les plans de requêtes pour les 20% des requêtes globalisées
qui consommes le plus les temps machine


7) analyser l'écriture du code Transact SQL

8) analyser le style de développement client

....

bref 5 à 8 jours de travail pour un spécialiste de la chose....



>
> Car nous avons fait venir un dba qui n'a rien vu et nous avons encore des
> problèmes (sur des requêtes bien identifiées) malgré son intervention.

Ce n'est pas un DBA qu'il vous faut mais un expert qui est capable de
réaliser un audit !

>
> J'ai fait un profiler de la procédure et il y a le deroulement du curseur
> qui prend pas mal de temps. C'est quand même étrange cette perte de
> performances inexpliquée.

Tout s'explique à conditions d'employer les moyens adéquats.

A +


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************

>
> "SQLpro [MVP]" a écrit :
>
>> Olivier a écrit :
>>> Occupation des disques, faible (j'ai quand même 120mo de bande passante
>>> moyenne), volume 1 GO pour une base données et 10 go pour la seconde.
>>>
>>> Les problèmes de lenteur sont sue la petite. les tables concernées font
>>> 100000 ligne max.
>>>
>> Difficile de dire ce qui se passe sans auditer...
>>
>> A +
>>
>>
>>> "SQLpro [MVP]" a écrit :
>>>
>>>> taux d'occupation des disques, volume des fichiers ???
>>>>
>>>> A +
>>>>
>>>> Olivier a écrit :
>>>>> Ht --> desactive
>>>>>
>>>>> "SQLpro [MVP]" a écrit :
>>>>>
>>>>>> Olivier a écrit :
>>>>>>> 1 serveur bi pro 3 go de ram dont 2 dédié à sql raid 10, log et temps db
>>>>>>> séparées des data. Accès disque : pas de crête contrairement à la cpu, je
>>>>>>> n'ai pas de fragmentation.
>>>>>> hyper threading ?
>>>>>>
>>>>>>> 2 Volume 100000 lignes + des jointures sur quelques petites tables
>>>>>>>
>>>>>>> 3 Cette procédure marchait trés bien avant et elle n'a pas bougé. Par contre
>>>>>>> j'utilise une DLL sous forme de procédure etendue qui n'a pas bougé non plus.
>>>>>>>
>>>>>>> 3 le code est trés volumineux, je ne sais pas si cela sert de le montrait
>>>>>>> étant donné qu'il n'a pas bougé et que les perf ont chutées.
>>>>>>>
>>>>>>> "SQLpro [MVP]" a écrit :
>>>>>>>
>>>>>>>> Olivier a écrit :
>>>>>>>>> Bonjour,
>>>>>>>>>
>>>>>>>>> j'ai une procédure stockée sur un serveur (serveur taillé pour absorber une
>>>>>>>>> charge trés conséquente) qui est devenues trés lente.
>>>>>>>>>
>>>>>>>>> Avant elle s'executait en 2 secondes, aujourd'hui elle peut mettre jusqu'a 2
>>>>>>>>> minutes.
>>>>>>>>>
>>>>>>>>> J'ai essayé de rejouter des index, mais rien n'y fait. J'ai le recalcul des
>>>>>>>>> statistiques qui s'executent tous les soirs.
>>>>>>>>>
>>>>>>>>> Cette procédure provoque des crêtes de performance.
>>>>>>>>>
>>>>>>>>> Mon serveur est un sql sp3a.
>>>>>>>>>
>>>>>>>>> Que faire ?
>>>>>>>> 1) nous donner des infos sur la machine RAM, proc, émulation, disque,
>>>>>>>> taux d'occupation des disques
>>>>>>>> 2) nous donner des informations sur la base : volume des fichiers data
>>>>>>>> et JT...
>>>>>>>> 3) nous montrer le code de cette PS
>>>>>>>>
>>>>>>>> A +
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>>>>>>>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>>>>>>>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>>>>>>>> ********************* http://www.datasapiens.com ***********************
>>>>>>>>
>>>>>> --
>>>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>>>>>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>>>>>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>>>>>> ********************* http://www.datasapiens.com ***********************
>>>>>>
>>>> --
>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>>>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>>>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>>>> ********************* http://www.datasapiens.com ***********************
>>>>
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> ********************* http://www.datasapiens.com ***********************
>>




1 2