Richtiger Wert für den Füllfaktor für Clustered-Indizes mit Ersatzidentitätsschlüsseln

Ich habe eine große Tabelle mit einem Clustered-Index mit einem Identitätsprimärschlüssel. Ich entscheide mich für den richtigen Wert für den Füllfaktor für diese Tabelle, um Seitenaufteilungen zu minimieren. Wir verwalten Indizes mithilfe eines täglich ausgeführten Skripts, das die Fragmentierung misst und geeignete Maßnahmen ergreift. Die Tabelle enthält Spalten variabler Länge.

Mein erster Gedanke war, es auf 100 zu setzen (da Datensätze nur bis zum Ende der Tabelle geschrieben werden sollten), aber ich gehe davon aus, dass Änderungen an den Spalten mit variabler Länge auch zu Seitenaufteilungen führen können, also gehe ich jetzt in Richtung 90.

Jeder Rat geschätzt.

Es hängt davon ab, ob

Es ist ein Balanceakt. Wenn Ihre Tabelle intensiv gelesen wird und nicht viele Aktualisierungen oder Löschungen vorgenommen wurden, sollte die Standardeinstellung (100) in Ordnung sein.

Wenn Ihre Tabelle sehr schreibintensiv ist und viele Aktualisierungen enthält, ist ein Wert unter 80 möglicherweise besser geeignet.

Es gibt keine Zauberformel für dieses Zeug. (AFAIK, wenn ja, lassen Sie es mich bitte wissen.) Am besten haben Sie eine Testumgebung und eine Arbeitslast zum Testen. Nehmen Sie die Änderungen vor und sehen Sie, wie sich Ihre Datenbank mit der Arbeitslast verhält.

Nick ist ziemlich richtig.

Wenn Sie Aktualisierungen durchführen, die die Größe eines Datensatzes auf gepackten Seiten erhöhen, verursachen Sie Seitensplits. Abgesehen davon führt ein Identitätsprimärschlüssel jedoch nicht zu Seitensplits im Clustered-Index.

(Obwohl dies gesagt wird, gibt es 5 Arten von Seitenteilungen, die die Storage Engine ausführen kann, und nicht alle verursachen Fragmentierung und Datenverschiebung. Diejenige, die Sie beim Einfügen von monatlich ansteigenden Identitätswerten erhalten, ist eine Teilung am Ende der Seite Ich schweife ab...)

Ich habe vielen Kunden dabei geholfen und die BOL darüber geschrieben - wenn Sie nur einen Wert als Einsatz vor Ort auswählen möchten, haben 70% den größten Erfolg erzielt. Wie Nick sagt, überwachen und optimieren Sie nach Bedarf.

Die Auswahl eines Füllfaktors für einen Index ist ein Balanceakt dafür, wie viel Aktivität auftritt, die die Seitenfülle auf 100% erhöht, und wie oft Sie Korrekturmaßnahmen ergreifen können, um den Füllfaktor zurückzusetzen. Sie müssen darüber nachdenken, wie viel Speicherplatz auf den Seiten anfänglich "verschwendet" wird, wenn Sie den Füllfaktor wirklich niedrig einstellen, z. B. 50%, aber ich habe wieder gesehen, dass dies in einigen Fällen angemessen ist.

Sie sollten auch überlegen, wie der Index verwendet wird. Wenn es sich nur um Singleton-Lookups handelt, können Sie mit einem niedrigeren Füllfaktor und mehr Zeit zwischen Neuerstellung / Defragmentierung davonkommen, da Sie nicht zu viele E / A / Speicher verschwenden, wenn Sie einen Großteil des dünn besiedelten Clustered-Index im Speicher haben. Für Scans mit großer Reichweite möchten Sie den Füllfaktor etwas höher haben, um die E / A- und Speichereffizienz zu erhöhen.

Es gibt auch die Frage OLTP vs DW - normalerweise ändert sich ein DW nicht, sodass die Indizes einen 100% igen Füllfaktor haben. OLTP ist der schwierige Teil.

Denken Sie nach dem Sortieren des Clustered-Index daran, dass auch die Nicht-Clustered-Indexe Aufmerksamkeit benötigen, da sie höchstwahrscheinlich fragmentiert werden.

Denken Sie beim Zurücksetzen des Füllfaktors daran, dass Sie zwischen Neuaufbau und Defragmentierung wählen können. DBCC INDEXDEFRAG / ALTER INDEX ... REORGANIZE kann den Füllfaktor in einigen Fällen für Indizes zurücksetzen, die nicht stark fragmentiert sind.

Hoffe das hilft!

(Entschuldigung für die 'Überantwort' - einer meiner Hot-Buttons, nachdem ich den Code geschrieben habe :-)