Pedoman untuk pemeliharaan indeks teks lengkap

Pedoman apa yang harus dipertimbangkan untuk mempertahankan indeks teks lengkap?

Haruskah saya MEMBANGUN KEMBALI atau MEMBUKA KEMBALI katalog teks lengkap (lihat BOL )? Apa itu irama perawatan yang masuk akal? Heuristik apa (mirip dengan ambang fragmentasi 10% dan 30%) yang dapat digunakan untuk menentukan kapan pemeliharaan diperlukan?

(Segala sesuatu di bawah ini hanyalah informasi tambahan yang menguraikan pertanyaan dan menunjukkan apa yang saya pikirkan sejauh ini.)

Info tambahan: penelitian awal saya

Ada banyak sumber daya pada pemeliharaan indeks b-tree (misalnya, pertanyaan ini , skrip Ola Hallengren , dan banyak posting blog tentang subjek dari situs lain). Namun, saya telah menemukan bahwa tidak satu pun dari sumber daya ini memberikan rekomendasi atau skrip untuk mempertahankan indeks teks lengkap.

Ada dokumentasi Microsoft yang menyebutkan bahwa defragment indeks b-tree dari tabel dasar dan kemudian melakukan REORGANISASI pada katalog teks lengkap dapat meningkatkan kinerja, tetapi tidak menyentuh rekomendasi yang lebih spesifik.

Saya juga menemukan pertanyaan ini , tetapi terutama difokuskan pada pelacakan perubahan (bagaimana pembaruan data ke tabel yang mendasarinya disebarkan ke dalam indeks teks lengkap) dan bukan jenis pemeliharaan terjadwal yang dapat memaksimalkan efisiensi indeks.

Info tambahan: pengujian kinerja dasar

Ini Fiddle SQL berisi kode yang dapat digunakan untuk membuat indeks teks lengkap dengan AUTOpelacakan perubahan dan memeriksa kedua ukuran dan permintaan kinerja indeks sebagai data dalam tabel tersebut dimodifikasi. Ketika saya menjalankan logika skrip pada salinan data produksi saya (sebagai lawan dari data buatan yang dibuat dalam biola), berikut adalah ringkasan hasil yang saya lihat setelah setiap langkah modifikasi data:

Meskipun pernyataan pembaruan dalam skrip ini dibuat secara wajar, data ini tampaknya menunjukkan bahwa ada banyak hal yang dapat diperoleh dengan pemeliharaan rutin.

Info tambahan: Gagasan awal

Saya sedang berpikir tentang membuat tugas malam atau mingguan. Tampaknya tugas ini dapat melakukan REBUILD atau REORGANIZE.

Karena indeks teks lengkap mungkin cukup besar (puluhan atau ratusan juta baris), saya ingin dapat mendeteksi kapan indeks dalam katalog cukup terfragmentasi sehingga diperlukan REBUILD / REORGANIZE. Saya sedikit tidak jelas tentang apa heuristik mungkin masuk akal untuk itu.

Saya tidak dapat menemukan sumber daya yang bagus di internet, jadi saya melakukan penelitian lebih lanjut dan berpikir akan berguna untuk memposting rencana pemeliharaan teks lengkap yang kami implementasikan berdasarkan penelitian itu.

Heuristik kami untuk menentukan kapan pemeliharaan diperlukan

Tujuan utama kami adalah untuk mempertahankan kinerja kueri teks lengkap yang konsisten saat data berevolusi dalam tabel yang mendasarinya. Namun, karena berbagai alasan akan sulit bagi kami untuk meluncurkan rangkaian representatif dari permintaan teks lengkap terhadap setiap basis data kami setiap malam dan menggunakan kinerja dari pertanyaan tersebut untuk menentukan kapan pemeliharaan diperlukan. Oleh karena itu, kami ingin membuat aturan praktis yang dapat dihitung dengan sangat cepat dan digunakan sebagai heuristik untuk menunjukkan bahwa pemeliharaan indeks teks lengkap mungkin diperlukan.

Dalam perjalanan eksplorasi ini, kami menemukan bahwa katalog sistem menyediakan banyak informasi tentang bagaimana indeks teks lengkap apa pun dibagi menjadi fragmen. Namun, tidak ada "% fragmentasi%" resmi dihitung (karena ada untuk indeks b-tree melalui sys.dm_db_index_physical_stats ). Berdasarkan informasi fragmen teks lengkap, kami memutuskan untuk menghitung "% fragmentasi teks lengkap" kami sendiri. Kami kemudian menggunakan server dev untuk berulang kali membuat pembaruan acak di mana saja antara 100 dan 25.000 baris sekaligus menjadi 10 juta baris salinan data produksi, merekam fragmentasi teks lengkap, dan melakukan patokan menggunakan permintaan teks lengkap CONTAINSTABLE.

Hasilnya, seperti yang terlihat pada grafik di atas dan di bawah, sangat mencerahkan dan menunjukkan ukuran fragmentasi yang kami buat sangat berkorelasi dengan kinerja yang diamati. Karena ini juga berkaitan dengan pengamatan kualitatif kami dalam produksi, ini cukup bahwa kami merasa nyaman menggunakan% fragmentasi sebagai heuristik kami untuk memutuskan kapan indeks teks lengkap kami memerlukan pemeliharaan.

Rencana pemeliharaan

Kami telah memutuskan untuk menggunakan kode berikut untuk menghitung% fragmentasi untuk setiap indeks teks lengkap. Indeks teks lengkap ukuran non-sepele dengan fragmentasi setidaknya 10% akan ditandai untuk dibangun kembali oleh pemeliharaan malam kami.

-- 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

Kueri ini menghasilkan hasil seperti berikut, dan dalam hal ini baris 1, 6, dan 9 akan ditandai sebagai terlalu terfragmentasi untuk kinerja yang optimal karena indeks teks lengkap lebih dari 1MB dan setidaknya 10% terfragmentasi.

Irama pemeliharaan

Kami sudah memiliki jendela pemeliharaan setiap malam, dan perhitungan fragmentasi sangat murah untuk dihitung. Jadi kami akan menjalankan pemeriksaan ini setiap malam dan kemudian hanya melakukan operasi yang lebih mahal untuk benar-benar membangun kembali indeks teks lengkap bila diperlukan berdasarkan ambang fragmentasi 10%.

BANGUN KEMBALI vs. REORGANISASI vs. DROP / BUAT

SQL Server menawarkan REBUILDdan REORGANIZEopsi, tetapi mereka hanya tersedia untuk katalog teks lengkap (yang mungkin berisi sejumlah indeks teks lengkap) secara keseluruhan. Untuk alasan sebelumnya, kami memiliki satu katalog teks lengkap yang berisi semua indeks teks lengkap kami. Oleh karena itu, kami telah memilih untuk menjatuhkan ( DROP FULLTEXT INDEX) dan kemudian membuat kembali ( CREATE FULLTEXT INDEX) pada tingkat indeks teks lengkap individual.

Mungkin lebih ideal untuk memecah indeks teks lengkap ke dalam katalog terpisah dengan cara yang logis dan melakukan REBUILDsebaliknya, tetapi sementara itu solusi drop / create akan bekerja untuk kita.