Y a-t-il un avantage à défragmenter les index SQL dans un environnement SAN?

16

Notre serveur SQL vit sur un SAN. Il contient des dizaines de bases de données OLTP, certaines avec plusieurs tables contenant plus de 1 million d'enregistrements.

Nous exécutons chaque semaine les scripts de maintenance d'index d'Ola Hallengren , et cela dure plusieurs heures à chaque fois. En fonction du seuil de fragmentation, le script réorganisera ou réindexera un index. Nous avons observé que lors de la réindexation, les fichiers journaux deviennent énormes, ce qui entraîne une consommation excessive de bande passante lors de l'envoi des journaux.

Vient ensuite un article de Brent Ozar dans lequel il dit de ne plus se soucier des index SQL :

Vos disques durs sont partagés avec d'autres serveurs qui font également des demandes de disques en même temps, donc les disques vont toujours sauter partout pour obtenir des données. Défragmenter vos index n'est qu'un travail chargé de sens.

Googler cette question conduit à des opinions divergentes, la plupart appuyées par des arguments qui semblent trop brefs ou faibles. Notre plan provisoire est d'ajuster le seuil de fragmentation dans notre script de maintenance afin qu'il se réorganise beaucoup plus souvent qu'il ne se réindexe.

Quel est le verdict final? Vaut-il la peine de défragmenter les index SQL sur un SAN compte tenu des charges associées à l'exécution des travaux de maintenance hebdomadaires?

— dev_etter
source

10

Les stratégies de défragmentation aident à améliorer la vitesse de numérisation vers / depuis le disque .

La grande variété d'opinions s'explique par le fait que la stratégie de défragmentation idéale d'un environnement devrait dépendre de nombreux facteurs différents. Il existe également plusieurs couches potentielles de fragmentation en jeu.

Dire que vos bases de données sont stockées sur un SAN ne suffit pas. Par exemple:

Les fichiers de base de données sont-ils stockés sur des groupes RAID physiques distincts ou sur le même groupe RAID? Quels autres processus sont actifs sur ce même appareil? Vos fichiers de sauvegarde se retrouvent-ils là aussi? Vous devrez peut-être demander ces informations à votre administrateur SAN, car elles ne sont pas toujours transparentes.
Quels sont les modèles d'accès aux bases de données? OLTP est généralement un accès aléatoire, mais parfois une application est compatible avec l'analyse de table et vous ne pouvez pas changer son comportement (application ISV). Les applications sont-elles principalement en lecture, en écriture ou quelque part entre les deux?
Y a-t-il des SLA de performance en jeu pendant une période de récupération / basculement ?

Le post de Brent suppose qu'il y a un pool géant de stockage et que tout le partage. Cela signifie que les disques physiques sont rarement inactifs, et donc la plupart des accès sont aléatoires. Si telle est votre situation, alors les conseils s'appliquent et je suis d'accord pour l'essentiel. Bien que ce type de stratégie soit beaucoup plus facile à gérer, ce n'est pas nécessairement (a) ce que vous avez dans votre environnement, ou (b) quelle est la meilleure solution pour votre environnement.

Si la maintenance de l'index est lourde, envisagez de la faire de manière moins agressive et / ou amortissez le coût sur la semaine (c.-à-d. Exécutez une maintenance légère une fois / jour, au lieu d'une maintenance lourde une fois / semaine).

Vous pouvez également activer l' SortInTempdboption pour réduire potentiellement la quantité de journalisation qui a lieu dans les bases de données utilisateur.

— Jon Seigel
source

Wow, une réponse approfondie. Il me faudra probablement un certain temps pour faire toutes les recherches, mais je ne doute pas que vous me meniez sur la bonne voie. Notre stratégie actuelle consiste en fait à exécuter la maintenance de manière moins agressive à la fois du point de vue de la reconstruction et de la réorganisation, je pense que j'ai mal exprimé cela dans la question. À partir de là, je ferai plus de recherches sur les autres facteurs que vous avez mentionnés.

— dev_etter

1

@dev_etter: Je n'ai énuméré que quelques facteurs; il y en a beaucoup plus. Le point principal est la toute première phrase. Si vous gardez cela à l'esprit lorsque vous réfléchissez à votre environnement, cela dirigera correctement votre décision. Tout découle de cela. (En outre, tout cela suppose qu'aucun SSD n'est impliqué.)

— Jon Seigel

FWIW, j'avais complètement oublié quelque chose - le script réel dans l'étape de travail (plutôt que la source) a été configuré pour adresser chaque index qui avait un pourcentage de fragmentation minimum de 1. J'ai grimpé jusqu'à 15 et j'ai également dépassé le seuil de reconstruction de 30 à 35. Le travail s'exécute maintenant en un peu plus de 3 heures au lieu de 8. Votre suggestion d'être moins agressif était correcte. Ma faute résidait dans le fait que je pensais que le travail avait déjà été exécuté pour être moins agressif. Cette approche est probablement la meilleure pour nous, touchez et partez, mais elle a déjà soulagé certaines douleurs.

— dev_etter

@ JonSeigel Je suis totalement d'accord avec cette réponse. Au cours de mes voyages, je vois la plupart des DBA partager un seul pool, ou au moins une baie au même niveau RAID. J'ai eu des DBA à 3 heures du matin 24h / 24 et 7j / 7 juste pour défragmenter des groupes de fichiers individuels de bases de données de plus de 100 To ... et pour quoi exactement? Nous avions des E / S totalement aléatoires sur les disques et la latence était de 15 ms. À ce stade, je devrais simplement indiquer 15 ms et dire aux développeurs de me laisser tranquille.

— ooutwire

2

Idéalement, vous devez réorganiser / réindexer UNIQUEMENT les index qui nécessitent une attention, sinon vous gaspillez des ressources et vous risquez de causer d'autres problèmes.

Vous devez établir une référence de performances et chaque fois que vous apportez des modifications, comparez la modification des performances à la référence pour déterminer si votre modification mérite d'être mise en œuvre.

— Jimbo
source

Notre stratégie immédiate consiste à faire exactement cela - nous allons modifier les paramètres des variables minFragmentation et rebuildThreshold dans ce script: sqlfool.com/2011/06/index-defrag-script-v4-1

— dev_etter

0

D'accord, la question concerne les index de base de données, qui sont une construction d'un fichier ou d'un ensemble de fichiers. La lecture des réponses ci-dessus amènerait une personne à croire que nous parlons de fragmentation au niveau du disque et non des index à l'intérieur d'un fichier. Ces sujets totalement séparés.

L'approche myope ici est que les performances lors de la récupération des données à l'intérieur et la base de données OLTP s'améliorent si les index sont fragmentés ou reconstruits. La réponse est oui! Cependant, il est important de noter que la fragmentation du disque est également un facteur.

"Coût" le plus bas dans l'ensemble? Faites votre maintenance de base de données. Deuxième coût le plus bas, détachez la base de données, déplacez-la ailleurs, reformatez vos disques et suivez les meilleures pratiques pour l'alignement des partitions de disque http://msdn.microsoft.com/en-us/library/dd758814.aspx . Enfin, utilisez un défragmenteur avancé tiers comme Diskkeeper.

Gardez à l'esprit que ceci est UNIQUEMENT recommandé pour le stockage de type NTFS (par exemple, Windows OS) et ce n'est pas une approbation pour aucun produit et je ne suis pas affilié à Condusiv Technologies ou à ses filiales.

— IryDBA2791
source

2

Vous voudrez probablement éviter de dire catégoriquement "La réponse est OUI!" aux espaces problématiques qui ont été longuement discutés par d'autres affiches. S'il est vrai que parfois la réponse est «oui», comme l'a montré Brent Ozar dans son billet de blog, ce n'est pas toujours le cas.

— Max Vernon