Discussion :

[joujousagem2006]

Bonjour

j'ai lancer un mis a jour de statistique de façon manuel sur un table volumineux

mais cette action ne se lance pas

aprés que je lance la requête

Code :

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

DBCC SHOW_STATISTICS ( 'mvtFabr', PK__mvtFabr__49666609)

le table c'est mvtFaber l'index c'est PK__mvtFabr__49666609 j'étatit surpris que cette statique n'est pas mis a jour (voir la date dans imprime écran)
pourquoi ??? d'ou viens le blocage ???

merci

[mikedavem]

Hello,

Quelle commande lances-tu ? Quand ? Dans une période de maintenance ou dans la journée avec une activité sur ta base ? Un message d'erreur particulier ou une commande qui prend du temps ?

++

[joujousagem2006]

Bonjour

je le fait de façon graphique je couche l'option "Mettre a jour les statistique pour ces colonnes"

il est lancé dans un journée avec une activité sur ma base

aucun message d'erreur qui s’apparaît

[mikedavem]

Et si tu lances la commande suivante dans une fenêtre de requête :

Code :

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

1
2
3
 
UPDATE STATISTICS dbo.mvtFabr PK__mvtFabr__49666609
GO

++

[darkelend]

en passant par l'outil graphique dans SSMS, s'il y a un message d'erreur on ne le voit pas toujours. Il vaut mieux passer par la commande T-SQL, au moins tu sauras si ca plante ou non

[joujousagem2006]

en passant par l'outil graphique dans SSMS, s'il y a un message d'erreur on ne le voit pas toujours. Il vaut mieux passer par la commande T-SQL, au moins tu sauras si ca plante ou non

Bonjour

méme avec le transact sql Toujours méme Chose

mais il y a point remarqué c'est que j'ai pas d'espace sur la base temporaire tempdb
en exécutant la comande

Code :

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

exec sp_spaceused

sur la base tempdb j'aurai cette résultat (voir imprime écran)

[mikedavem]

méme avec le transact sql Toujours méme Chose

C'est à dire ? La requête tourne et ne se termine pas ?

Est-ce que tu as quelque chose quand tu lances la commande :

Code :

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

1
2
3
4
5
6
7
SELECT 
 session_id,
 command,
 wait_type,
 wait_time 
FROM sys.dm_exec_requests
WHERE session_id = <session_id de la session ou tu lances la commande>

++

[SQLpro]

Pouvez vous nous donner la composition de l'index et de la table, ainsi que le nombre de lignes de la table.
A +

[joujousagem2006]

Bonjour aprés avoir réussi a faire la mis a jour sur la table MVt faber les utilisateur on mon réclamer la présence d'un grand lenteur
tout les procédure stocké relier avec la table MVt faber qui a subit une mis a jour des statistiques prend beaucoup de temps
mon colégue ma conseillé d’exécuter la Command exec sp_recompile "dbo.mvtfabr"
j'ai penser a redémarer le serveur
qui peux m'aider svp j'ai un grand pression pour résoudre le probléme

merci

[SQLpro]

1) vous avez cloturé cette demande c'est pourquoi on ne vous répond pas....

2) si vous redémarrez le serveur, tout deviendra lent. Par principe on ne redémarre pas un serveur SQL. jamais !

3) c'est normal que ce soit lent au début, pour recalculez les stats, le système à du placer la table en mémoire au détriment d'autres données, et donc poussé au dehors certaines tables fortement utilisées

4) tout va revenir dans l'ordre au bout de quelques temps, sans rien avoir à faire.

5) il est probable que vous n'avez pas assez de RAM. Vérifieiez les compteurs "page life expectansy" et "cache hit ratio" du compteur SQL Server : Memory manager dans le perfmon. La premier doit être au dessus de 98% et le second au minimum de 300 (par précaution 600).

A +

[joujousagem2006]

1) vous avez cloturé cette demande c'est pourquoi on ne vous répond pas....

Désoler mais vu que j'ai eu des réclamation de latence sur la production ,j'ai concentrée a voir la cause mais dans tout les cas merci pour vos support

2) si vous redémarrez le serveur, tout deviendra lent. Par principe on ne redémarre pas un serveur SQL. jamais !
suite au pression et suite que j'ai pas de piste j'ai penser a redémarrer le serveur

3) c'est normal que ce soit lent au début, pour recalculez les stats, le système à du placer la table en mémoire au détriment d'autres données, et donc poussé au dehors certaines tables fortement utilisées
ok par comptre ce probléme a été résolu suite au ajout d'option "with fullscan" donc j'ai executer la command

Code :

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

update statistics dbo.Mvt_faber with fullscan

4) tout va revenir dans l'ordre au bout de quelques temps, sans rien avoir à faire.

5) il est probable que vous n'avez pas assez de RAM. Vérifieiez les compteurs "page life expectansy" et "cache hit ratio" du compteur SQL Server : Memory manager dans le perfmon. La premier doit être au dessus de 98% et le second au minimum de 300 (par précaution 600).
ok je faire un test et voir la résultat fournit
A +

ok par compte j'ai autre question quel est la différence d’exécuter la command "update statistics mvt_faber" soit avec option fullscan ou sample

[SQLpro]

FullScan lit toute la table. Sample tire au sort quelques pages pour échantillon. Néanmoins pour que les plans soient impeccable, il faut de temps à autre faire des fullscan.

A +

[joujousagem2006]

FullScan lit toute la table. Sample tire au sort quelques pages pour échantillon. Néanmoins pour que les plans soient impeccable, il faut de temps à autre faire des fullscan.

A +

Bonjour
j'ai une deuxième question SVP lorsque j'ai lancer la commande

Code :

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

UPDATE statistics dbo.Mvt_faber WITH fullscan

avec l'option ful scan cette command a entrainer une dégradation de performance sur le serveur sql server et suite au pression faite par la production (nos client) j'était obliger d’arrêter ce plan
après cette arrêt j'ai vérifier mes statistique j'ai trouver qu'il y a des statistiques qui ont subit la mis ajour et d'autre non
on a planifier un arrêt avec nos client pour faire nos travaux de maintenance ma question comment maintenant je doit procéder est ce que je doit lancer une autre foit la comand sur tout la table ou je doit le lancer que sur les statistic qui n'on pas subit la mis a jour bien sur s'il existe aussi est ce je doit laisser l'option fullscan ou je doit le modifier par option sample
merci pour vos aide

[SQLpro]

Votre question est trop vague... Quelle est l'édition de SQL Server , Quel est la volumétrie de la base et des tables ?


A +

[joujousagem2006]

Votre question est trop vague... Quelle est l'édition de SQL Server , Quel est la volumétrie de la base et des tables ?

version sql server 2005 64bit vesion Entreprise

Taille de base 550 GO

Taille de table MVT_faber 320GO Data + 70GO Index

A +

[SQLpro]

Avec 2008 vous auriez pu utiliser la compression des données... Domage.

Quelle est la RAM du serveur ?
Quelle est la composition de cette table (colonnes, contraintes, index...) ?

A +

[joujousagem2006]

1) vous avez cloturé cette demande c'est pourquoi on ne vous répond pas....

2) si vous redémarrez le serveur, tout deviendra lent. Par principe on ne redémarre pas un serveur SQL. jamais !

3) c'est normal que ce soit lent au début, pour recalculez les stats, le système à du placer la table en mémoire au détriment d'autres données, et donc poussé au dehors certaines tables fortement utilisées

4) tout va revenir dans l'ordre au bout de quelques temps, sans rien avoir à faire.

5) il est probable que vous n'avez pas assez de RAM. Vérifieiez les compteurs "page life expectansy" et "cache hit ratio" du compteur SQL Server : Memory manager dans le perfmon. La premier doit être au dessus de 98% et le second au minimum de 300 (par précaution 600).

A +

bonjour

je reviens vers vous pour vous poser un question au moment ou il y a soit un redémarrage de MSSQL server ou même Un Command de type DBCC Freeproccache c'est a dire ou il exit un événement de Vidage de cache mémoire mes serveur de production ne font pas la recalcul automatique des stats le lenteur reste toujours même après le passage de deux heures
il disparaît après un update des statistiques en fullscan
pourquoi ce phénomène ???

[mikedavem]

Après un redémarrage du serveur ou un vidage du cache des procédures, il n'y a plus aucun plan d'exécution et de pages de données stockés dans ton instance SQL Server. Cela ne déclenche pas de mises à jour de statistiques qui sont déclenchés par des modifications de données.

Les lenteurs peuvent au départ s'expliquer avec le temps de remplir le cache des données et de compiler les plans d'exécutions. Tu verras de nombreux commentaires sur le forum qui stipulent qu'un redémarrage de serveur SQL peut avoir des conséquences sur les performances ...

Maintenant tu parles de lenteur mais est-ce que celles-ci sont ciblées à un ensemble de requêtes ou générales quand tu redémarres ton instance SQL Server ? J'ai vu plus haut dans le post que la mise à jour en FULL SCAN ne réglait pas forcément ton problème bien au contraire tu confirmes ?

Edit : je pense que ce thread est en double avec celui-ci . Autant se concentrer sur un seul thread pour être efficace ..

++

[joujousagem2006]

Après un redémarrage du serveur ou un vidage du cache des procédures, il n'y a plus aucun plan d'exécution et de pages de données stockés dans ton instance SQL Server. Cela ne déclenche pas de mises à jour de statistiques qui sont déclenchés par des modifications de données.

Les lenteurs peuvent au départ s'expliquer avec le temps de remplir le cache des données et de compiler les plans d'exécutions. Tu verras de nombreux commentaires sur le forum qui stipulent qu'un redémarrage de serveur SQL peut avoir des conséquences sur les performances ...

Maintenant tu parles de lenteur mais est-ce que celles-ci sont ciblées à un ensemble de requêtes ou générales quand tu redémarres ton instance SQL Server ? J'ai vu plus haut dans le post que la mise à jour en FULL SCAN ne réglait pas forcément ton problème bien au contraire tu confirmes ?

Edit : je pense que ce thread est en double avec celui-ci . Autant se concentrer sur un seul thread pour être efficace ..

++

je suis d'accord avec vous que après chaque redémarrage de l'instance il aura une dégradation de performance afin que le moteur faire leur compilation et prend son temps pour ecriture de cache du procédure mais dans mon cas le serveur ne fait CA de façon automatique j'aurai toujours un temps élevé d’exécution des procédures avec un I/O élevé mais après une tache d'update des statistics sur la table le plus volumineux et le plus utilisé en terme de transaction et surtout au moment ou l'opération attaque l'index non cluster "PK__mvtFabr__49666609" tout reviens a un état normale
j'ai lue cette article http://rudi.developpez.com/sqlserver...misation/#LI-A et surtout cette paragraphe

La lecture sur disque est l'opération la plus coûteuse d'une requête, il est donc important de limiter le nombre de pages lues, en s'assurant d'avoir assez de RAM pour permettre à SQL Server de stocker les pages les plus fréquemment accédées dans son cache, et plus important, en limitant le nombre de pages lues par la création d'index ou l'optimisation du code SQL.

je pense que toujours mon moteur est entrain de lire le table a partir de disque et qu'il n'est pas capable de le mettre sur la cache je te confirme que j'ai du pression sur la mémoire
y a t il un moyer de forcer SQL a monter ce table en éliminant d'autre page surtout qu'il s'agit de la table le plus important ??
je ne sais pas si mon chemin d’analyse est correcte surtout que j'ai pas d'autre chemin pour comprendre ce comportement

[mikedavem]

je suis d'accord avec vous que après chaque redémarrage de l'instance il aura une dégradation de performance afin que le moteur faire leur compilation et prend son temps pour ecriture de cache du procédure mais dans mon cas le serveur ne fait CA de façon automatique j'aurai toujours un temps élevé d’exécution des procédures avec un I/O élevé mais après une tache d'update des statistics sur la table le plus volumineux et le plus utilisé en terme de transaction et surtout au moment ou l'opération attaque l'index non cluster "PK__mvtFabr__49666609" tout reviens a un état normale

Le fait de mettre à jour les statistiques invalident les plans d'exécution en cache pour les requêtes concernées. As-tu regardé les plans d'exécutions de ces requêtes avant et après la mise à jour des statistiques pour tes requêtes ? Il se peut que tu sois face à un problème de qualité de plan avec du parameter sniffing ou quelque chose du genre.

je pense que toujours mon moteur est entrain de lire le table a partir de disque et qu'il n'est pas capable de le mettre sur la cache je te confirme que j'ai du pression sur la mémoire
y a t il un moyer de forcer SQL a monter ce table en éliminant d'autre page surtout qu'il s'agit de la table le plus important ??
je ne sais pas si mon chemin d’analyse est correcte surtout que j'ai pas d'autre chemin pour comprendre ce comportement

Je pense que tu fais fausse route ici vu de loin. Je pense que si après la mise à jour de statistiques tout rentre dans l'ordre je pencherais plus vers un problème de plan d'exécution à mon humble avis.


++