Файл базы 1С разросся: чем и как его сократить

Быстро освободить место помогает чистка кэша, а вот сам файл 1Cv8.1CD физически сжимается только двумя инструментами: утилитой chdbfl.exe и операцией «Сжатие таблиц информационной базы» в режиме тестирования и исправления. Всё остальное — удаление данных , свёртка, вынос файлов в тома — лишь готовит почву: без финального сжатия освободившееся место внутри файла остаётся «дырами», и размер базы 1С на диске не падает.

Поэтому логика работы такая: сначала понять, что именно разрослось, затем убрать лишнее, и только потом ужать файл. Для серверной базы на SQL последовательность другая — там размер уменьшается на стороне СУБД. Ниже разберём оба случая.

Сначала найдите, что именно раздувает базу

Прежде чем что-то сжимать, посмотрите на структуру каталога. У файловой базы объём съедают три вещи: сам 1Cv8.1CD (данные), папка 1Cv8Log (журнал регистрации) и присоединённые файлы, если они хранятся внутри базы, а не на диске.

Откройте папку информационной базы (путь виден в окне запуска 1С — кнопка Изменить, поле Каталог информационной базы) и отсортируйте файлы по размеру. Это сразу покажет, с чего начинать.

• 📦 1Cv8.1CD на несколько гигабайт — скорее всего, накопились документы за годы или много присоединённых файлов внутри базы.
• 📝 1Cv8Log крупнее, чем сами данные — вышел из-под контроля журнал регистрации.
• 🗂️ Много тяжёлых файлов рядом с базой — вложения уже вынесены в тома, тогда базу трогать смысла меньше.

Очистка кэша — первое, что освобождает место

Кэш 1С — это временные файлы в профиле пользователя: скомпилированные формы, настройки, служебные данные сеанса. Они накапливаются и иногда занимают сотни мегабайт, при этом никак не относятся к самим данным учёта.

Кэш лежит в двух каталогах профиля (закройте 1С перед удалением):

%LocalAppData%\1C\1cv8\
%AppData%\1C\1cv8\

Внутри — подпапки с длинными именами из букв и цифр (хэши баз). Их можно удалить целиком: при следующем запуске 1С пересоздаст нужное. Учётные данные при этом не теряются — кэш не содержит документов.

То же самое делает запуск с параметром /ClearCache в командной строке 1cv8.exe. Но ручное удаление папок надёжнее: оно заодно решает и мелкие сбои интерфейса — «слетевшие» формы, зависшие настройки списков.

Сжатие файла: chdbfl и тестирование-исправление

Когда вы удалили часть данных, место внутри 1Cv8.1CD помечается как свободное, но файл на диске не уменьшается. Вернуть это пространство операционной системе можно двумя способами.

Утилита chdbfl.exe лежит в каталоге bin установленной платформы (например, C:\Program Files\1cv8\<номер версии>\bin). Запускается при закрытой базе.

1. Укажите путь к файлу 1Cv8.1CD.
2. Поставьте флажок Исправлять обнаруженные ошибки.
3. Нажмите Выполнить.

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

«Сжатие таблиц информационной базы» — альтернатива из Конфигуратора: Администрирование → Тестирование и исправление. В окне нужно снять лишние галочки и оставить только Сжатие таблиц информационной базы (режим «Только тестирование» для сжатия не подходит — выберите исправление).

Обе операции требуют монопольного доступа к базе: все пользователи должны выйти. Для серверной базы монополию выставляют через параметр блокировки начала сеансов. Планируйте работу на нерабочее время — во время сжатия базой пользоваться нельзя.

Есть и третий приём, который часто дают недооценку: выгрузка и загрузка через .dt. Выгрузите базу (Администрирование → Выгрузить информационную базу), создайте пустую файловую базу и загрузите .dt в неё (Загрузить информационную базу). Платформа пересоберёт все таблицы с нуля — итоговый 1Cv8.1CD получается дефрагментированным и нередко меньше, чем после chdbfl. Минус — на большой базе выгрузка-загрузка идёт дольше сжатия, зато попутно вы получаете проверенную резервную копию в виде .dt.

Отдельно стоит пересчитать итоги регистров — форма «Управление итогами» (проще всего открыть через Все функции по названию). Устаревшие и избыточные итоги тоже занимают место, а их пересчёт иногда ощутимо чистит таблицы регистров накопления и бухгалтерии.

Удаление старых данных и свёртка базы

Если база выросла за годы учёта, одним сжатием объём не отыграть — сначала надо убрать сами данные.

Удаление помеченных объектов. Документы и элементы справочников, помеченные на удаление, физически остаются в базе и занимают место. В типовых конфигурациях (БП 3.0, ЗУП 3.1, УТ 11) их чистят через Администрирование → Удаление помеченных объектов. Программа проверит ссылки и удалит то, на что никто не ссылается.

Свёртка информационной базы — более радикальный путь для давно работающих баз. Обработка сворачивает документы до выбранной даты: формирует остатки на начало периода отдельными документами ввода остатков, а старые документы помечает на удаление. После свёртки и удаления база заметно худеет.

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

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

Журнал регистрации: как не дать ему разрастись

Журнал регистрации пишет, кто и что делал в базе. На активной базе он пухнет быстрее самих данных — папка 1Cv8Log на гигабайты не редкость.

Настройки — в Конфигураторе: Администрирование → Настройка журнала регистрации. Здесь можно:

• 🔧 снизить уровень детализации — писать только ошибки и предупреждения вместо всех событий (поле выбора регистрируемых событий);
• 📅 включить разделение хранения по периодам (день/неделя/месяц) — тогда старые куски легко удалять;
• 🧹 удалить записи за период старше нужного прямо из этого окна.

Для файловой базы современная платформа хранит журнал в файле формата SQLite (.lgd). Чистка через настройку журнала — штатный и безопасный способ; руками файлы журнала удалять не стоит, пока база открыта.

Разумный компромисс: хранить журнал за последние 2–3 месяца и писать не каждое открытие формы, а значимые события. Этого хватает для разбора инцидентов и не раздувает базу.

Вложения — в тома на диске, а не внутрь базы

Сканы договоров, акты, картинки товаров — если их хранить внутри базы, она растёт на объём всех файлов. Решение: перенести присоединённые файлы в тома хранения на диске. В базе останутся только ссылки, а сами файлы лягут в обычные папки файловой системы.

В типовых конфигурациях на БСП это настраивается в разделе Администрирование в группе настроек работы с файлами. Нужно:

1. Включить хранение файлов в томах на диске.
2. Создать том и указать путь к папке (лучше на отдельном диске с запасом места).
3. Запустить перенос уже накопленных файлов из базы в том — обработкой переноса, которая идёт в комплекте.

После переноса файлов в тома освободившееся место внутри базы снова нужно вернуть сжатием.

Чистка конфигурации от лишних объектов

Размер базы складывается не только из данных, но и из самой конфигурации. Если база снята с поддержки и дорабатывалась, в ней могли накопиться неиспользуемые объекты: брошенные обработки, отчёты, подсистемы, роли.

Убрать их можно в Конфигураторе вручную, через Конфигурация → Открыть конфигурацию, с проверкой поиска ссылок на объект перед удалением. Эффект на размер файла обычно скромный — доли процента против гигабайтов данных, — но чистка упрощает последующие обновления и уменьшает конфигурацию в выгрузке.

Это не массовый способ уменьшить базу, а скорее гигиена для сильно переделанных внедрений. Основной объём всё равно сидит в данных и журнале, а не в метаданных.

Когда файловой базы мало: переход на SQL

Файловый вариант удобен, но у него есть практический потолок. Когда 1Cv8.1CD разрастается до нескольких гигабайтов и с базой работают несколько человек, начинаются тормоза, долгие проведения и риск повреждения файла. Дальше сжимать уже не главная задача — пора на клиент-серверный вариант с PostgreSQL или MS SQL Server.

После перевода базы на СУБД размер уменьшают уже средствами сервера баз данных:

• MS SQL. Основной «пожиратель» места — журнал транзакций (.ldf), который под моделью восстановления FULL растёт без резервного копирования. Переведите базу в модель SIMPLE или настройте регулярный бэкап журнала, затем при необходимости ужмите файл командой DBCC SHRINKFILE. Саму базу данных (.mdf) постоянно сжимать не нужно — это вредит производительности.
• PostgreSQL. Работает автоочистка (autovacuum); при сильном раздувании таблиц помогает VACUUM FULL, но он блокирует таблицу, поэтому — только в технологическое окно.

Сам перенос делается через знакомую пару .dt: выгружаете файловую базу, создаёте на сервере 1С новую базу с указанием сервера СУБД и загружаете в неё выгрузку. Данные и настройки переезжают целиком, а дальше размером управляет уже СУБД.

Перевод на SQL сам по себе часто решает вопрос «файл слишком большой»: ограничения файлового формата снимаются, место распределяется между .mdf и .ldf (у MS SQL) разумнее, а тяжёлые операции перестают упираться в один файл. Свёртку и чистку журнала на серверной базе тоже делают — принцип тот же, меняется только способ вернуть освободившееся место диску.

Частые вопросы