Tabellenoptimierung vs Füllfaktor

Hallo,

wie haben einen Kunden (Client 5.00 SP1 Build 28884), der trotz SQL-DB und diversen Wartungsjobs immer eine Tabellenoptimierung in NAV durchführt. Er ist momentan nicht davon abzubringen, weil er durch die Optimierung der einzelnen Tabellen erheblich Platz einspart (DB > 100GB)
Der SQL-Server hat als Standardfüllfaktor 90% eingestellt. Meine Frage/Vermutung ist jetzt, ob die Tabellenoptimierung nicht den extra reservierten Platz vom Füllfaktor nicht wieder freigibt und deshalb immer wieder Platz beim Optimieren der Tabelle eingespart wird? Ist das so oder warum wird beim Tabellenoptimieren so viel Platz eingespart? Leere SIFTS sollten bei dem Stand doch kein Problem mehr sein oder?

Oh je ...

Nun, Füllfaktoren können wichtig sein, es ist aber entscheidend wo und wie man ihn einstellt. Den "Standard Füllfaktor" auf SQL Server Instanz-Ebene zu setzen ist Quatsch - das betrifft dann alle Tabellen/Indexe in allen Datenbanken ...

Wenn man den FF nicht mit Tools berechnen und individuell einstellen kann, dann sollte man einen Wartungsplan mit dem "Index Rebuild" Task erstellen und dort den freien Speicher eintragen; also für einen FF von 90% eben "10% freier Speicher" angeben.
Letztlich kommt es beim FF auf das aufzunehmende Wachstum der DB innerhalb des Wartungszeitraumes an; heißt also: ein FF von 90% (10% frei) ist gedacht um ein durchschnittliches Wachstum vom 10% innerhalb des Wartungszeitraumes (Woche?) aufzunehmen.
Bei einer DB von 100GB+ Größe (netto?) bedeutet das, dass ein Wachstum von 10GB pro Woche angenommen wird ... ist das plausibel?
Leider wachsen auch nicht alle Indexe gleich stark, deshalb ist es nicht einfach einen optimalen "globalen FF" zu finden, aber ich würde das mal auf 95% (5% frei) ändern.

Zum "Table Optimizer": Der TO baut die Indexe stets komplett neu auf (CREATE INDEX WITH DROP EXISTING); im Gegensatz zum "Rebuild Index" (ALTER INDEX REBUILD).
Das Ergebnis des TO ist normalerweise nur marginal besser, aber sowas erzeugt natürlich super Last im System und dauer eeeeewig lange.
CREATE WITH DROP EXISTING ist etwa so, als würdest Du bei denem PC ständig FORMAT C:\ durchführen und alles neu installieren; ALTER INDEX defragmentiert eben nur (und wenn man's richtig macht mit schneller Laufzeit, minimalem Impact und sehr gutem Ergebnis).
Der FF bleibt aber auch mit dem TO erhalten, dafür sorgt der "Standard" FF ...

Mein Rat: Finger weg von dem "Table Optimizer" - der Wartungsplan macht's besser (und wie man's noch besser machen kann steht z.B. hier)

P.S.: Über wie viel "Platzeinsparung" reden wir denn hier? Und wie lange hält die "Ersparnis" an?

Wie gesagt, wir versuchen es ihm auch auszureden, aber uns haben bis jetzt die triftigen Argumente gefehlt und nur gefährliches Halbwissen behaupten ist nicht unser Stil.

Die Datenbank wächst ca. 200 - 300 MB pro Tag (! mit 24/7). Performanceprobleme gibt es eigentlich nicht, zumal ein dir bekannter Herr R. auch schon zweimal vor Ort war und die Datenbank performanceoptimiert hat. Es geht dem Kunden tatsächlich nur um die Größe der DB (wegen Sicherung und Rebuild) und deswegen macht er den TO. Wenn er die Tabellen optimiert hat, sind es schon ein paar GB (~ 10GB) weniger (er hat dann ein ruhiges Gewissen) und er macht es 1x im Monat. Jetzt ist dem Kunden aufgefallen, dass die DB innerhalb einer Woche um ca. 7 GB gewachsen ist, obwohl wie immer gearbeitet wurde.

Warum wird jetzt die Größe der Tabelle bei TO kleiner und warum kann es so einen Sprung in der Größe geben?

P.s.: letztens hat er auch die T37 optimiert, danach gab es teilweise Performanceprobleme.

Es geht dem Kunden tatsächlich nur um die Größe der DB (wegen Sicherung und Rebuild) und deswegen macht er den TO. Wenn er die Tabellen optimiert hat, sind es schon ein paar GB (~ 10GB) weniger (er hat dann ein ruhiges Gewissen) und er macht es 1x im Monat.
Warum wird jetzt die Größe der Tabelle bei TO kleiner und warum kann es so einen Sprung in der Größe geben?

Das bedeutet ja, dass die DB in dem Monat ziemlich stark fragmentiert. Wenn der TO zuschlägt und die Indexe neu aufbaut dann werden diese ja defragmentiert und ggf. Speicher-Seiten freigegeben; daher das "schrumpfen".
Das ist aber eher ein Indiz dafür, dass man die Index-Defragmentierung häufiger durchführen sollte (ich empfehle mindestens wöchentlich), was bei 24/7 out-of-the-box nicht so einfach ist ...