Microsoft SQL Server 2008 - 99% Fragmentierung auf non-clustered, non-unique index
Ich habe eine Tabelle mit mehreren Indizes (wie nachstehend definiert). Einer der Indizes (IX_external_guid_3) hat 99% Fragmentierung unabhängig davon, Umbau/Neuorganisation der index. Jemand eine Idee, was den Fehler verursachen, oder der beste Weg, um es zu beheben?
Sind wir mit Entity Framework 4.0 zur Abfrage dieser, die EF-Abfragen auf der anderen indizierten Felder zu 10x schneller im Durchschnitt dann die external_guid_3 Feld, aber ein ADO.Net Abfrage ist in etwa die gleiche Geschwindigkeit auf beiden (obwohl 2x langsamer als die EF-Abfrage an indizierte Felder).
Tabelle
- - id(PK, int, not null)
- guid(uniqueidentifier, null, "rowguid")
- external_guid_1(uniqueidentifier, not null)
- external_guid_2(uniqueidentifier, null)
- Zustand(varchar(32), null)
- value(varchar(max), null)
- infoset(XML(.), null) --> in der Regel 2-4K
- created_time(datetime, null)
- updated_time(datetime, null)
- external_guid_3(uniqueidentifier, nicht
null) - FK_id(FK, int, null)
- locking_guid(uniqueidentifer, null)
- locked_time(datetime, null)
- external_guid_4(uniqueidentifier,
null) - corrected_time(datetime, null)
- is_add(bit, nicht null) Wert(int,
null) - row_version(timestamp, null)
Indizes
- PK_table(Gruppierten)
- IX_created_time(Nicht Eindeutigen, Nicht Gruppierten)
- IX_external_guid_1(Nicht Eindeutigen, Nicht Gruppierten)
- IX_guid(Nicht Eindeutigen, Nicht Gruppierten)
- IX_external_guid_3(Nicht Eindeutigen, Nicht Gruppierten)
- IX_state(Nicht Eindeutigen, Nicht Gruppierten)
Du musst angemeldet sein, um einen Kommentar abzugeben.
Hinweis: SQL Server Best Practices Zustand, Indizes mit weniger als 10.000 Seiten in der Regel nicht profitieren von performance-Steigerungen.
Sehen http://technet.microsoft.com/en-gb/library/cc966523.aspx
http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx?pr=blog
Hier ein kleines snippet, um festzustellen, Wann die DB muss defragmentieren.In unserem Produkt, wir reduzierten dieses auf 2000 und wählte >20% Fragmentierung.
Sie können ganz einfach ändern Sie das Skript, Ihnen zu sagen, die indecies im besonderen.
Sieht es tatsächlich einfach wie Indexierung auf einem guid-könnte das das übel sein hier:
http://www.sqlskills.com/blogs/paul/can-guid-cluster-keys-cause-non-clustered-index-fragmentation/
Letzter Zeit habe ich Suche nach eine Reihe von hinweisen, die scheinen dies zu unterstützen.
Du wahrscheinlich nicht genug Daten in den index zu verdienen defragmentieren. Nachdem Sie ein paar tausend Zeilen, die Umbauten und reorgs wird loszuwerden, die Fragmentierung.
Bis die index-Seite zählen, bekommt bis zu 100 oder so, die Fragmentierung hat keine Auswirkungen auf die Leistung.
Werden Sie auch wollen, um sicherzustellen, dass Ihre Abfrage vom index abgedeckt wird und dass der index verwendet wird.
Führen Sie die Abfrage aus dem management studio (erfassen Sie die Abfrage mit sql profiler oder die Aktivitätsanzeige, wenn es dynamisch ist), und klicken Sie auf "tatsächlichen Ausführungsplan Einschließen". Dies wird Ihnen sagen, welche index verwendet wird, und wenn die Abfrage abgedeckt.
Drehen db-auto-shrink aus. Es scheint eine Nebenwirkung der Fragmentierung von Indizes.