DBA: Wer befürchtet, dass die Reorganisation oder der Neuaufbau von Indizes zu Datenverlusten führen kann?

Wir haben einige Datenbanken mit einer Indexfragmentierung von> 95%. Soweit ich weiß, wurden die Indizes noch nie neu erstellt und noch nie weniger neu organisiert. In Jahren.

(Um fair zu sein, scheinen für diese Tabellen automatisch aktualisierte Statistiken aktiviert zu sein. Um fair zu sein, kümmert er sich auch gewissenhaft um Sicherungen: stündlich vollständige tägliche und TRX-Protokolle.)

Als ich fragte, sagte der DBA, er zögere, die Indizes neu zu erstellen oder neu zu ordnen. Als ich fragte, warum, konnte er es nicht wirklich artikulieren. Schließlich sagte er, er sei besorgt über einen möglichen Datenverlust. Zum Beispiel wird eine der Datenbanken von unserer Buchhaltungsanwendung Great Plains Dynamics verwendet, und er schien diesbezüglich sehr besorgt zu sein.

Ich bin kein DBA, aber nach dem, was ich gelesen habe, scheint seine Angst ... für mich schwer zu verstehen.

Ich bin mir nicht sicher, was ich als nächstes tun soll. Vorschläge, wie ich vorgehen soll?

sql-server maintenance

— Greg Hendershott
quelle

Solange diese Datenbank nicht rund um die Uhr hart getroffen wird und die Welt untergeht, wenn sie offline geht, gibt es keine Entschuldigung für ein solches Verhalten. Ich schreibe jede Woche Reorgs und Statistiken in über 12.000 Datenbanken, ohne dass ich darüber nachdenken muss. In 16 Jahren hatte ich wegen eines schlechten Controllers nur einen korrupten.

— Brain2000

Antworten:

Das Neuerstellen eines Datenbankindex sollte keinen Datenverlust verursachen. Dies führt jedoch wahrscheinlich zu einer erheblichen Verschlechterung der Leistung, da die neu erstellten Indizes normalerweise erst nach Abschluss der Neuerstellung zur Verwendung zur Verfügung stehen. Aus diesem Grund sollte dies außerhalb der Geschäftszeiten erfolgen, wenn die betroffenen Systeme inaktiv sind.

Paranoia ist eine gute Sache in einem DBA - Wenn sie sich Sorgen um Datenverlust machen, lassen Sie sie die Backups ordnungsgemäß testen (stellen Sie sie auf einem separaten System wieder her und stellen Sie sicher, dass alle Daten vorhanden sind) und ob sie es sind Es wäre eine vernünftige Vorsichtsmaßnahme, eine vollständige Sicherung durchzuführen, bevor die Indizes neu erstellt werden.

— voretaq7
quelle

+1 für Paranoia ist gute DBA-Eigenschaft

— Joel Coel

Ich verstehe und schätze gesunde Paranoia. Zweimal messen, einmal schneiden. Wo ich verblüfft bin, geht es eher um Unverständnis als um Vorsicht. Und anstatt "Lass uns einen Weg finden, es sorgfältig zu versuchen", ist es "Ja, das wird nicht passieren". Wir könnten (sagen wir) eine Test-EC2-Instanz mit einer Kopie der Daten spoolen, die Indizes neu ordnen, den Zeitpunkt festlegen und die Ergebnistabellenzeilen delta, um zu bestätigen, dass keine Daten beschädigt wurden. Ein solcher Plan wäre Vorsicht ... im Gegensatz zu Untätigkeit?

— Greg Hendershott

Nur eine Erinnerung, dass die Indexreorganisation immer online ist (alle Indizes sind während der Defragmentierung verfügbar) und die WITH (ONLINE=ON)

— Indexrekonstruktion

@ Greg Yeah, die Mentalität "Lassen Sie uns einfach nicht die Indizes anfassen, die so fragmentiert sind, dass sie wahrscheinlich die Leistung beeinträchtigen" verwirrt mich ebenfalls. Die gelegentliche REINDEX"vorbeugende Wartung" von Tabellen, bei denen sich der Indexinhalt stark ändert, ist hübsch nach meiner erfahrung üblich (wenn der index überwiegend statisch ist, ist das weniger

— wichtig

@Remus guter Tipp - Dies verringert die Auswirkungen auf die Leistung (Sie werden immer noch hohe Festplatten-E / A haben, was Sie verlangsamen wird, aber zumindest Dinge, die einen Index verwenden würden, können ihn weiterhin verwenden, anstatt auf sequentielle Scans zurückzugreifen )

— voretaq7

Es besteht kein Risiko eines Datenverlusts durch Neuerstellen oder Defragmentieren von Indizes.

— mrdenny
quelle

Es sei denn, Sie haben bereits einen gewissen Grad an Datenbeschädigung oder es liegt ein Hardwarefehler vor. In beiden Fällen ist die Indexfragmentierung die geringste Sorge für Sie!

— db2

Dies wäre jedoch keine Beschädigung durch eine Indexwiederherstellung, sondern ein anderes Problem.

— Mrdenny

Das Reorganisieren der Indizes nimmt weniger Zeit in Anspruch und erfordert weniger Aufwand vom SQL Server, sodass sie in Instanzen vom Typ "weeknight" ausgeführt werden können. Wenn Sie das, was Sie sagen, als wahr bezeichnen, kann das Reorganisieren der noch nie dagewesenen Indizes auch größere Auswirkungen auf den Server haben. Das Neuerstellen der Indizes erfordert einen erheblichen Aufwand für den SQL Server, da sie gelöscht und neu erstellt werden. Eine Wiederherstellung an einem Wochentag ist nicht das Risiko wert, dass der Server mit Indizes beschäftigt ist und die Benutzer nicht bedient.

Ich stimme voretaq7 zu, wenn er sich solche Sorgen um die Arbeit mit Indizes macht, probiere es zuerst auf den Entwicklungs- oder Testservern aus, um zu sehen, wie die reagieren.

— RateControl
quelle

Ein anderer Ansatz könnte darin bestehen, SQL Server explizit DROP INDEXund neu zu definieren. CREATE INDEXIch bin mir jedoch nicht sicher, aber ich weiß, dass PostgreSQL es manchmal besser macht, einen Index wegzublasen und von vorne zu beginnen, als ihn neu zu erstellen ( REINDEX).

— Voretaq7

Ich bin mir ziemlich sicher, dass das Löschen und Neuerstellen auf SQL Server nicht erforderlich ist.

— Justin Dearing

@Justin Ich bin mir ziemlich sicher, dass Sie Recht haben (in der Tat von meinen Sybase-Tagen erinnere ich mich, dass das Neuindizierungsverhalten effektiv ein Ablegen / Erstellen ist, so dass es keine merkwürdige Indexverriegelung wie in Postgres gibt)

— voretaq7

Das Reorganisieren von Indizes kann weniger Zeit in Anspruch nehmen. Welche länger dauert, hängt vom Fragmentierungsgrad des Index ab.

— Mrdenny