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.
