Index - Réorganiser + Reconstruire

Bonjour,

je souhaite confirmer avec vous un fonctionnement de SQL Server (2012) lors des taches de maintenance.
Est ce qu'il est utile de faire à la suite une tache de Réorganisation des indexs suivi tout de suite après d'une tache de Reconstruction des indexs comme présenté sur la capture d’écran?
Je connais la différence entre la réorg et la reconstruction mais un "consultant" m'a dit que l'on pouvait laisser les deux taches s'enchainer car SQL n'allait faire la reorg des indexs que pour ceux qui en avaient besoin puis SQL ferait la reconstruction pour les indexs trop fragmentés...
Pour moi ce n'est pas comme ça que ça marche mais du coup j'ai eu un doute...
Donc selon vous, ce genre d'action de maintenance est-il logique ou pas?

Pièce jointe 596119

Je vous confirme que c'est absurde ! On fait deux fois le travail. De plus il faut appliquer des seuils :
ne pas traiter les petits objets (moins de 64 pages)

• réorganiser entre 10 et 30 % de fragmentation
• reconstruire si plus de 30%

Et enfin, encore plus important : recalculer les statistiques, si possible en mode FULLSCAN pour tous les objets non traités par la reconstruction...

Autrement dit il faut scripter tout cela.

A +

Bonjour,

Je suis d'accord avec la remarque de FB.
Sauf sur 1 point : appliquer aveuglément les consignes de seuil (préconisation M$ si je ne m'abuse)

A mon sens il faut aller plus loin dans la réflexion/étude pour inclure :

- la durée des fenêtres de maintenance

Ce point n'est pas géré par M$ (contrairement à Oracle).
Il est classique que le WE on ait plus de temps pour "faire du ménage"
Peut-être qu'on peut en profiter pour abaisser le seuil de reconstruction voire de ne pas en avoir du tout (à valider)

- quand est faite la sauvegarde ? qu'attend t'on à trouver en cas de restauration ? (d'ailleurs, comment êtes vous sûr que la restauration va fonctionner le jour J ?)

- quels sont les effets d'une non exécution des maintenance d'index ? comment les mesures ont été prises ?

- quels sont les effets du non rafraichissement des statistiques planifié ? comment les mesures ont été prises ?

Bref, même si les réponses toutes faites sont pratiques, il ne faut pas perdre de vue l'objectif et les enjeux.

Merci pour vos réponses !
Cela me rassure et m'inquiète à la fois.
- Rassuré de voir que je n’étais pas à coté de la plaque sur mes connaissances SQL,
- Inquiet de voir le niveau de l'expert SQL qu'une société de consulting met à notre disposition.

Sur les serveurs SQL que je gère, j'utilise les scripts SQL de Ola Hallengren.
Mais j'avoue qu'ils sont exécutés en mode quasi automatique et sans configuration spécifique, faute de temps et de compétences pour les personnaliser.

Ce que j'ai donné est du basique qui convient dans 95% des cas....

Chez quelques clients je vais plus loin, mais avec des bases de plusieurs To...

Par exemple je module le seuil de prise en compte en fonction de la longueur moyenne des lignes...

A +

Bonjour SebScop :)

Concernant les jobs de Ola, voici les paramètres que j'utilise régulièrement :

Code:

---

1 2 3 4 5 6 7 8 9

EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationLevel1 = 5, @FragmentationLevel2 = 30, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y'

---

Il permet de faire la REORG des index ayant en 5% et 30% de fragmentation, le REBUILD des index ayant au dessus de 30% de fragmentation et de mettre à jour les statistiques s'il y a eu des modifications de lignes depuis la dernière mise à jour des statistiques
Il y a d'autres options par défaut qui n'apparaissent pas comme le nombre de page minimale de l'index pour qu'il soit pris en compte (1000 par défaut avec le script de Ola).

Vous pouvez trouver d'autres configuration directement en bas de la page du site de Ola :
https://ola.hallengren.com/sql-serve...intenance.html

Cordialement,

Donovan