MS-SQL Server 2000 медленная полнотекстовая индексация - PullRequest
3 голосов
/ 01 июня 2009

У нас есть полнотекстовый индекс на довольно большой таблице из 633 569 записей. Индекс перестраивается с нуля как часть плана обслуживания каждый вечер после запуска нескольких пакетов DTS, которые удаляют / вставляют записи. Большие куски данных удаляются, а затем вставляются (чтобы заботиться об обновлениях и вставках), поэтому добавочная индексация невозможна. Изменение пакетов для удаления только при необходимости также невозможно, поскольку это устаревшее приложение, которое в конечном итоге будет заменено.

FTI включает в себя две колонки - одну varchar (50) не нуль и varchar (255) ноль.

В столбце первичного ключа есть кластерный индекс, который является просто столбцом идентификаторов. Существует также комбинированный индекс для целочисленного столбца и столбца varchar (50), упомянутого выше. Этот последний индекс был добавлен по соображениям производительности.

Проблема в том, что переиндексация мучительно медленная - около 8 часов.

Сервер достаточно надежный (двухпроцессорный, 4 ГБ ОЗУ), и все быстро выходит за рамки этой переиндексации.

Любые советы о том, как ускорить это?

UPDATE

Наш клиент имеет доступ к коробке sql. Оказывается, они включили отслеживание изменений в таблице, которая является частью полнотекстового индекса. Мы выключили это, и полное население заняло меньше чем 3 часа. Все еще не отлично, но лучше, чем 8.

ОБНОВЛЕНИЕ 2

FTI снова занимает ~ 8 часов для заполнения.

Ответы [ 7 ]

3 голосов
/ 26 июня 2009

Индексирование SQL Server происходит медленно, в основном из-за его асинхронной схемы извлечения данных.

  • Используйте отслеживание изменений с "обновлением Индекс в фоновом режиме "вариант.

Самый простой способ повысить производительность полнотекстовой индексации - это использовать отслеживание изменений с опцией «обновить индекс в фоновом режиме». Когда вы индексируете таблицу (FTI, как и «стандартные» индексы SQL, работает на таблица), вы указываете полное население, добавочное население или отслеживание изменений. Когда вы выбираете полное заполнение, каждая строка в таблице, для которой выполняется полнотекстовое индексирование, извлекается и индексируется. Это двухступенчатый процесс.

Сначала вы (или Enterprise Manager) запускаете эту системную хранимую процедуру:

sp_fulltext_getdata CatalogID, object_id

После того, как все наборы результатов всех временных меток и значений PK будут возвращены в MSSearch, MSSearch выдаст еще одну процедуру sp_fulltext_getdata, но на этот раз один раз для каждой строки в вашей таблице. Так что, если в вашей базе данных есть 50 миллионов строк, эта процедура будет выдана 50 миллионов раз.

С другой стороны, если вы используете добавочную совокупность, MSSearch выдаст начальную букву:

sp_fulltext_getdata CatalogID, object_id

для каждой строки в таблице, для которой выполняется полнотекстовое индексирование. Таким образом, если у вас есть 50 миллионов строк в вашей базе данных, этот оператор также будет выполнен 50 миллионов раз. Зачем? Поскольку даже при добавочной совокупности MSSearch должен точно определить, какие строки были изменены, обновлены и удалены. Другая проблема с добавочными группами заключается в том, что они будут индексировать или переиндексировать строку, даже если было внесено изменение в столбец, для которого вы не выполняете полнотекстовую индексацию.

Хотя добавочная совокупность, как правило, быстрее, чем полная совокупность, вы можете заметить, что для больших таблиц любая из них отнимает много времени.

Я рекомендую вам включить отслеживание изменений с фоновым или запланированным обновлением. Если вы это сделаете, вы увидите, что MSSearch сначала выдаст другое:

sp_fulltext_getdata CatalogID, object_id

для каждой строки в таблице с включенным отслеживанием изменений. Затем для каждой строки, в которой есть столбец, для которого выполняется полнотекстовое индексирование и который был изменен после первоначального полного заполнения, информация о строке будет записана (в базе данных Вы индексируете) в таблицу sysfulltextnotify. Затем MSSearch выдаст следующее только для строк, которые появляются в этой таблице, и затем удалит их из таблицы sysfulltextnotify.

  • Рассмотрите возможность использования отдельной сборки Сервер

Таблицы, которые сильно обновляются во время индексирования, могут создавать проблемы с блокировкой, поэтому, если вы можете использовать каталог, который периодически устарел, и механизм MSSearch, который иногда недоступен, рассмотрите возможность использования отдельного сервера сборки. Это можно сделать, убедившись, что на сервере индексирования есть копия таблицы для полнотекстовой индексации, и экспортируйте каталог. Понятно, если вам нужны обновления каталога в реальном времени или почти в реальном времени, это не очень хорошее решение.

  • Ограничить активность, когда население работает

Когда выполняется заполнение, не запускайте Profiler и максимально ограничивайте другие действия с базой данных. Профилировщик потребляет значительные ресурсы.

  • Увеличить количество тем для процесс индексации

Увеличьте количество потоков, которые вы запускаете для процесса индексации. По умолчанию используется только пять, а на четырех или восьми направлениях вы можете увеличить это значение до гораздо более высоких значений. Однако MSSearch будет ограничивать себя, если отбирает слишком много данных из SQL Server, поэтому избегайте этого в однопроцессорных или двухпроцессорных системах.

  • Остановите любой антивирус или откройте ПО для резервного копирования файлового агента.

Если это невозможно, попробуйте запретить им проверять временные каталоги, используемые SQL FTI и каталогами каталогов

  • Разместите каталог, временный каталог и файлы подкачки на собственных контроллерах

Если вы можете сделать эти инвестиции. Поместите каталог на свой собственный контроллер, предпочтительно в массив RAID-1. Поместите временный каталог в массив RAID-1. Аналогично, рассмотрите возможность размещения файла подкачки в своем собственном массиве RAID-1 с собственным контроллером.

  • Рассмотрите возможность создания вторичных данных файлы для временной базы данных - 1 на процессор / Ядро.
1 голос
/ 01 июня 2009
  • Достаточно ли у вас оперативной памяти?

  • Каковы ваши места размещения файловых дисков с точки зрения конфигурации RAID?

  • Вы видите высокую активность tempDB?

(Кстати, полмиллиона записей не велико; даже не средних ...;))

0 голосов
/ 06 мая 2012

Улучшение производительности полнотекстовых индексов: http://msdn.microsoft.com/en-us/library/ms142560.aspx

0 голосов
/ 25 июня 2009

Вот контрольный список параметров для производительности индексирования FT на SQL Server . Большинство из них уже процитированы и проверены здесь. Я не нашел ни одного из них в ваших комментариях:

Параметр ПАМЯТЬ СЕРВЕРА SQL Server MAX должен быть установлен вручную (динамическое выделение памяти отключено), чтобы оставалось достаточно виртуальной памяти для запуска службы полнотекстового поиска. Для этого выберите параметр MAX SERVER MEMORY, который после установки оставляет достаточно виртуальной памяти, чтобы служба полнотекстового поиска могла получить доступ к количеству виртуальной памяти, равному 1,5-кратному объему физической памяти на сервере. Для достижения этой настройки потребуется некоторое количество проб и ошибок.

0 голосов
/ 19 июня 2009

Запрещение пустых значений в столбце, которое в данный момент не может ускорить индекс, но, по моему опыту, это лучшая практика, особенно для целей индексации. Единственные столбцы, которые я могу обосновать разрешением пустых значений, это столбцы даты.

0 голосов
/ 01 июня 2009

Является ли система автономной, пока вы выполняете переиндексацию или живете?

Это единственные элементы в вашем полнотекстовом каталоге; если нет, то вы можете рассмотреть возможность отделения их от остальной части ваших данных FTS. (Может также помочь с мониторингом) В индексе столбец идентификации настроен как уникальный ключ?

Можете ли вы подсчитать большое количество изменений? Есть 3 основных варианта для повторного заселения; Возможно, вы захотите попробовать перейти на полный или инкрементный, так как он может подойти вам лучше, чем тот, который вы используете сейчас. По моему опыту, инкрементная работа работает хорошо, если изменения в общей базе данных составляют менее 40% (имелась аналогичная проблема при переносе больших объемов данных в базу данных). Если изменение> 40%, то заполнение скорее всего лучше (из моего опыта - я индексирую документы так что он может работать по-другому для вас) Третий вариант, который вы можете рассмотреть, попробуйте вариант отслеживания изменений с запланированным обновлением переиндексации.

Если вы можете перевести сервер в автономный режим для пользователей, то при каких настройках производительности у вас работает FTS во время переиндексации? Вы можете проверить эту вкладку Свойства / Производительность службы полнотекстового поиска - Использование системных ресурсов как слайдер (представьте, что есть 4 или 5 позиций). Вероятно, есть системный процесс, чтобы изменить это, не знаю, и у меня нет машины 2000, чтобы проверить больше.

FTS / Reindexing любит баранов и многое из этого; Общее правило: виртуальная память в 3 раза больше физической памяти; если у вас есть несколько физических дисков, то создайте несколько файлов Pagefile.sys, чтобы каждый файл Pagefile.sys был помещен на его собственный физический диск. Вы на NT или Windows 2000? убедитесь, что расширенная память более 2 ГБ действительно настроена правильно.

0 голосов
/ 01 июня 2009

Попробуйте поместить индекс на отдельный физический диск, чем база данных.

РЕДАКТИРОВАТЬ: Скотт сообщает, что это уже так.

...