SQL Server - Indizes Fragmentiert

Question

Hallo zusammen,

über die Tabellen "dm_db_index_physical_stats" und "sys.indexes" habe ich herausgefunden, dass die Indizes meiner Tabellen teilweise zu 90% fragmentiert sind. Ich habe die Indizes schon neu organisiert und neu erstellt. Die Fragmentierung liegt immernoch bei 70%.

Daraufhin habe ich die Indizes über ein "Drop und Create in" -Statement komplett neu angelegt. Spätestens jetzt sollten der Index komplett neu erstellt werden. Leider weiterhin ohne Erfolg. Die Fragmentierung ist immernoch so hoch.

Woran könnte das jetzt noch liegen?

Gruß Dennis

Edit:

SQL Server 2014

Answer 1

Die Verfahren scheinen da eher anders zu sein, da eine Datenbank mit Seiten organisiert sind und eine Wiederverwendung von freien Seiten erfolgt.

https://docs.microsoft.com/de-de/sql/relational-databases/indexes/reorganize-and-rebuild-indexes#TsqlProcedureReorg

Ich denke mal, dass ein Create Index eben Seiten wiederverwendet, während ein "Reorganize" auf jeden Fall neuen Platz beansprucht.

Answer 2

Kann es sein, dass die Tabellen sehr klein sind?

When Index is rebuilt and index is having fewer amount of pages, pages to index are allocated from mixed extent which could be lying anywhere and this seems to user that fragmentation is still there. But is actually how data pages are allocated to new index with small page count, by virtue of fact that mixed pages can be lying anywhere and when these pages are allocated to index it seems to end user that fragmentation is still there but this is actually default behavior of Database Engine. pages are kind of Scattered. Since they are scattered hence they create what seems like fragmentation but actually its how Database engine allocates pages. It would also be correct to say that such indexes are not fragmented considering the real world meaning of fragmentation, which means something which causes performance issue.

SQL Server In depth: What can Cause Index to be Still Fragmented After Rebuild

HTH!

---

Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

Answer 3

Hallo Dennis, 

eine Frage hätte ich. Sind die Tabellen wo die Indexe darauf liegen stark durch Insert und Update Anweisungen beansprucht. Denn selbst auf einem neuen "sauberen" Index können schnell wieder hohe Fragmentierungen liegen wenn die Tabelle klein und häufigen Änderungen unterworfen ist. Unter 1000 Pages macht eine Indexwartung keinen unterschied.

Ein Index Reorg macht nur bei Fragmentierungen unter 30% sinn, alles was über 30% liegt muss über einen Index Rebuild erfolgen. Bei einem Rebuild wird der Index komplett neu erzeugt (genau wie beim Drop und Create) in der Zeit darf der Index und auch die Tabelle nicht genutzt werden, außer man hat die Enterprise Edition wo der Rebuild auch Online geht.

Ich würde dir empfehlen deine Index regelmäßig zu warten. Hier kannst du eine Lösung von Ola Hallengren nutzen welche sehr gut arbeitet. Skript herunterladen, ausführen und deinen Zeitplan auf den Agent Job zur Indexwartung setzten.

https://ola.hallengren.com/

---

Benjamin Hoch
MCSE: Data Platform & Data Management and Analytics
MCSA: SQL Server 2012/2014 & 2016 DB Administration
MCSA: Windows Server 2012

Answer 4

Hallo Dennis,

ich vermute das gleiche wie Christoph: Wenn ein Index unter 1000 Data Pages liegt, kannst Du den Fragmentierungsgrad komplett ignorieren und selbst bei 10 K ist so ein Faktor eher nebensächlich.

---

Olaf Helper

[ Blog] [ Xing] [ MVP]

Answer 5

Vielen Dank für all eure Antworten.

Und Ihr habt alle Recht. Jede Tabelle hat sogar unter 100 Seiten. Und die Tabellen haben viele Inserts und Updates.

OK. Dann akzeptiere ich, dass ich diese Fragmentierung in diesen kleinen Seitenbereich nicht so ernst nehmen darf. Ich habe einen Job eingerichtet, der 1x pro Woche nun nachts einmal aufräumt.

Nochmals vielen Dank für eure Antworten

Viele Grüße

Dennis

Answer 6

Wenn sehr häufig über Index auf Daten zugegriffen wird, spielt die Fragmentierung nur dann eine Rolle, wenn die Indexseiten aus dem Cache (Hauptspeicher) häufig wieder verdrängt werden.
Man muss schließlich immer daran denken, dass ja grundsätzlich alles über den Haupspeicher läuft.

https://www.sqlshack.com/insight-into-the-sql-server-buffer-cache/

Je mehr Speicher also zur Verfügung steht, desto schneller kann die Datenbank arbeiten.

https://docs.microsoft.com/de-de/sql/database-engine/configure-windows/server-memory-server-configuration-options