Как уменьшить вес базы 1С: пошаговая инструкция

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

Прежде чем что-то удалять, важно понять, из чего складывается объём. В файловой базе это один файл 1Cv8.1CD, внутри которого лежат и данные, и индексы. В клиент-серверном варианте объём распределён между таблицами MS SQL или PostgreSQL, журналом транзакций и временными файлами. Методы сжатия для этих вариантов различаются, и применять их нужно в правильной последовательности.

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

Определяем, что занимает место в базе

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

В клиент-серверном варианте размер таблиц смотрят средствами СУБД. В MS SQL Server это отчёт «Disk Usage by Table» в Management Studio, в PostgreSQL — запросы к системным представлениям pg_total_relation_size. Сопоставить имена таблиц СУБД с объектами метаданных помогает функция «ПолучитьСтруктуруХраненияБазыДанных()» в конфигураторе.

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

Сокращаем журнал регистрации

Журнал регистрации — один из главных потребителей места, особенно если включена регистрация всех событий, включая доступ к данным. Файлы журнала в файловой базе хранятся в подкаталоге 1Cv8Log рядом с базой, в серверной — в служебном каталоге кластера или в самой базе в зависимости от режима.

Для сокращения откройте конфигуратор, пункт «Администрирование → Настройка журнала регистрации». Нажмите «Сократить» и укажите дату, до которой удалить события, обязательно выбрав сохранение старой части в отдельный файл — так вы не потеряете историю окончательно. Затем в том же диалоге снизьте уровень регистрации: отключите события «Доступ к данным» и «Отказ в доступе», если они не требуются политикой безопасности.

После сокращения журнала в файловой базе место внутри 1Cv8.1CD само не освободится — потребуется дефрагментация (об этом ниже). В серверной базе журнал хранится отдельно, поэтому эффект виден сразу.

Удаляем помеченные объекты и чистим служебные данные

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

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

Версионирование объектов

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

Свёртка базы: убираем старые периоды

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

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

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

1. 1
   Создайте полную резервную копию базы и убедитесь, что она восстанавливается
2. 2
   Проанализируйте размер таблиц и найдите основные источники объёма
3. 3
   Сократите журнал регистрации и снизьте уровень протоколирования
4. 4
   Выполните удаление помеченных объектов с контролем ссылок
5. 5
   Очистите версии объектов, протоколы обменов и служебные регистры
6. 6
   При необходимости выполните свёртку старых периодов на копии базы
7. 7
   Проведите дефрагментацию (файловая база) или shrink и реиндексацию (SQL)
8. 8
   Проверьте итоговый размер и корректность учётных данных

Дефрагментация файловой базы

Файловая база 1Cv8.1CD устроена как контейнер: удалённые данные оставляют внутри «дырки», и файл сам не уменьшается. Чтобы физически сжать файл, запустите конфигуратор в монопольном режиме: «Администрирование → Тестирование и исправление», отметьте пункт «Сжатие таблиц информационной базы» и выполните. Операция на большой базе может занять часы — планируйте её на нерабочее время.

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

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

В клиент-серверном варианте после удаления данных страницы в файлах БД остаются выделенными. Для MS SQL Server используйте операцию Shrink Database или Shrink File в Management Studio, но учитывайте: shrink сильно фрагментирует индексы, поэтому сразу после него выполните реиндексацию (перестроение индексов). Лучшая практика — не злоупотреблять shrink, а поддерживать размер регламентными заданиями очистки.

Отдельно проверьте журнал транзакций (файл .ldf): при модели восстановления Full без регулярного бэкапа лога он разрастается до огромных размеров. Решение — настроить регулярное резервное копирование журнала или, если точечное восстановление не требуется, перевести базу в модель восстановления Simple.

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

Сравнение подходов

Тестирование и исправление со сжатием

Подходит для файловых баз; просто, но требует монопольного доступа и времени

Выгрузка и загрузка через .dt

Даёт максимальное сжатие файловой базы; нужно много свободного места и время на загрузку

Shrink + реиндексация на SQL

Для серверных баз; эффективно, но фрагментирует индексы, требует последующего обслуживания

Свёртка периодов

Радикально уменьшает данные; теряется детальная история, обязательна архивная копия

Выносим файлы и архивы из базы

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

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

Проверка результата и профилактика

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

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

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

Почему после удаления документов размер базы не уменьшился?

Удалённые данные оставляют внутри файла или страниц SQL пустое пространство, которое не возвращается системе автоматически. Для файловой базы выполните сжатие таблиц через тестирование и исправление или загрузку из dt, для серверной — shrink с последующей реиндексацией.

Можно ли уменьшить базу без свёртки старых периодов?

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

Опасно ли делать shrink базы на MS SQL?

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

Сколько времени занимает сжатие большой файловой базы?

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

Что делать, если журнал транзакций SQL занял весь диск?

При модели восстановления Full журнал растёт, пока не настроен бэкап лога. Сделайте резервную копию журнала — после этого его можно сократить. Если восстановление на момент времени не нужно, переведите базу в модель Simple и сожмите файл журнала, но согласуйте это с политикой резервного копирования.

Можно ли удалять старые файлы журнала регистрации вручную?

Файлы старых сегментов журнала в каталоге 1Cv8Log можно переместить в архив после остановки работы с базой, но безопаснее использовать штатное сокращение журнала в конфигураторе — оно корректно обновляет структуру журнала и позволяет сохранить удаляемую часть в отдельный файл.