Проблема медленной работы отборов в журналах документов 1С:Предприятие 7.7 на файловых базах (DBF) — это классическая техническая сложность, с которой сталкиваются администраторы и разработчики при росте объема данных. Особенно остро она проявляется, когда документы, попадающие под критерий отбора, расположены в базе «вразнобой» (с большим временным разрывом). Рассмотрим причины этого явления и разберем по шагам методы оптимизации системы.
Проанализируем ситуацию, когда документы, идущие подряд, отображаются быстро, а разбросанные по времени — медленно. Это связано с тем, как движок базы данных (CodeBase) и операционная система взаимодействуют с дисковой подсистемой. Когда записи расположены последовательно, система использует упреждающее чтение (read-ahead caching). Данные попадают в кэш большими блоками, и следующая запись уже находится в оперативной памяти.
Если же документы разбросаны, происходит множество операций произвольного поиска (Random I/O). Каждая запись требует обращения к разным участкам индексного файла .CDX и основного файла .DBF. Это приводит к постоянному сбросу и обновлению кэша файловой системы, что визуально воспринимается как «дикие тормоза» интерфейса.
Выясним важный нюанс: даже если все пользователи работают в терминальном режиме, само наличие открытого общего доступа (сетевой папки) к базе данных может замедлять работу. Рассмотрим критический фактор: если хотя бы одна сессия 1С 7.7 открыта «по сети» через общую папку, а остальные — в терминале, сервер переключает режим работы с файлами. Механизмы кэширования Windows становятся гораздо менее агрессивными, чтобы обеспечить целостность данных для сетевого клиента.
Что необходимо сделать:
Со временем индексные файлы .CDX могут фрагментироваться или содержать устаревшую структуру после изменений в конфигурации. Разберем процедуру «оздоровления» индексов. Рекомендуется не просто запускать «Переиндексацию» из конфигуратора, а выполнить полную очистку.
Алгоритм действий:
.CDX из каталога информационной базы.Это гарантирует создание максимально компактных и эффективных индексов «с нуля».
Часто проблема кроется не в самом механизме отбора, а в том, что отображается в журнале. Проанализируем содержимое граф журнала. Если в журнале присутствуют колонки, в поле «Формула» которых стоит вызов функции, 1С будет выполнять эту функцию для каждой строки, попавшей в отбор.
Когда мы прокручиваем «рваный» список, нагрузка на процессор и диск возрастает многократно. Посмотрим на пример: если функция гпПолучитьОстаток(ТекущийДокумент) обращается к регистрам, то при отборе по 100 документам, раскиданным по всей базе, система выполнит 100 сложных запросов к итогам регистров. Рекомендация: минимизируйте количество вычисляемых граф в журналах, по которым планируется делать частые отборы.
Если база лежит на Windows Server, необходимо настроить параметры сетевого взаимодействия и безопасности, которые напрямую влияют на производительность DBF-движка:
.DBF, .CDX, .MD и .TMP в папке с базой. Иначе при каждом обращении к индексу антивирус будет перехватывать поток данных для проверки.Если штатные средства УстановитьОтбор() не справляются, рассмотрим использование библиотеки 1С++. Она позволяет строить журналы на основе «прямых запросов» к DBF-файлам или использовать объект ИндексированнаяТаблица.
При использовании 1С++ и класса ТабличноеПоле отбор происходит практически мгновенно, так как данные извлекаются напрямую, минуя штатный тяжеловесный механизм отрисовки журналов 1С. Это требует доработки конфигурации, но полностью снимает проблему скорости.
Пример логики прямого обращения к данным (условно):
// Пример использования 1С++ для быстрого получения списка ID документов
ТекстЗапроса = "
|SELECT ID as [Док $Документ]
|FROM _1SJOURN (NOLOCK)
|WHERE IDDOCDEFS = :ВидДока AND $ОбщийРеквизит = :ЗначениеОтбора
|";
Запрос = СоздатьОбъект("ПоставщикДанных");
// Результат выводится в ТабличноеПоле на форме
.CDX файлы вручную.Соблюдение этих правил позволяет комфортно работать с базами 1С 7.7 объемом в несколько гигабайт даже при интенсивном использовании отборов.