← На главную

Рассмотрим распространенную проблему, с которой сталкиваются системные администраторы и разработчики при эксплуатации файловых информационных баз 1С большого объема. Типичные симптомы выглядят следующим образом: в конце рабочей недели при попытке записать или провести некоторые документы происходит аварийное завершение работы программы. После выполнения процедуры Тестирование и исправление информационной базы (ТИИ) работа восстанавливается, однако утилита выявляет неразрешимые ссылки и заменяет их на NULL (или объекты вида «Объект не найден»), а спустя несколько дней сбой повторяется снова.

Выясним причины регулярного повреждения базы данных

Проанализируем архитектурные особенности работы 1С в файловом режиме, чтобы понять, почему возникают сбои:

1. Гибридный сетевой доступ (работа через общую папку по SMB). Потенциально самая частая причина повреждения файла 1Cv8.1CD. Если часть пользователей работает в сеансах терминального сервера (RDP), а часть подключена напрямую по локальной сети через общую папку, то при минимальном кратковременном обрыве связи у «сетевых» пользователей происходит аварийный разрыв транзакции. Файловые блокировки Windows не успевают корректно снять захват таблицы, в результате чего индексы и структуры ссылочной целостности базы данных разрушаются. Даже одного компьютера с нестабильным сетевым адаптером или WiFi-подключением достаточно, чтобы повредить всю базу.
2. Превышение предельных объемов файлового формата. Файловая база размером 14 Гб приближается к критическим пределам файлового движка. В платформе 8.2 размер любой отдельной внутренней таблицы и её индексов ограничен 4 Гб. При интенсивном формировании документов таблицы итогов, движений регистров или журнала документов начинают достигать этого порога. В момент записи очередного документа платформа пытается пересчитать итоги, упирается в лимит и экстренно завершает сеанс.
3. Сильная фрагментация файла базы данных. Постоянные перезаписи, удаление объектов и активная работа пользователей приводят к фрагментации физических страниц файла 1Cv8.1CD. При высокой нагрузке считывание адресов данных может давать сбои.

Диагностика и поиск источника сбоев

Прежде чем принимать кардинальные меры, разберем по шагам, как точно диагностировать причину экстренного завершения сеансов:

1. Анализ системных журналов Windows. На стороне терминального сервера и локальных ПК пользователей необходимо проверить журналы событий Windows (Приложение / Application и Система / System) на момент вылета программы. Обратите внимание на ошибки с кодами аварийного завершения процессов и события сетевых адаптеров.
2. Включение технологического журнала 1С. Настройка технологического журнала позволяет зафиксировать точное исключение, которое происходит перед падением сеанса. Это дает возможность узнать, какая именно таблица или операция вызывают сбой.
3. Проверка физической целостности файла базы. Выполним проверку файла базы утилитой chdbfl.exe, которая находится в каталоге bin установленной платформы. В отличие от штатного ТИИ в Конфигураторе, данный инструмент проверяет физическую структуру страниц файла 1Cv8.1CD без запуска самой платформы.

Шаги по окончательному устранению проблемы

Рассмотрим подробнее эффективные варианты решения данной ситуации от наиболее простых к кардинальным.

Вариант 1. Перевод всех пользователей в терминальный режим (RDP)

Самый быстрый и эффективный способ защитить файловую базу от повреждений без покупки дорогостоящих лицензий — полностью исключить работу по сетевым файловым протоколам.

1. Подключите абсолютно всех пользователей (включая тех 2–3 человек, которые работали через локальную сеть) к терминальному серверу.
2. Убедитесь, что все сеансы запускаются локально на сервере, где физически расположен файл 1Cv8.1CD.
3. Исключите использование беспроводных сетей (Wi-Fi) для рабочих мест, работающих с базой, а сервер и сетевое оборудование подключите к источникам бесперебойного питания (ИБП).

Вариант 2. Оптимизация и дефрагментация файла информационной базы

Для сокращения физического размера файла и восстановления структуры индексов выполним следующие процедуры:

1. Выполните выгрузку информационной базы в файл сжатого дампа .dt через меню «Администрирование» — «Выгрузить информационную базу».
2. Создайте новую пустую папку и загрузите выгруженный файл обратно через «Загрузить информационную базу». Это полностью перестраивает таблицы, удаляет неиспользуемые страницы и существенно уменьшает итоговый размер файла на диске.
3. Настройте регулярный пересчет итогов регистров накопления и сведений в Конфигураторе для уменьшения объема временных таблиц.

Вариант 3. Переход на клиент-серверный вариант работы (СУБД)

При размере базы свыше 10–12 Гб и числе пользователей более 10 человек файловый режим становится нестабильным по своей природе. Наиболее надежным решением является переход на клиент-серверную архитектуру:

1. Установите сервер 1С:Предприятие и СУБД (например, PostgreSQL или MS SQL Server).
2. Перенесите информационную базу в СУБД. В клиент-серверном режиме обрывы связи пользователей не приводят к повреждению физической структуры базы данных, так как транзакциями управляет полноценная СУБД, а ограничения файлового формата полностью снимаются.