Мені не вдалося знайти жодних хороших ресурсів в Інтернеті, тому я зробив ще кілька практичних досліджень і подумав, що було б корисно опублікувати отриманий повнотекстовий план обслуговування, який ми реалізуємо на основі цього дослідження.
Наш евристичний, щоб визначити, коли потрібне технічне обслуговування
Наша основна мета - зберегти послідовну повнотекстову роботу запитів, оскільки дані розвиваються в нижчих таблицях. Однак з різних причин нам буде важко запускати репрезентативний набір повнотекстових запитів проти кожної з наших баз даних щовечора та використовувати ефективність цих запитів, щоб визначити, коли потрібне обслуговування. Тому ми шукали, щоб створити великі правила, які можна швидко обчислити і використовувати як евристику, щоб вказати, що підтримка повнотекстового індексу може бути гарантованою.
У ході цього дослідження ми з’ясували, що системний каталог надає багато інформації про те, як будь-який заданий повнотекстовий індекс поділений на фрагменти. Однак не існує офіційного обчисленого "фрагментарного%" (як це існує для b-tree індексів через sys.dm_db_index_physical_stats ). Виходячи з повнотекстової інформації про фрагменти, ми вирішили обчислити власну "повнотекстову фрагментацію%". Потім ми використовували сервер розробників, щоб неодноразово робити випадкові оновлення від 100 до 25000 рядків одночасно, щоб копіювати виробничі дані на 10 мільйонів рядків, записати повнотекстову фрагментацію та виконати повнотекстовий запит еталону CONTAINSTABLE.
Результати, як видно з діаграм вище та нижче, були дуже яскравими, і показали, що створений нами захід фрагментації дуже сильно корелює зі спостережуваними показниками. Оскільки це також пов'язане з нашими якісними спостереженнями у виробництві, цього достатньо, щоб нам було зручно використовувати фрагментацію% як наш евристичний для вирішення того, коли наші повнотекстові індекси потребують обслуговування.
План технічного обслуговування
Ми вирішили використовувати наступний код для обчислення фрагментації% для кожного повнотекстового індексу. Будь-які повнотекстові покажчики нетривіальної величини з фрагментацією не менше 10% будуть позначені для того, щоб вони були відтворені за допомогою нашого нічного обслуговування.
-- 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
Ці запити дають такі результати, як наступні, і в цьому випадку рядки 1, 6 і 9 будуть позначені як занадто фрагментовані для оптимальної продуктивності, оскільки повнотекстовий індекс перевищує 1 МБ і принаймні 10% фрагментований.
Каденція технічного обслуговування
У нас вже є вікно нічного обслуговування, і обчислення фрагментації дуже дешево обчислити. Таким чином, ми будемо проводити цю перевірку щовечора, а потім лише виконувати дорожчу операцію фактично перебудувати повнотекстовий покажчик, коли це необхідно, виходячи з 10% -ного порогу фрагментації.
ПОВЕРНУТИСЯ проти РЕОРГАНІЗАЦІЇ ДРОП / СТВОРИТИ
SQL Server пропонує REBUILDта REORGANIZEваріанти, але вони доступні лише для повнотекстового каталогу (який може містити будь-яку кількість повнотекстових покажчиків) у повному обсязі. З застарілих причин ми маємо єдиний повнотекстовий каталог, який містить усі наші повнотекстові покажчики. Тому ми вирішили "drop" ( DROP FULLTEXT INDEX), а потім знову створити ( CREATE FULLTEXT INDEX) на індивідуальному повнотекстовому рівні індексу.
Можливо, було б більш ідеально розбити повнотекстові індекси на окремі каталоги логічно і REBUILDзамість цього виконати , але рішення "drop / create" тим часом буде працювати для нас.
