Как уменьшить объём базы 1С 8.3: от выгрузки в DT до свёртки

Файл файловой базы (1Cv8.1CD) сам по себе не уменьшается. Когда вы удаляете документы или помечаете их на удаление, место внутри файла остаётся занятым — поэтому «удалил половину данных, а база весит столько же» — это нормальное поведение, а не сбой. Чтобы реально сжать базу 1С 8.3 и уменьшить размер файла, её нужно физически пересобрать или почистить от накопленного мусора.

Способ зависит от того, как у вас хранится база. Для файлового варианта работают сжатие таблиц и выгрузка в .dt. Для клиент-серверного размер уменьшают средствами СУБД (MS SQL или PostgreSQL), а инструменты Конфигуратора там почти не дают эффекта. Разберём оба пути, а в конце — что делать, когда база большая из-за реального объёма данных и обычное сжатие бесполезно.

Чтобы не держать все способы в голове, вот короткая сводка — какой метод под какую задачу:

С чего начать: резервная копия и монопольный доступ

Любая операция сжатия меняет файл базы целиком. Перед началом сделайте резервную копию: для файловой базы достаточно скопировать папку с файлом 1Cv8.1CD, когда никто не работает ; в клиент-серверном варианте — средствами СУБД.

Выгрузка/загрузка .dt, тестирование и исправление требуют монопольного доступа. Это значит, что в момент операции в базе не должно быть ни одного активного сеанса — иначе 1С не даст начать, а если сеансы оборвать принудительно, незавершённые операции потеряются. Планируйте сжатие на нерабочее время: вечер, выходные или обеденный перерыв.

Сжатие таблиц файловой базы через Конфигуратор

Самый быстрый способ уменьшить размер файловой базы — встроенное сжатие таблиц. Оно убирает пустоты внутри 1Cv8.1CD, которые остались после удалённых данных.

1. Запустите базу в режиме Конфигуратор.
2. Откройте меню Администрирование → Тестирование и исправление.
3. Снимите все галочки проверок и оставьте только Сжатие таблиц информационной базы.
4. В переключателе внизу выберите режим Только исправление (а не «тестирование»).
5. Нажмите Выполнить.

1С пересоберёт таблицы и вернёт свободное место операционной системе. На базе в несколько гигабайт процесс занимает от пары минут до получаса.

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

Выгрузка в DT: полная пересборка файловой базы

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

1. В Конфигураторе откройте Администрирование → Выгрузить информационную базу.
2. Укажите имя файла — например, base.dt — и дождитесь окончания выгрузки.
3. Создайте в списке баз новую пустую файловую базу (или используйте ту же).
4. Откройте её в Конфигураторе и выполните Администрирование → Загрузить информационную базу, указав сохранённый .dt.

После загрузки сравните размер старого и нового файла 1Cv8.1CD — разница бывает в разы, если база давно не обслуживалась.

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

Очистка лишних данных перед сжатием

Любое физическое сжатие только убирает пустоты. Чтобы база похудела по-настоящему, сначала уберите из неё то, что уже не нужно. Эти действия выполняются в режиме 1С:Предприятие.

🗑️ Помеченные на удаление объекты. Пометка на удаление не освобождает место — данные лежат в базе до фактического удаления. Запустите Администрирование → Обслуживание → Удаление помеченных объектов. Программа проверит ссылки и удалит то, на что никто не ссылается.

🕓 Устаревшие версии объектов. Если включено версионирование (история изменений), база хранит все редакции документов и справочников. В разделе настроек истории изменений задайте срок хранения версий и очистите старые — на активно правимых базах это освобождает заметный объём.

🔁 Регистрация изменений для обмена. В базах с обменами данными (РИБ, синхронизация) копится таблица регистрации изменений. Если узел обмена давно не используется, снимите с него регистрацию или удалите неактуальный узел — таблица изменений перестанет расти.

📑 Журнал регистрации. Сам журнал в размер файла базы не входит (он лежит отдельными файлами в каталоге базы), но может занимать гигабайты на диске. Настройте период хранения событий и при необходимости сократите его.

Удаление неиспользуемых объектов конфигурации

Иногда вес набирает не данные, а сама конфигурация — особенно если в неё добавляли внешние подсистемы, печатные формы, обработки, которые давно не нужны. Это касается файла конфигурации (.cf), а не данных.

Разумно убрать:

• неиспользуемые внешние обработки и отчёты, подключённые как встроенные;
• лишние расширения конфигурации , если они больше не применяются;
• справочники и регистры, созданные под завершённые доработки.

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

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

Сжатие клиент-серверной базы на SQL

В клиент-серверном варианте файла 1Cv8.1CD нет — данные лежат в базе СУБД. Поэтому сжимать нужно средствами MS SQL Server или PostgreSQL, а не Конфигуратором.

MS SQL Server. Типичная причина раздувания — журнал транзакций (.ldf), который растёт при полной модели восстановления.

1. Сначала удалите лишние данные в 1С (помеченные объекты, старые версии).
2. Переведите базу в простую модель восстановления (Recovery model: Simple), если полный журнал вам не нужен для частых бэкапов.
3. Выполните сжатие файлов данных и журнала — через SSMS (Tasks → Shrink → Files) или командой DBCC SHRINKFILE.

PostgreSQL. Здесь место освобождает VACUUM. Обычный VACUUM помечает место свободным для повторного использования, но файл на диске не уменьшает. Чтобы вернуть место ОС, нужен VACUUM FULL — но он полностью перезаписывает таблицу и на время работы блокирует её, поэтому запускайте только когда с базой никто не работает.

Регулярные автоматические VACUUM и обслуживание индексов на стороне СУБД снимают проблему раздувания в принципе — настройте их, чтобы не сжимать базу вручную каждые полгода.

Присоединённые файлы и тома хранения на диске

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

Решение — перенести файлы из базы в тома хранения на диске. В типовых конфигурациях на базе Библиотеки стандартных подсистем (Бухгалтерия, ЗУП, Управление торговлей) это настраивается так:

1. В разделе Администрирование найдите настройки работы с файлами.
2. Включите вариант Хранить файлы в томах на диске и укажите каталог тома.
3. Запустите перенос уже накопленных файлов из базы в том (регламентная операция переноса).

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

Когда сжатие не помогает: свёртка и альтернативы

Если база большая не из-за мусора, а из-за реального объёма — несколько лет документов, миллионы записей в регистрах — никакое сжатие таблиц объём не уменьшит. Данные живые, и они занимают место по делу.

Варианты здесь такие:

• Свёртка базы. Специальная обработка формирует остатки на выбранную дату и удаляет документы за прошлые периоды, заменяя их вводом начальных остатков. База резко худеет, но операция рискованная: её делают на копии, тщательно сверяют остатки и только потом переносят результат в работу. Для сложного учёта свёртку часто доверяют специалисту.
• Старт нового периода в чистой базе. Иногда проще начать новый год в свежей базе с перенесёнными остатками и справочниками, а старую оставить как архив для просмотра.
• Переход на клиент-сервер. Если файловая база упёрлась в предел по размеру и скорости, перевод на MS SQL или PostgreSQL снимает ограничения и упрощает обслуживание.
• Апгрейд диска. Иногда дешевле добавить места и перевести базу на SSD, чем бороться за каждый гигабайт.

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