Как сжать базу 1С и уменьшить её размер

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

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

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

Почему база 1С растёт и когда нужно сжатие

Файл базы 1С устроен как контейнер таблиц. Когда вы удаляете документ или элемент справочника, запись помечается как удалённая, но место на диске не возвращается — оно будет переиспользовано под новые данные. Если объём удалений велик (например, свёртка базы, массовая очистка старых периодов), внутри файла образуется много «пустот».

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

Подготовка: резервная копия и условия запуска

Перед любой операцией сжатия сделайте полную резервную копию. Для файловой базы достаточно скопировать файл 1Cv8.1CD при остановленной работе пользователей или выгрузить базу через конфигуратор («Администрирование → Выгрузить информационную базу»). Для клиент-серверной базы используйте штатные средства СУБД — backup в MS SQL или pg_dump в PostgreSQL.

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

Убедитесь, что на диске достаточно свободного места: в процессе сжатия платформа фактически создаёт новую копию таблиц, поэтому потребуется пространство, сопоставимое с размером самой базы. Для больших баз ориентируйтесь на запас не менее 50–100 % от текущего размера файла.

Сжатие файловой базы через «Тестирование и исправление»

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

1. 1
   Создайте резервную копию файла 1Cv8.1CD или выгрузку .dt
2. 2
   Завершите сеансы всех пользователей и фоновые задания
3. 3
   Откройте базу в конфигураторе
4. 4
   Перейдите: Администрирование → Тестирование и исправление
5. 5
   Отметьте пункты «Реиндексация таблиц» и «Сжатие таблиц информационной базы»
6. 6
   Выберите режим «Тестирование и исправление» и нажмите «Выполнить»
7. 7
   Дождитесь окончания и проверьте размер файла и работу базы

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

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

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

В клиент-серверном варианте «Тестирование и исправление» со сжатием таблиц в конфигураторе для SQL-баз не выполняет физическое уменьшение файлов СУБД — оно полезно в основном для реиндексации и проверки. Реальное освобождение места делается средствами самой СУБД.

Сжатие в MS SQL Server

В MS SQL используется операция SHRINKDATABASE или SHRINKFILE через SQL Server Management Studio. Перед сжатием проверьте модель восстановления базы: если журнал транзакций разросся, переведите базу в модель Simple, сделайте backup, выполните сжатие журнала, затем при необходимости верните Full и сразу создайте полную резервную копию.

DBCC SHRINKDATABASE (N'MyBase', 10);
GO
-- либо точечно по файлам:
DBCC SHRINKFILE (N'MyBase_Log', 1024);
GO

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

Очистка в PostgreSQL

В PostgreSQL аналогом служит команда VACUUM FULL, которая перезаписывает таблицы и возвращает место операционной системе. Обычный VACUUM место не возвращает, а только помечает его свободным для переиспользования. VACUUM FULL требует блокировки таблицы и свободного места на диске, поэтому выполняется в окне обслуживания.

VACUUM FULL;
-- или для отдельной таблицы:
VACUUM FULL tablename;

Уменьшение базы за счёт очистки данных

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

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

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

Проверка результата и типичные ошибки

После завершения процедуры сравните размер файла базы до и после. Для файловой базы достаточно посмотреть размер 1Cv8.1CD в проводнике, для SQL-баз — размер файлов данных и журнала в свойствах базы в Management Studio или через системные представления.

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

Как часто сжимать базу и чем заменить процедуру

Регулярное сжатие «по расписанию» не требуется. Оно оправдано после событий, освобождающих много места: свёртка базы, удаление старых периодов, массовая чистка версий и истории, перенос файлов из базы в тома. В остальное время платформа и СУБД сами переиспользуют свободное место внутри файлов.

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

Часто задаваемые вопросы