Richtlinien für die Pflege des Volltextindex

Welche Richtlinien sollten für die Pflege von Volltextindizes beachtet werden?

Soll ich den Volltextkatalog neu erstellen oder neu organisieren (siehe BOL )? Was ist eine angemessene Wartungskadenz? Welche Heuristiken (ähnlich den Fragmentierungsschwellen von 10% und 30%) könnten verwendet werden, um zu bestimmen, wann eine Wartung erforderlich ist?

(Alles, was unten steht, ist lediglich eine zusätzliche Information, die auf die Frage eingeht und zeigt, worüber ich bisher nachgedacht habe.)

Extra Info: meine ersten Nachforschungen

Es gibt viele Ressourcen zur Pflege von B-Tree-Indizes (z. B. diese Frage , Ola Hallengrens Skripte und zahlreiche Blog-Beiträge zu diesem Thema von anderen Websites). Ich habe jedoch festgestellt, dass keine dieser Ressourcen Empfehlungen oder Skripte zur Pflege von Volltextindizes enthält.

Es gibt eine Microsoft-Dokumentation , in der erwähnt wird, dass das Defragmentieren des B-Tree-Index der Basistabelle und das anschließende Durchführen einer REORGANIZE-Operation für den Volltextkatalog die Leistung verbessern kann, spezifischere Empfehlungen jedoch nicht berührt.

Ich habe diese Frage auch gefunden , sie konzentriert sich jedoch in erster Linie auf die Änderungsnachverfolgung (wie Datenaktualisierungen der zugrunde liegenden Tabelle in den Volltextindex übertragen werden) und nicht auf die Art der regelmäßig geplanten Wartung, die die Effizienz des Index maximieren könnte.

Zusätzliche Informationen: grundlegende Leistungstests

Diese SQL-Geige enthält Code, mit dem ein Volltextindex mit AUTOÄnderungsnachverfolgung erstellt und sowohl die Größe als auch die Abfrageleistung des Index überprüft werden kann, wenn Daten in der Tabelle geändert werden. Wenn ich die Skriptlogik auf einer Kopie meiner Produktionsdaten ausführe (im Gegensatz zu den künstlich hergestellten Daten in der Geige), ist hier eine Zusammenfassung der Ergebnisse, die ich nach jedem Datenänderungsschritt sehe:

Auch wenn die Update-Anweisungen in diesem Skript ziemlich technisch sind, scheinen diese Daten zu zeigen, dass durch regelmäßige Wartung viel gewonnen werden kann.

Zusatzinfo: Erste Ideen

Ich denke darüber nach, eine nächtliche oder wöchentliche Aufgabe zu erstellen. Es scheint, dass diese Aufgabe entweder ein REBUILD oder ein REORGANIZE durchführen könnte.

Da die Volltextindizes sehr groß sein können (Dutzende oder Hunderte von Millionen Zeilen), möchte ich feststellen können, ob die Indizes innerhalb des Katalogs so fragmentiert sind, dass ein REBUILD / REORGANIZE gerechtfertigt ist. Ich bin mir ein bisschen unklar, welche Heuristiken dafür Sinn machen könnten.

Ich konnte online keine guten Ressourcen finden, also habe ich noch mehr praktische Nachforschungen angestellt und dachte, es wäre nützlich, den resultierenden Volltext-Wartungsplan zu veröffentlichen, den wir basierend auf diesen Nachforschungen implementieren.

Unsere Heuristik, um festzustellen, wann eine Wartung erforderlich ist

Unser primäres Ziel ist es, die konsistente Leistung von Volltextabfragen beizubehalten, während sich Daten in den zugrunde liegenden Tabellen entwickeln. Aus verschiedenen Gründen wäre es für uns jedoch schwierig, jede Nacht eine repräsentative Reihe von Volltextabfragen für jede unserer Datenbanken zu starten und anhand der Leistung dieser Abfragen zu bestimmen, wann eine Wartung erforderlich ist. Aus diesem Grund wollten wir Faustregeln erstellen, die sehr schnell berechnet und als Heuristik verwendet werden können, um darauf hinzuweisen, dass die Pflege des Volltextindex möglicherweise gerechtfertigt ist.

Im Verlauf dieser Untersuchung haben wir festgestellt, dass der Systemkatalog viele Informationen darüber enthält, wie ein Volltextindex in Fragmente unterteilt ist. Es wird jedoch keine offizielle "Fragmentierung%" berechnet (wie bei B-Tree-Indizes über sys.dm_db_index_physical_stats ). Basierend auf den Volltextfragmentinformationen haben wir beschlossen, unsere eigene "Volltextfragmentierung%" zu berechnen. Anschließend verwendeten wir einen Entwickler-Server, um wiederholt zufällige Aktualisierungen von 100 bis 25.000 Zeilen gleichzeitig an einer Kopie von Produktionsdaten mit 10 Millionen Zeilen durchzuführen, die Volltextfragmentierung aufzuzeichnen und eine Benchmark-Volltextabfrage mit durchzuführen CONTAINSTABLE.

Die in den obigen und unteren Diagrammen gezeigten Ergebnisse waren sehr aufschlussreich und zeigten, dass das von uns erstellte Fragmentierungsmaß sehr stark mit der beobachteten Leistung korreliert. Da dies auch mit unseren qualitativen Beobachtungen in der Produktion zusammenhängt, ist es ausreichend, dass wir die Fragmentierung% als unsere Heuristik verwenden, um zu entscheiden, wann unsere Volltextindizes gewartet werden müssen.

Der Wartungsplan

Wir haben uns entschieden, den folgenden Code zu verwenden, um eine Fragmentierung% für jeden Volltextindex zu berechnen. Alle Volltextindizes von nicht trivialer Größe mit einer Fragmentierung von mindestens 10% werden von unserer über-Nacht-Wartung als neu erstellt gekennzeichnet.

-- Compute fragmentation information for all full-text indexes on the database
SELECT c.fulltext_catalog_id, c.name AS fulltext_catalog_name, i.change_tracking_state,
    i.object_id, OBJECT_SCHEMA_NAME(i.object_id) + '.' + OBJECT_NAME(i.object_id) AS object_name,
    f.num_fragments, f.fulltext_mb, f.largest_fragment_mb,
    100.0 * (f.fulltext_mb - f.largest_fragment_mb) / NULLIF(f.fulltext_mb, 0) AS fulltext_fragmentation_in_percent
INTO #fulltextFragmentationDetails
FROM sys.fulltext_catalogs c
JOIN sys.fulltext_indexes i
    ON i.fulltext_catalog_id = c.fulltext_catalog_id
JOIN (
    -- Compute fragment data for each table with a full-text index
    SELECT table_id,
        COUNT(*) AS num_fragments,
        CONVERT(DECIMAL(9,2), SUM(data_size/(1024.*1024.))) AS fulltext_mb,
        CONVERT(DECIMAL(9,2), MAX(data_size/(1024.*1024.))) AS largest_fragment_mb
    FROM sys.fulltext_index_fragments
    GROUP BY table_id
) f
    ON f.table_id = i.object_id

-- Apply a basic heuristic to determine any full-text indexes that are "too fragmented"
-- We have chosen the 10% threshold based on performance benchmarking on our own data
-- Our over-night maintenance will then drop and re-create any such indexes
SELECT *
FROM #fulltextFragmentationDetails
WHERE fulltext_fragmentation_in_percent >= 10
    AND fulltext_mb >= 1 -- No need to bother with indexes of trivial size

Diese Abfragen führen zu folgenden Ergebnissen. In diesem Fall werden die Zeilen 1, 6 und 9 für eine optimale Leistung als zu fragmentiert markiert, da der Volltextindex über 1 MB und mindestens 10% fragmentiert ist.

Wartungskadenz

Wir haben bereits ein nächtliches Wartungsfenster und die Fragmentierungsberechnung ist sehr billig zu berechnen. Daher führen wir diese Prüfung jede Nacht durch und führen dann nur den teureren Vorgang durch, bei dem ein Volltextindex basierend auf dem Fragmentierungsschwellenwert von 10% tatsächlich neu erstellt wird, wenn dies erforderlich ist.

REBUILD vs. REORGANIZE vs. DROP / CREATE

SQL Server-Angebote REBUILDund REORGANIZE-Optionen sind jedoch nur für einen Volltextkatalog (der eine beliebige Anzahl von Volltextindizes enthalten kann) in seiner Gesamtheit verfügbar. Aus älteren Gründen haben wir einen einzigen Volltextkatalog, der alle unsere Volltextindizes enthält. Aus diesem Grund haben wir uns dafür entschieden, stattdessen einzelne Volltextindizes zu löschen ( DROP FULLTEXT INDEX) und neu zu erstellen ( CREATE FULLTEXT INDEX).

Es ist möglicherweise idealer, Volltextindizes auf logische Weise in separate Kataloge zu unterteilen und REBUILDstattdessen einen auszuführen , aber die Drop / Create-Lösung wird in der Zwischenzeit für uns funktionieren.