Discussion :

[maxced01]

Bonjour
je viens d'arriver sur mon nouveau poste et en effectuant un petit tour des bases et instances, je m'aperçois que l'ensemble des bases qui sont utilisées on les options :
- création automatique des stats : True
- mise a jour automatiques des stats : True

vu que je ne trouve pas de plan de maintenance ou de jobs d'update de statistiques.
Puis je faire confiance au moteur SQL quant a la bonne gestion des stats ou bien dois je mettre en place un job de maintenance ?

Merci pour vos retour et prenez soin de vous.

[Boubou2020]

personnellement je Désactive l'auto update stats et je fait un calcul en mode FULLSCAN

[SQLpro]

Non, ne pas désactiver l'auto update stats car elle est utilisé si les données ont notablement changé au cous de l'exploitation ordinaire des données. Ce serait dommage qu'une requête parte subitement en live parce que les stats sont obsolète et que l'auto update est désactivé....
En version Entreprise mettez le en asynchrone (il faut activer les deux)
Si vous avez des tables partitionnées, activez les stats incrémentales.

Mais dans tous les cas une maintenance aux heures creuses en reconstruction en mode FULLSCAN avec un indice de sélection progressif est une bonne chose !

A +

[maxced01]

merci pour ces retours.

[maxced01]

.... En version Entreprise mettez le en asynchrone (il faut activer les deux) ...

Mais dans tous les cas une maintenance aux heures creuses en reconstruction en mode FULLSCAN avec un indice de sélection progressif est une bonne chose !

A +

C'est a dire ?
en P.J. les option d'une de mes bases.

[Boubou2020]

Non, ne pas désactiver l'auto update stats car elle est utilisé si les données ont notablement changé au cous de l'exploitation ordinaire des données. Ce serait dommage qu'une requête parte subitement en live parce que les stats sont obsolète et que l'auto update est désactivé....
En version Entreprise mettez le en asynchrone (il faut activer les deux)
Si vous avez des tables partitionnées, activez les stats incrémentales.

Mais dans tous les cas une maintenance aux heures creuses en reconstruction en mode FULLSCAN avec un indice de sélection progressif est une bonne chose !

A +

ce ci est aussi pour les grosses tables ?

[mikedavem]

Pour les grosses tables il y a une variété d'options à disposition (en fonction de la version) pour tenter le FULLSCAN et minimiser le temps de l'opération mais en général celles-ci requierent soit plus de ressources pour aller plus vite ou un changement structurel au niveau de la table. Au travers de mes différentes expériences sur le sujet j'ai pu utiliser les techniques suivantes:

- Découpage de la maintenance des statistiques sur plusieurs jours

- Parallélisation de la mise à jour des statistiques avec le trace flag 7471 - Nécessite d'avoir des ressources qui tiennent la route (CPU, IO et mémoire)

- Etude de la distribution des données pour les statistiques et choix de la méthode FULLSCAN ou SAMPLE.
Si la méthode SAMPLE peut être judicieuse à utiliser, il peut arriver un moment où en fonction du taux d'échantillonnage utilisé que la méthode FULLSCAN soit plus rapide. FULLSCAN est exécuté en parallèle alors que pour SAMPLE ce n'est pas le cas

- Partitionement + statistiques incrémentales
Bien garder en tête que ce mécanisme est uniquement dédié à réduire la fenêtre de maintenance. L'optimiseur n'utilise pas les statistiques au niveau partition mais uniquement la statistique au niveau globale

++

[SQLpro]

Pour le découpage de la maintenance sur plusieurs jours j'utilise la technique suivante :
1) analyse des stats qui nécessitent un recalcul
2) tirage au sort d'une stat pour la recalculer avec un GUID
3) vérification du temps restant:

• si dépassé arrêter le process
• sinon boucler en 2

A +