J'ai de s=E9rieux probl=E8mes pour localiser les mauvaises=20
performances de requ=EAtes.
J'ai lanc=E9 diff=E9rentes traces pour tester, et =E0 chaque=20
fois j'ai les m=EAmes r=E9sultats:
Par exemple sur 200 ex=E9cutions d'une m=EAme requ=EAte, 190=20
mettent moins d'1 seconde pour s'ex=E9cuter, et 10 mettent=20
de 2 =E0 5s. Il peut s'agir de requ=EAtes comme de procs=20
stocks, les param=E8tres quand il y en a sont rigoureusement=20
identiques...
J'ai donc naturellement pens=E9 =E0 des pb de locks, mais les=20
traces que j'ai ex=E9cut=E9 dans cette optique m'ont dit que=20
tout allait bien.
J'ai essay=E9 de voir ce qui pouvait se passer en m=EAme temps=20
sur la base, rien.
Le serveur est 100% d=E9di=E9 =E0 la base de donn=E9es.
Je commence =E0 s=E9cher, d'autant que c'est syst=E9matique sur=20
toutes les requ=EAtes: sur 10min de trace, je suis s=FBr=20
d'avoir 300 requ=EAtes dans ce cas...
Si quelqu'un a des infos ou des pistes pour chercher, je=20
suis preneur!! ^_^;
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Med Bouchenafa[MVP]
Dans le cas de procédure stockée, essaye de regarder si cela ne coïncide pas avec une recompilation de la procédure stockée. Il est possible qu'au bout d'un certain temps d'inutilisation, la procédure est sortie du cache. A son rappel, elle est recompilée à nouveau, ce qui forcément prend plus de temps. Pour cela, essaye de tracer l'événement "sp-recompil" (je crois de tête) Auquel cas, il te faudra un peu plus de RAM
-- Salutations Med Bouchenafa TETRASET 75015 Paris
"Patrick" wrote in message news:05cd01c37852$bb9a5150$ Bonjour
J'ai de sérieux problèmes pour localiser les mauvaises performances de requêtes. J'ai lancé différentes traces pour tester, et à chaque fois j'ai les mêmes résultats: Par exemple sur 200 exécutions d'une même requête, 190 mettent moins d'1 seconde pour s'exécuter, et 10 mettent de 2 à 5s. Il peut s'agir de requêtes comme de procs stocks, les paramètres quand il y en a sont rigoureusement identiques... J'ai donc naturellement pensé à des pb de locks, mais les traces que j'ai exécuté dans cette optique m'ont dit que tout allait bien. J'ai essayé de voir ce qui pouvait se passer en même temps sur la base, rien. Le serveur est 100% dédié à la base de données. Je commence à sécher, d'autant que c'est systématique sur toutes les requêtes: sur 10min de trace, je suis sûr d'avoir 300 requêtes dans ce cas... Si quelqu'un a des infos ou des pistes pour chercher, je suis preneur!! ^_^;
Patrick
Dans le cas de procédure stockée, essaye de regarder si cela ne coïncide pas
avec une recompilation de la procédure stockée.
Il est possible qu'au bout d'un certain temps d'inutilisation, la procédure
est sortie du cache.
A son rappel, elle est recompilée à nouveau, ce qui forcément prend plus de
temps.
Pour cela, essaye de tracer l'événement "sp-recompil" (je crois de tête)
Auquel cas, il te faudra un peu plus de RAM
--
Salutations
Med Bouchenafa
TETRASET
75015 Paris
"Patrick" <nospam@nospam.fr> wrote in message
news:05cd01c37852$bb9a5150$a101280a@phx.gbl...
Bonjour
J'ai de sérieux problèmes pour localiser les mauvaises
performances de requêtes.
J'ai lancé différentes traces pour tester, et à chaque
fois j'ai les mêmes résultats:
Par exemple sur 200 exécutions d'une même requête, 190
mettent moins d'1 seconde pour s'exécuter, et 10 mettent
de 2 à 5s. Il peut s'agir de requêtes comme de procs
stocks, les paramètres quand il y en a sont rigoureusement
identiques...
J'ai donc naturellement pensé à des pb de locks, mais les
traces que j'ai exécuté dans cette optique m'ont dit que
tout allait bien.
J'ai essayé de voir ce qui pouvait se passer en même temps
sur la base, rien.
Le serveur est 100% dédié à la base de données.
Je commence à sécher, d'autant que c'est systématique sur
toutes les requêtes: sur 10min de trace, je suis sûr
d'avoir 300 requêtes dans ce cas...
Si quelqu'un a des infos ou des pistes pour chercher, je
suis preneur!! ^_^;
Dans le cas de procédure stockée, essaye de regarder si cela ne coïncide pas avec une recompilation de la procédure stockée. Il est possible qu'au bout d'un certain temps d'inutilisation, la procédure est sortie du cache. A son rappel, elle est recompilée à nouveau, ce qui forcément prend plus de temps. Pour cela, essaye de tracer l'événement "sp-recompil" (je crois de tête) Auquel cas, il te faudra un peu plus de RAM
-- Salutations Med Bouchenafa TETRASET 75015 Paris
"Patrick" wrote in message news:05cd01c37852$bb9a5150$ Bonjour
J'ai de sérieux problèmes pour localiser les mauvaises performances de requêtes. J'ai lancé différentes traces pour tester, et à chaque fois j'ai les mêmes résultats: Par exemple sur 200 exécutions d'une même requête, 190 mettent moins d'1 seconde pour s'exécuter, et 10 mettent de 2 à 5s. Il peut s'agir de requêtes comme de procs stocks, les paramètres quand il y en a sont rigoureusement identiques... J'ai donc naturellement pensé à des pb de locks, mais les traces que j'ai exécuté dans cette optique m'ont dit que tout allait bien. J'ai essayé de voir ce qui pouvait se passer en même temps sur la base, rien. Le serveur est 100% dédié à la base de données. Je commence à sécher, d'autant que c'est systématique sur toutes les requêtes: sur 10min de trace, je suis sûr d'avoir 300 requêtes dans ce cas... Si quelqu'un a des infos ou des pistes pour chercher, je suis preneur!! ^_^;
Patrick
Patrick
Merci pour ta réponse Med, et l'info pourra toujours me servir plus tard ;) Mais malheureusement ce n'est pas le cas. Le problème se présente aussi bien avec des proc qu'avec des requetes en dur. J'ai quand même voulu vérifier ton histoire (pour info, l'évènement est bien "SP:Recompile"), mais il n'y a aucune recompilation. En même temps, vu la fréquence d'utilisation de la base (vente en ligne sur internet), je pense pas qu'une procédure puisse avoir le temps de sortir du cache... :)
-----Message d'origine----- Dans le cas de procédure stockée, essaye de regarder si
cela ne coïncide pas
avec une recompilation de la procédure stockée. Il est possible qu'au bout d'un certain temps
d'inutilisation, la procédure
est sortie du cache. A son rappel, elle est recompilée à nouveau, ce qui
forcément prend plus de
temps. Pour cela, essaye de tracer l'événement "sp-recompil" (je
crois de tête)
Auquel cas, il te faudra un peu plus de RAM
-- Salutations Med Bouchenafa TETRASET 75015 Paris
"Patrick" wrote in message news:05cd01c37852$bb9a5150$ Bonjour
J'ai de sérieux problèmes pour localiser les mauvaises performances de requêtes. J'ai lancé différentes traces pour tester, et à chaque fois j'ai les mêmes résultats: Par exemple sur 200 exécutions d'une même requête, 190 mettent moins d'1 seconde pour s'exécuter, et 10 mettent de 2 à 5s. Il peut s'agir de requêtes comme de procs stocks, les paramètres quand il y en a sont rigoureusement identiques... J'ai donc naturellement pensé à des pb de locks, mais les traces que j'ai exécuté dans cette optique m'ont dit que tout allait bien. J'ai essayé de voir ce qui pouvait se passer en même temps sur la base, rien. Le serveur est 100% dédié à la base de données. Je commence à sécher, d'autant que c'est systématique sur toutes les requêtes: sur 10min de trace, je suis sûr d'avoir 300 requêtes dans ce cas... Si quelqu'un a des infos ou des pistes pour chercher, je suis preneur!! ^_^;
Patrick
.
Merci pour ta réponse Med, et l'info pourra toujours me
servir plus tard ;)
Mais malheureusement ce n'est pas le cas.
Le problème se présente aussi bien avec des proc qu'avec
des requetes en dur.
J'ai quand même voulu vérifier ton histoire (pour info,
l'évènement est bien "SP:Recompile"), mais il n'y a aucune
recompilation. En même temps, vu la fréquence
d'utilisation de la base (vente en ligne sur internet), je
pense pas qu'une procédure puisse avoir le temps de sortir
du cache... :)
-----Message d'origine-----
Dans le cas de procédure stockée, essaye de regarder si
cela ne coïncide pas
avec une recompilation de la procédure stockée.
Il est possible qu'au bout d'un certain temps
d'inutilisation, la procédure
est sortie du cache.
A son rappel, elle est recompilée à nouveau, ce qui
forcément prend plus de
temps.
Pour cela, essaye de tracer l'événement "sp-recompil" (je
crois de tête)
Auquel cas, il te faudra un peu plus de RAM
--
Salutations
Med Bouchenafa
TETRASET
75015 Paris
"Patrick" <nospam@nospam.fr> wrote in message
news:05cd01c37852$bb9a5150$a101280a@phx.gbl...
Bonjour
J'ai de sérieux problèmes pour localiser les mauvaises
performances de requêtes.
J'ai lancé différentes traces pour tester, et à chaque
fois j'ai les mêmes résultats:
Par exemple sur 200 exécutions d'une même requête, 190
mettent moins d'1 seconde pour s'exécuter, et 10 mettent
de 2 à 5s. Il peut s'agir de requêtes comme de procs
stocks, les paramètres quand il y en a sont rigoureusement
identiques...
J'ai donc naturellement pensé à des pb de locks, mais les
traces que j'ai exécuté dans cette optique m'ont dit que
tout allait bien.
J'ai essayé de voir ce qui pouvait se passer en même temps
sur la base, rien.
Le serveur est 100% dédié à la base de données.
Je commence à sécher, d'autant que c'est systématique sur
toutes les requêtes: sur 10min de trace, je suis sûr
d'avoir 300 requêtes dans ce cas...
Si quelqu'un a des infos ou des pistes pour chercher, je
suis preneur!! ^_^;
Merci pour ta réponse Med, et l'info pourra toujours me servir plus tard ;) Mais malheureusement ce n'est pas le cas. Le problème se présente aussi bien avec des proc qu'avec des requetes en dur. J'ai quand même voulu vérifier ton histoire (pour info, l'évènement est bien "SP:Recompile"), mais il n'y a aucune recompilation. En même temps, vu la fréquence d'utilisation de la base (vente en ligne sur internet), je pense pas qu'une procédure puisse avoir le temps de sortir du cache... :)
-----Message d'origine----- Dans le cas de procédure stockée, essaye de regarder si
cela ne coïncide pas
avec une recompilation de la procédure stockée. Il est possible qu'au bout d'un certain temps
d'inutilisation, la procédure
est sortie du cache. A son rappel, elle est recompilée à nouveau, ce qui
forcément prend plus de
temps. Pour cela, essaye de tracer l'événement "sp-recompil" (je
crois de tête)
Auquel cas, il te faudra un peu plus de RAM
-- Salutations Med Bouchenafa TETRASET 75015 Paris
"Patrick" wrote in message news:05cd01c37852$bb9a5150$ Bonjour
J'ai de sérieux problèmes pour localiser les mauvaises performances de requêtes. J'ai lancé différentes traces pour tester, et à chaque fois j'ai les mêmes résultats: Par exemple sur 200 exécutions d'une même requête, 190 mettent moins d'1 seconde pour s'exécuter, et 10 mettent de 2 à 5s. Il peut s'agir de requêtes comme de procs stocks, les paramètres quand il y en a sont rigoureusement identiques... J'ai donc naturellement pensé à des pb de locks, mais les traces que j'ai exécuté dans cette optique m'ont dit que tout allait bien. J'ai essayé de voir ce qui pouvait se passer en même temps sur la base, rien. Le serveur est 100% dédié à la base de données. Je commence à sécher, d'autant que c'est systématique sur toutes les requêtes: sur 10min de trace, je suis sûr d'avoir 300 requêtes dans ce cas... Si quelqu'un a des infos ou des pistes pour chercher, je suis preneur!! ^_^;
Patrick
.
Med Bouchenafa[MVP]
Dans SQL/Server 2000, les requêtes, si elles sont lancées avec les mêmes paramètres, se comportent comme des procédures. Elles sont aussi mises dans le cache et réutilisées. C'est une nouveauté de SQL/Server 2000 Ce que je te propose de faire est le test suivant Tu vide le cache des procédures et des données par DBCC DBCC FREEPROCCACHE DBCC DROPCLEANBUFFERS Tu lances ensuite une procédure stockée et tu vois combien elle met de temps Tu la relances juste après et tu compares. Si les temps correspondent à ceux que tu as donné tout à l'heure, c'est forcement un problème de recompilation
Mais bon comme tu dis que tu n'as d'événement "SP:Recompile" dans les traces, c'est peut-être un problème de ressources. Et c'est forcément beaucoup plus complexe à trouver Une première chose à vérifier serait la surcharge IO des disques.
Il faut espérer que Lionel soit de passage et lise ton message. Il a peut-être d'autres idées.
-- Salutations Med Bouchenafa TETRASET 75015 Paris
"Patrick" wrote in message news:09d501c3786d$94750050$ Merci pour ta réponse Med, et l'info pourra toujours me servir plus tard ;) Mais malheureusement ce n'est pas le cas. Le problème se présente aussi bien avec des proc qu'avec des requetes en dur. J'ai quand même voulu vérifier ton histoire (pour info, l'évènement est bien "SP:Recompile"), mais il n'y a aucune recompilation. En même temps, vu la fréquence d'utilisation de la base (vente en ligne sur internet), je pense pas qu'une procédure puisse avoir le temps de sortir du cache... :)
-----Message d'origine----- Dans le cas de procédure stockée, essaye de regarder si
cela ne coïncide pas
avec une recompilation de la procédure stockée. Il est possible qu'au bout d'un certain temps
d'inutilisation, la procédure
est sortie du cache. A son rappel, elle est recompilée à nouveau, ce qui
forcément prend plus de
temps. Pour cela, essaye de tracer l'événement "sp-recompil" (je
crois de tête)
Auquel cas, il te faudra un peu plus de RAM
-- Salutations Med Bouchenafa TETRASET 75015 Paris
"Patrick" wrote in message news:05cd01c37852$bb9a5150$ Bonjour
J'ai de sérieux problèmes pour localiser les mauvaises performances de requêtes. J'ai lancé différentes traces pour tester, et à chaque fois j'ai les mêmes résultats: Par exemple sur 200 exécutions d'une même requête, 190 mettent moins d'1 seconde pour s'exécuter, et 10 mettent de 2 à 5s. Il peut s'agir de requêtes comme de procs stocks, les paramètres quand il y en a sont rigoureusement identiques... J'ai donc naturellement pensé à des pb de locks, mais les traces que j'ai exécuté dans cette optique m'ont dit que tout allait bien. J'ai essayé de voir ce qui pouvait se passer en même temps sur la base, rien. Le serveur est 100% dédié à la base de données. Je commence à sécher, d'autant que c'est systématique sur toutes les requêtes: sur 10min de trace, je suis sûr d'avoir 300 requêtes dans ce cas... Si quelqu'un a des infos ou des pistes pour chercher, je suis preneur!! ^_^;
Patrick
.
Dans SQL/Server 2000, les requêtes, si elles sont lancées avec les mêmes
paramètres, se comportent comme des procédures.
Elles sont aussi mises dans le cache et réutilisées.
C'est une nouveauté de SQL/Server 2000
Ce que je te propose de faire est le test suivant
Tu vide le cache des procédures et des données par
DBCC DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS
Tu lances ensuite une procédure stockée et tu vois combien elle met de temps
Tu la relances juste après et tu compares.
Si les temps correspondent à ceux que tu as donné tout à l'heure, c'est
forcement un problème de recompilation
Mais bon comme tu dis que tu n'as d'événement "SP:Recompile" dans les
traces, c'est peut-être un problème de ressources.
Et c'est forcément beaucoup plus complexe à trouver
Une première chose à vérifier serait la surcharge IO des disques.
Il faut espérer que Lionel soit de passage et lise ton message.
Il a peut-être d'autres idées.
--
Salutations
Med Bouchenafa
TETRASET
75015 Paris
"Patrick" <nospam@nospam.fr> wrote in message
news:09d501c3786d$94750050$a401280a@phx.gbl...
Merci pour ta réponse Med, et l'info pourra toujours me
servir plus tard ;)
Mais malheureusement ce n'est pas le cas.
Le problème se présente aussi bien avec des proc qu'avec
des requetes en dur.
J'ai quand même voulu vérifier ton histoire (pour info,
l'évènement est bien "SP:Recompile"), mais il n'y a aucune
recompilation. En même temps, vu la fréquence
d'utilisation de la base (vente en ligne sur internet), je
pense pas qu'une procédure puisse avoir le temps de sortir
du cache... :)
-----Message d'origine-----
Dans le cas de procédure stockée, essaye de regarder si
cela ne coïncide pas
avec une recompilation de la procédure stockée.
Il est possible qu'au bout d'un certain temps
d'inutilisation, la procédure
est sortie du cache.
A son rappel, elle est recompilée à nouveau, ce qui
forcément prend plus de
temps.
Pour cela, essaye de tracer l'événement "sp-recompil" (je
crois de tête)
Auquel cas, il te faudra un peu plus de RAM
--
Salutations
Med Bouchenafa
TETRASET
75015 Paris
"Patrick" <nospam@nospam.fr> wrote in message
news:05cd01c37852$bb9a5150$a101280a@phx.gbl...
Bonjour
J'ai de sérieux problèmes pour localiser les mauvaises
performances de requêtes.
J'ai lancé différentes traces pour tester, et à chaque
fois j'ai les mêmes résultats:
Par exemple sur 200 exécutions d'une même requête, 190
mettent moins d'1 seconde pour s'exécuter, et 10 mettent
de 2 à 5s. Il peut s'agir de requêtes comme de procs
stocks, les paramètres quand il y en a sont rigoureusement
identiques...
J'ai donc naturellement pensé à des pb de locks, mais les
traces que j'ai exécuté dans cette optique m'ont dit que
tout allait bien.
J'ai essayé de voir ce qui pouvait se passer en même temps
sur la base, rien.
Le serveur est 100% dédié à la base de données.
Je commence à sécher, d'autant que c'est systématique sur
toutes les requêtes: sur 10min de trace, je suis sûr
d'avoir 300 requêtes dans ce cas...
Si quelqu'un a des infos ou des pistes pour chercher, je
suis preneur!! ^_^;
Dans SQL/Server 2000, les requêtes, si elles sont lancées avec les mêmes paramètres, se comportent comme des procédures. Elles sont aussi mises dans le cache et réutilisées. C'est une nouveauté de SQL/Server 2000 Ce que je te propose de faire est le test suivant Tu vide le cache des procédures et des données par DBCC DBCC FREEPROCCACHE DBCC DROPCLEANBUFFERS Tu lances ensuite une procédure stockée et tu vois combien elle met de temps Tu la relances juste après et tu compares. Si les temps correspondent à ceux que tu as donné tout à l'heure, c'est forcement un problème de recompilation
Mais bon comme tu dis que tu n'as d'événement "SP:Recompile" dans les traces, c'est peut-être un problème de ressources. Et c'est forcément beaucoup plus complexe à trouver Une première chose à vérifier serait la surcharge IO des disques.
Il faut espérer que Lionel soit de passage et lise ton message. Il a peut-être d'autres idées.
-- Salutations Med Bouchenafa TETRASET 75015 Paris
"Patrick" wrote in message news:09d501c3786d$94750050$ Merci pour ta réponse Med, et l'info pourra toujours me servir plus tard ;) Mais malheureusement ce n'est pas le cas. Le problème se présente aussi bien avec des proc qu'avec des requetes en dur. J'ai quand même voulu vérifier ton histoire (pour info, l'évènement est bien "SP:Recompile"), mais il n'y a aucune recompilation. En même temps, vu la fréquence d'utilisation de la base (vente en ligne sur internet), je pense pas qu'une procédure puisse avoir le temps de sortir du cache... :)
-----Message d'origine----- Dans le cas de procédure stockée, essaye de regarder si
cela ne coïncide pas
avec une recompilation de la procédure stockée. Il est possible qu'au bout d'un certain temps
d'inutilisation, la procédure
est sortie du cache. A son rappel, elle est recompilée à nouveau, ce qui
forcément prend plus de
temps. Pour cela, essaye de tracer l'événement "sp-recompil" (je
crois de tête)
Auquel cas, il te faudra un peu plus de RAM
-- Salutations Med Bouchenafa TETRASET 75015 Paris
"Patrick" wrote in message news:05cd01c37852$bb9a5150$ Bonjour
J'ai de sérieux problèmes pour localiser les mauvaises performances de requêtes. J'ai lancé différentes traces pour tester, et à chaque fois j'ai les mêmes résultats: Par exemple sur 200 exécutions d'une même requête, 190 mettent moins d'1 seconde pour s'exécuter, et 10 mettent de 2 à 5s. Il peut s'agir de requêtes comme de procs stocks, les paramètres quand il y en a sont rigoureusement identiques... J'ai donc naturellement pensé à des pb de locks, mais les traces que j'ai exécuté dans cette optique m'ont dit que tout allait bien. J'ai essayé de voir ce qui pouvait se passer en même temps sur la base, rien. Le serveur est 100% dédié à la base de données. Je commence à sécher, d'autant que c'est systématique sur toutes les requêtes: sur 10min de trace, je suis sûr d'avoir 300 requêtes dans ce cas... Si quelqu'un a des infos ou des pistes pour chercher, je suis preneur!! ^_^;
