Как уменьшить размер файловой базы 1С при разбухании регистров ЭДО?

← На главную

Разрастание файловой базы 1С до критических размеров (10 Гб и более) — частая проблема при активном использовании электронного документооборота (ЭДО). Основными «пожирателями» пространства становятся регистры сведений, хранящие транспортную информацию. Проанализируем ситуацию: стандартная настройка «Хранение файлов в томах на диске» зачастую игнорирует эти данные, так как подсистема ЭДО использует собственные механизмы хранения двоичных данных непосредственно внутри таблиц базы данных .1cd.

Рассмотрим подробнее причины этой проблемы и разберем по шагам доступные способы оптимизации объема базы, не теряя при этом юридически значимую информацию.

Причина разбухания: почему тома не помогают?

Выясним причину, по которой стандартный механизм БСП (Библиотеки стандартных подсистем) по выносу файлов в тома не срабатывает для ЭДО. В типовых конфигурациях 1С (Бухгалтерия, ERP, Комплексная автоматизация) файлы документов могут храниться в справочнике Файлы, который легко настраивается на хранение вне базы. Однако данные ЭДО (электронные подписи, квитанции, транспортные пакеты) записываются в специализированные регистры сведений:

СодержимоеТранспортныхКонтейнеров
ТранспортныеКонтейнеры
ВложенияНеформализованныхДокументов
ДвоичныеДанныеФайлов

Эти регистры хранят информацию в ресурсах с типом ХранилищеЗначения. Платформа 1С воспринимает их как часть структуры таблиц базы данных, а не как отдельные присоединенные файлы. Поэтому простая настройка томов их не затрагивает.

Решение 1: Регламентная очистка транспортных контейнеров

Проанализируем состав данных. «Транспортный контейнер» — это своего рода техническая упаковка, необходимая для передачи документа через оператора ЭДО. После того как документ получен, расшифрован и принят к учету, сам контейнер со всей служебной «обвязкой» перестает быть оперативно нужным, хотя и занимает огромный объем. В современных версиях конфигураций предусмотрен штатный механизм очистки.

Перейдем в раздел Администрирование — Обслуживание — Регламентные операции.
Найдем регламентное задание Очистка ненужных транспортных контейнеров.
Настроим срок хранения (например, удалять контейнеры старше 3-6 месяцев).

Важно: Это действие удалит только технический «мусор» из тяжелых регистров. Сами документы (PDF, XML) и файлы электронных подписей останутся в архиве ЭДО и будут доступны для проверок.

Решение 2: Техническое обслуживание и сжатие таблиц

Простое удаление записей из регистров (программно или через регламентное задание) не уменьшает физический размер файла 1cv8.1cd на диске. Платформа просто помечает освободившееся место как «пустое» для будущих записей. Чтобы реально сжать базу, выполним следующие шаги:

Обязательно создадим резервную копию базы.
Запустим конфигуратор и перейдем в Администрирование — Тестирование и исправление.
Установим галочку только на пункте Сжатие таблиц информационной базы.
Для файловых баз также полезно использовать внешнюю утилиту chdbfl.exe (находится в папке bin установленной платформы) с установленной галочкой «Исправлять обнаруженные ошибки».

Посмотрим на результат: после удаления старых контейнеров и последующего сжатия размер базы может сократиться в 2-3 раза.

Решение 3: Переход на клиент-серверный вариант (SQL)

Если объем базы превышает 10 Гб, необходимо помнить о критическом ограничении файлового движка: размер одной таблицы внутри файла .1cd не может превышать 4 Гб. Если регистр СодержимоеТранспортныхКонтейнеров приблизится к этому порогу, база выдаст ошибку записи, даже если свободное место на диске есть.

Рассмотрим вариант перехода на бесплатную СУБД, например PostgreSQL или MS SQL Server Express. Это решит проблему ограничений на размер таблиц и существенно повысит надежность работы с данными ЭДО. Как отмечают специалисты, работа «скульной» базы зачастую стабильнее при больших объемах бинарных данных в регистрах.

Решение 4: Разработка собственного механизма выноса данных

Если переход на SQL невозможен, а данные хранить необходимо, можно реализовать кастомное решение по выносу ресурсов из регистров во внешнее хранилище. Разберем пример логики такой обработки:


// Пример логики переноса данных (псевдокод)
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ Ссылка, Данные ИЗ РегистрСведений.СодержимоеТранспортныхКонтейнеров ГДЕ Дата < &ДатаОтсечения";
Запрос.УстановитьПараметр("ДатаОтсечения", ДобавитьМесяц(ТекущаяДата(), -12));
Выборка = Запрос.Выполнить().Выбрать();

Пока Выборка.Следующий() Цикл
    ПутьКФайлу = "C:\EdoStorage\" + Выборка.Ссылка.УникальныйИдентификатор();
    ДвоичныеДанные = Выборка.Данные.Получить();
    ДвоичныеДанные.Записать(ПутьКФайлу);
    
    // Очистка данных в регистре с сохранением записи (или удаление)
    МенеджерЗаписи = РегистрыСведений.СодержимоеТранспортныхКонтейнеров.СоздатьМенеджерЗаписи();
    // ... установка отбора и очистка ресурса
КонецЦикла;

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

Резюме и рекомендации

Для эффективного решения проблемы «разбухания» базы ЭДО рекомендуем придерживаться следующей стратегии:

Проверьте регламентные задания: включите очистку транспортных контейнеров.
Выполните ТИИ: процедура «Сжатие таблиц» обязательна после массового удаления данных.
Оцените размер конкретных таблиц: если любая из них подходит к 4 Гб, немедленно планируйте переход на SQL.
Рассмотрите 1С:Архив: для крупных внедрений это специализированное решение позволит вынести юридически значимые документы в отдельную базу, оставив рабочую базу «легкой» и быстрой.