DBA qui s'inquiète de la réorganisation ou de la reconstruction des index peut entraîner une perte de données?

Nous avons certaines bases de données dont la fragmentation d'index est> 95%. Du mieux que je puisse dire, les index n'ont jamais été reconstruits et encore moins réorganisés. Dans des années.

(En toute honnêteté, ces tableaux semblent avoir activé les statistiques de mise à jour automatique. Également en toute honnêteté, il est diligent au sujet des sauvegardes: journaux quotidiens complets et trx toutes les heures.)

Quand j'ai demandé, le DBA a dit qu'il était réticent à reconstruire ou réorganiser les index. Quand j'ai demandé pourquoi, il ne pouvait pas vraiment l'expliquer. Finalement, il a dit qu'il était préoccupé par la perte potentielle de données. Par exemple, l'une des bases de données est utilisée par notre application de comptabilité Great Plains Dynamics, et il semblait très inquiet à ce sujet.

Je ne suis pas DBA mais d'après ce que j'ai lu, son anxiété me semble ... difficile à comprendre.

Je ne sais pas quoi faire ensuite. Suggestions comment dois-je procéder?

sql-server maintenance

— Greg Hendershott
source

À moins que cette base de données ne soit durement touchée 24 heures sur 24 et 7 jours sur 7 et que le monde se termine s'il est hors ligne, il n'y a aucune excuse pour un tel comportement. Je script des réorganisations et des statistiques chaque semaine sur plus de 12 000 bases de données sans hésitation. En 16 ans, je n'ai eu qu'un seul corrompu en raison d'un mauvais contrôleur.

— Brain2000

Réponses:

La reconstruction d'un index de base de données ne devrait entraîner aucune perte de données. Cependant, cela entraînera probablement une dégradation substantielle des performances, car les index en cours de reconstruction ne seront normalement pas disponibles jusqu'à la fin de la reconstruction. Pour cette raison, cela doit être fait pendant les heures creuses lorsque les systèmes concernés sont inactifs.

La paranoïa est une bonne chose dans un DBA - S'ils s'inquiètent de la perte de données, je leur demanderais de faire un test approprié des sauvegardes (de les restaurer sur un système séparé et de s'assurer que toutes les données sont là), et si elles sont toujours préoccupé puis effectuer une sauvegarde complète avant de reconstruire les index serait une précaution raisonnable à prendre.

— voretaq7
source

+1 pour Paranoia is Good DBA Trait

— Joel Coel

Je comprends et apprécie complètement la paranoïa saine. Mesurez deux fois, coupez une fois. Là où je suis déconcerté, cela semble être un manque de compréhension plutôt que de prudence. Et plutôt que "déterminons une façon de l'essayer, soigneusement", c'est "ouais ça ne va pas arriver". Nous pourrions (par exemple) spouler une instance EC2 de test avec une copie des données, réorganiser les index, les chronométrer, delta les lignes du tableau de résultats pour confirmer qu'aucune donnée n'a été corrompue. Ce genre de plan serait de la prudence ... par opposition à l'inaction?

— Greg Hendershott

Juste un rappel que la réorganisation de l'index est toujours en ligne (tous les index sont disponibles pendant la défragmentation) et la reconstruction de l'index peut également être effectuée en ligne ( WITH (ONLINE=ON)tant que l'index ne contient pas de colonnes BLOB.

— Remus Rusanu

@Greg Oui, la mentalité "Ne touchons tout simplement pas aux index qui sont si fragmentés qu'ils sont probablement HURTING performance" me dérange aussi - L'occasionnel REINDEXcomme "maintenance préventive" sur les tables où le contenu de l'index change beaucoup est assez joli commun dans mon expérience (si l'index est principalement statique, c'est moins une chose)

— voretaq7

@Remus good tip - Cela diminue l'impact sur les performances (vous aurez toujours des E / S de disque élevées, ce qui vous ralentira, mais au moins les choses qui utiliseraient un index peuvent toujours l'utiliser plutôt que de recourir à des analyses séquentielles )

— voretaq7

Il n'y a aucun risque de perte de données lors de la reconstruction ou de la défragmentation des index.

— mrdenny
source

À moins que vous n'ayez déjà un certain degré de corruption des données ou qu'il y ait une défaillance du matériel. Mais dans l'un ou l'autre de ces cas, la fragmentation d'index est le moindre de vos soucis!

— db2

Mais ce ne serait pas la corruption d'une reconstruction d'index, mais d'un autre problème.

— mrdenny

La réorganisation des index prendra moins de temps et nécessitera moins d'efforts de la part du serveur SQL. Ils peuvent donc être effectués dans un type d'instance de semaine. Si ce que vous dites est vrai, même la réorganisation d'index qui ne l'ont jamais été peut également avoir un impact plus important sur le serveur. La reconstruction des index prendra beaucoup d'efforts de la part du serveur SQL car ils sont supprimés et reconstruits. Faire une reconstruction un soir de semaine ne vaut pas le risque que le serveur soit occupé avec des index et ne serve pas les personnes qui l'utilisent.

Je suis d'accord avec voretaq7, s'il est si inquiet de travailler avec des index, essayez-le d'abord sur les serveurs de développement ou de test pour voir comment réagit.

— RateControl
source

Une autre approche à adopter peut être de explicitement DROP INDEXet de re CREATE INDEX- je ne suis pas sûr de SQL Server, mais je sais que PostgreSQL fait parfois mieux de supprimer un index et de recommencer à zéro plutôt que d'essayer de le reconstruire ( REINDEX).

— voretaq7

Je suis sûr que la suppression et la recréation ne sont pas nécessaires sur SQL Server.

— Justin Dearing

@Justin, je suis sûr que vous avez raison (en fait, depuis mes jours Sybase, je me souviens que le comportement de réindexation est effectivement une baisse / création, donc il n'y a pas de bizarrerie de verrouillage d'index comme dans Postgres)

— voretaq7

La réorganisation des index peut prendre moins de temps. Laquelle prendra plus de temps dépendra de la quantité de fragmentation de l'index.

— mrdenny