Zunächst ist es wichtig zu prüfen, ob Fragmentierung wichtig ist.
Wenn Ihre Abfrage nur einzeilige Suchvorgänge ausführt, bemerken Sie möglicherweise überhaupt keine Fragmentierung. In modernen SANs können durch das Caching auf SAN-Ebene phyiskale E / A-Vorgänge schnell genug ausgeführt werden, sodass die Fragmentierung keine Rolle spielt. Auf einer SSD kann das zufällige E / A-Muster, das durch das Scannen eines fragmentierten Index verursacht wird, tatsächlich zu einer besseren Leistung führen als nicht fragmentierte Daten.
Oft bemerken die Leute, dass die Neuerstellung eines Index ein Leistungsproblem behoben hat. Durch die Neuerstellung eines Index werden auch neue Statistiken erstellt. Es kann sein, dass der eigentliche Fix frische Statistiken sind und nicht den Index neu erstellen. UPDATE STATISTICS...WITH FULLSCANDies kann eine billigere, schnellere und weniger aufdringliche Methode sein, um dasselbe Leistungsproblem zu lösen.
Wenn Sie keine durch Fragmentierung verursachten Probleme haben, müssen Sie möglicherweise viel Zeit und Mühe aufwenden, um keinen tatsächlichen Gewinn zu erzielen.
Zweitens gibt es zwei Arten der Fragmentierung:
Physikalische Fragmentierung. Daran denken die meisten Menschen, wenn sie an Fragmentierung denken. Die Seiten sind nicht in Ordnung und müssen neu bestellt werden. Beim Scannen eines Index kann diese Art der Fragmentierung manchmal ein Problem sein. Ich habe allgemein festgestellt, dass dies den größten Einfluss auf die Leistung bei physischen Lesevorgängen hat. Wenn Sie sich die Ergebnisse von ansehen sys.dm_db_index_physical_stats, ist diese Nummer die avg_fragmentation_in_percentSpalte.
Fragmentierung mit geringer Dichte. Diese Fragmentierung wird durch Seiten verursacht, die nur teilweise mit Daten gefüllt sind. Sie haben eine geringe Datendichte , da Ihre Daten auf mehr Seiten als erforderlich verteilt sind. Infolgedessen erfordert das Lesen der Daten mehr E / A, da die Daten auf mehr Seiten als erforderlich verteilt sind. Dies kann sich sowohl auf logische als auch auf physische Lesevorgänge auswirken. Wenn Sie sich die Ergebnisse von ansehen sys.dm_db_index_physical_stats, ist diese Nummer die avg_page_space_used_in_percentSpalte. Diese Spalte wird nur bei Verwendung von SAMPLEDoder DETAILEDmode ausgefüllt.
Was tun Sie dagegen?
Physische Fragmentierung : Wenn Sie einfach nur hohe Zahlen suchen avg_fragmentation_in_percent, sollten Sie wirklich überlegen, ob Sie Ihre Zeit verschwenden. Stellen Sie sicher, dass Sie eine tatsächliche Abfrage haben, die schlecht funktioniert, und verwenden Sie eine Testumgebung, um zu bestätigen, dass Sie ein Problem beheben, indem Sie die Fragmentierung beseitigen.
Sie können die physische Fragmentierung beheben, indem Sie dies tun ALTER INDEX...REORGANIZE. Der REORGANIZEVorgang ist online und verschiebt die Seiten nacheinander, um sie wieder in physische Reihenfolge zu bringen. Wenn Sie eine REORGANIZEAnweisung auf halbem Weg beenden, wird jede bereits ausgeführte Arbeit beibehalten. Es wird nur die eine Seite verschoben, die gerade verschoben wird. Das Ausführen einer REORGANIZEgroßen Tabelle mit starker Fragmentierung kann mehr Speicherplatz für das gesamte Transaktionsprotokoll erfordern und im vollständigen Wiederherstellungsmodus möglicherweise eine erhebliche Anzahl von Transaktionsprotokollsicherungen generieren. REORGANIZEEin stark fragmentierter Index kann auch länger dauern als ein REBUILD.
Sie werden häufig Ratschläge erhalten, eine REBUILDfür stark fragmentierte Indizes durchzuführen , anstatt eine REORGANIZE- Dies liegt daran, dass die Neuerstellung von Grund auf effizienter sein kann. Eine Reorganisation kann jedoch eine "onlineere" Operation sein und wird manchmal sogar für stark fragmentierte Indizes bevorzugt.
Fragmentierung mit niedriger Dichte kann nicht durch behoben werden REORGANIZE. Es kann nur durch eine behoben werden ALTER INDEX...REBUILD. Wenn Sie den Index mit ONLINE=ONausführen, sollten Sie in der Lage sein, das Blockieren zu minimieren. Das muss jedoch REBUILDnoch für einen Moment gesperrt werden, um den alten Index gegen den neuen Index auszutauschen. In einem sehr ausgelasteten System kann das Erreichen dieser exklusiven Sperre manchmal ein Problem sein. Sie sollten in der Lage sein, zu bestätigen, ob Sie dieses Problem haben, indem Sie sp_whoisactive verwenden , um die Blockierung während Ihrer Neuerstellung zu untersuchen und die Details der Sperren und Wartezeiten zu überprüfen. Die Verwendung der WAIT_AT_LOW_PRIORITYOption kann nützlich sein, wenn Sie wissen, dass eine geringe Auslastung bevorsteht und sich Ihre Neuerstellung für diesen Tausch "einschleichen" kann, wenn die Aktivität niedrig genug ist, um diese Sperre zu erreichen. Beachten Sie, dass eine lange LaufzeitREBUILDOperation wird auch eine lange offene Transaktion sein. Offene Transaktionen mit langer Laufzeit können ihre eigenen Probleme haben, die mit der Verwendung / Wiederverwendung von Transaktionsprotokollen zusammenhängen. Wenn Sie Spiegelungs- oder Verfügbarkeitsgruppen verwenden, gibt es auch Überlegungen zum Wiederherstellen des Transaktionsprotokolls auf dem sekundären Replikat.
REORGANIZEreduziert selbst bei hoher Fragmentierung die Fragmentierung von Blattseiten und den kompakten SpeicherplatzREBUILD, nur weniger effizient. Sind Sie sicher, dass die Größe auf Fragmentierung zurückzuführen ist? Was ist der Füllfaktor?