Механизм полнотекстового поиска (ППД) в платформе 1С:Предприятие — это мощный инструмент, который позволяет пользователям мгновенно находить нужные данные по всей базе. Однако системные администраторы и разработчики часто сталкиваются со странным поведением системы: полнотекстовый поиск отлично работает по всей базе, но наотрез отказывается искать информацию по одному конкретному объекту (например, по справочнику ВнутренниеДокументы в конфигурациях «1С:Документооборот» или «1С:ЭДО»).
В рамках этой статьи мы подробно разберем, почему возникает подобная локальная проблема, проанализируем внутреннее устройство индексации 1С и выработаем пошаговый алгоритм для восстановления корректной работы поиска.
Для начала рассмотрим программный способ проверки работы поиска по конкретному объекту метаданных. Если типовой поиск в интерфейсе не дает результатов, разработчики используют тестовую процедуру для прямого обращения к индексу. Проанализируем пример кода, выполняющего поиск с отбором по области метаданных:
СтрокаПоиска = ПараметрыПроцедуры.СтрокаПоиска + "*";
МассивОтбор = Новый Массив();
МассивОтбор.Добавить(Метаданные.Справочники.ВнутренниеДокументы);
СписокПоиска = ПолнотекстовыйПоиск.СоздатьСписок(СтрокаПоиска, 100);
СписокПоиска.ОбластьПоиска = МассивОтбор;
СписокПоиска.ПорогНечеткости = 0;
СписокПоиска.ПолучатьОписание = Истина;
СписокПоиска.ПерваяЧасть();
ТекущаяПозиция = СписокПоиска.НачальнаяПозиция();
ВсегоНайденоПоиск = СписокПоиска.ПолноеКоличество();
В данном фрагменте мы принудительно ограничиваем область поиска свойством ОбластьПоиска, передавая туда массив с метаданными конкретного справочника. Если этот код возвращает ВсегоНайденоПоиск = 0 при заведомо существующих в базе данных объектах, проблема кроется непосредственно в состоянии полнотекстового индекса или в настройках регистрации изменений.
Прежде чем переходить к радикальным мерам на сервере, исключим стандартные ошибки конфигурирования. Выясним, правильно ли настроено использование поиска в конфигураторе:
ВнутренниеДокументы).Наименование, Содержание, Артикул) и убедимся, что у них свойство Полнотекстовый поиск установлено в значение Использовать.Частой ошибкой администраторов является запуск процедуры «Тестирование и исправление» (ТиИ) с флагом «Реиндексация таблиц информационной базы». Важно понимать: полнотекстовый поиск не хранит свои индексы в основной таблице СУБД. Индекс ППД — это отдельная файловая структура, расположенная на сервере приложений 1С. Следовательно, запуск реиндексации базы данных никак не влияет на работу полнотекстового поиска и не решает проблемы с его сбоями.
В конфигурациях, работающих с присоединенными файлами (таких как «1С:Документооборот» и «1С:ЭДО»), справочник ВнутренниеДокументы тесно связан с хранением файлов различных форматов (PDF, DOCX, XLSX, изображения). Платформа пытается извлечь текстовое содержимое из этих файлов, чтобы проиндексировать их.
Рассмотрим детально, как это может заблокировать поиск:
rphost.Для решения этой проблемы перейдем в регистр сведений Очередь извлечения текста (или воспользуемся типовой обработкой управления извлечением текстов в составе БСП). Найдем проблемные файлы, по которым произошел сбой, и принудительно очистим их из очереди или извлечем текст вручную.
Если стандартный механизм сброса индекса через меню «Все функции -> Управление полнотекстовым поиском -> Очистить индекс» не дает результатов, это свидетельствует о блокировке файлов операционной системой или недостатке прав пользователя USR1CV8 на удаление каталогов.
Выполним жесткую очистку индекса вручную по следующему алгоритму:
1C:Enterprise 8.3 Server Agent).C:\Program Files\1cv8\srvinfo\<Имя_кластера>\<ID_базы>\1Cv8FTxt
1Cv8FTxt.snccntx<ID_базы>, а также временный кэш сервера 1С.Платформа 1С отслеживает изменения в объектах для их последующей индексации с помощью внутренних таблиц регистрации изменений (например, файла tableChanges.dat в файловом варианте или служебных таблиц в клиент-серверном варианте). При аварийных остановках сервера 1С или СУБД (о которых упоминалось в описании проблемы) структура этих таблиц может нарушиться.
Для восстановления целостности выполним проверку базы на уровне СУБД. В среде MS SQL Server выполним следующий запрос в однопользовательском режиме (предварительно создав резервную копию базы данных):
ALTER DATABASE [Имя_Вашей_Базы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
DBCC CHECKDB ('Имя_Вашей_Базы', REPAIR_ALLOW_DATA_LOSS);
GO
ALTER DATABASE [Имя_Вашей_Базы] SET MULTI_USER;
GO
Данная операция исправит логическую структуру базы данных и позволит платформе корректно регистрировать измененные объекты в очереди индексации полнотекстового поиска.
Проанализируем взаимосвязь изменения префикса информационной базы и работы поиска. Напрямую платформа не привязывает индекс ППД к константе префикса. Однако изменение префикса в конфигурациях класса ERP или Документооборот неизбежно запускает фоновые процессы перезаписи документов (например, при перенумерации).
В результате перезаписи сотен тысяч документов в очередь индексации мгновенно падает гигантский объем данных. На устаревших версиях платформы (например, 8.3.10.x) процесс rphost может завершаться аварийно по превышению лимита выделенной оперативной памяти, не успев обработать эту очередь. Внешне это выглядит как отказ поиска, хотя на самом деле сервер просто циклически пытается обработать перегруженную очередь.
Решением здесь служит своевременное обновление платформы до актуальных релизов ветки 8.3.20 и выше, где работа с памятью при индексации ППД существенно оптимизирована.
Если база данных используется в режиме разделения (например, архитектура SaaS или «1С:Fresh»), убедимся, что регламентные задания по обновлению и слиянию полнотекстового поиска настроены с учетом разделителей. Если общее регламентное задание выполняется вне контекста конкретной области данных, объекты метаданных в этой области могут игнорироваться индексатором. Настроим запуск индексации отдельно для каждой области данных.