Discussion :

[joujousagem2006]

Bonjour
j'ai lancer un plan de maintenance qui consiste a faire un update des statistique avec option fulscan cette action a permet d’améliorer le temps de réponse d’exécution des Différents procédure

stocké

hier on eu une coupure de courant sur Tout usine j'était surpris que j'ai eu de lenteur ,j'ai lancer une autre fois l'action update statics le problème a était résolu

est ce que je doit a chaque fois qu'il y a de redémarrage faire la même action et pourquoi sql server ne stocke pas ces information qui permet d’améliorer le temps d’exécution des plan de requête

cordialement

[bvesan]

Bonjour,
Les statistiques sur les colonnes sont des objets stockés en base. Ils survivent donc (fort heureusement) à un redémarrage d'une instance.

Les lenteurs et la méthode de résolution que vous avez appliqué peuvent a priori s'expliquer par le mécanisme de cache de pages de données.
Lorsqu'une page de données est lue depuis le disque (on parle de lecture physique), elle est dupliquée en mémoire nommée Buffer Cache. Les lectures suivantes de cette même page sont donc bien plus rapides puisqu'elles sont effectuées depuis la mémoire au lieu du disque (on parle de lecture logique).
Bien entendu, redémarrer une instance a pour conséquence une purge totale des différentes zones mémoires allouées à l'instance.

Le fait de lancer une mise à jour des statistiques en mode FullScan sur les tables et indexes de la base va lire toutes les pages de toutes les tables et indexes et les dupliquer en mémoire (si la zone Buffer Cache est suffisamment grande). Toutes les lectures de pages de données/indexes effectuées après cette mise à jour de statistiques seront donc des lectures en mémoire, bien plus rapides. Les requêtes sont donc plus rapides.

(Cette même mise à jour des statistiques aura aussi eu pour effet de supprimer les plans d'exécutions en mémoire, ce qui peut résoudre un problème lié à ce qu'on appelle le "Bind Variable Peeking", mais ce problème est moins fréquent)


Dans l'absolu, la première exécution d'une requête sera souvent bien plus lente que les autres exécutions, principalement parce que les pages brassées ne sont pas encore en mémoire et doivent être lues depuis les disques. L'action de mise à jour des statistiques a simplement permis d'éviter ce phénomène, mais le temps de réponse des requêtes serait de toutes façon revenu à des valeurs convenables avec le temps.

[SQLpro]

L'arrêt du serveur vide le cache (la ram) et donc au redémarrage, les requêtes consomment du disque pour monter en RAM les données.
Les statistiques d'optimisation ne sont pas véritablement concernées par cela (pas plus que le reste en tout cas). En revanche vous perdez bel et bien toutes les statistiques d'exécution (et donc de diagnostic) accessibles par les DMV....

N'oubliez jamais qu'un serveur SQL fonctionne exclusivement en RAM, le disque n'étant là que pour assurer la couche de persistance... La ram étant par nature volatile !

A +