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

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

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

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

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

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

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

Очищаем версии объектов и историю изменений

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

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

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

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

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

Журнал регистрации в файловой базе хранится отдельно (каталог с файлами .lgd рядом с базой), но в клиент-серверном варианте занимает таблицу в СУБД. Сократить его можно в конфигураторе: «Администрирование» → «Журнал регистрации» → кнопка «Сократить». Выберите дату, до которой удалить события, и обязательно включите сохранение удаляемой части в отдельный файл — это позволит при необходимости поднять старую историю аудита.

Сжимаем таблицы: тестирование и исправление, shrink на SQL

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

Для SQL Server аналогичный эффект даёт команда сжатия базы или файлов данных (DBCC SHRINKDATABASE / SHRINKFILE) через Management Studio. Для PostgreSQL физическое освобождение места выполняет VACUUM FULL по конкретным таблицам. Учтите: shrink на SQL Server вызывает сильную фрагментацию индексов, поэтому после него рекомендуется выполнить реиндексацию — либо штатным «Тестированием и исправлением», либо средствами СУБД.

1. 1
   Создайте резервную копию (выгрузка в dt или копия каталога базы)
2. 2
   Удалите помеченные объекты в режиме предприятия
3. 3
   Очистите устаревшие версии объектов и сократите журнал регистрации
4. 4
   Закройте все сеансы и откройте базу в конфигураторе монопольно
5. 5
   Запустите тестирование и исправление с опцией сжатия таблиц
6. 6
   Сравните размер файла 1Cv8.1CD до и после операции

Свертка старых периодов и перенос файлов из базы

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

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

Отдельная статья экономии — присоединённые файлы (сканы, изображения, документы Word и Excel). Если конфигурация поддерживает хранение файлов в томах на диске, переведите хранение из базы в файловые тома: размер базы заметно сократится, резервное копирование ускорится, а файлы останутся доступными пользователям.

Сравнение вариантов уменьшения базы

Очистка версий и журнала регистрации

Безопасно и быстро, но даёт умеренный эффект; подходит как регулярная профилактика

Удаление помеченных + сжатие таблиц

Заметный эффект при давно не обслуживаемой базе; требует монопольного доступа

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

Максимальное уменьшение, но теряется детальная история; нужна тщательная сверка остатков

Перенос файлов в тома на диске

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

Настраиваем регулярное обслуживание

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

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

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

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

Удалённые данные освобождают страницы внутри файла, но сам файл не сжимается автоматически. Для файловой базы выполните «Тестирование и исправление» с опцией сжатия таблиц, для SQL Server — shrink, для PostgreSQL — VACUUM FULL по нужным таблицам.

Безопасно ли сокращать журнал регистрации?

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

Что лучше для старых данных: свертка или отдельная архивная база?

Чаще удобнее комбинация: в рабочей базе выполняется свертка с остатками на дату, а полная копия базы до свертки сохраняется как архив. Архив открывается только при необходимости посмотреть старые документы, а рабочая база остаётся компактной.

Как часто нужно сжимать базу?

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

Влияет ли полнотекстовый поиск на размер базы?

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