Чистим и сжимаем базу 1С: как вернуть гигабайты

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

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

Ниже — по шагам: как найти тяжёлые места, что чистить и чем потом «ужать» результат. Пути указаны для 1С 8.3 с интерфейсом «Такси».

С чего растёт база и как найти тяжёлые таблицы

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

• 📄 Присоединённые файлы и сканы. Если в настройках хранить файлы внутри информационной базы, а не в томах на диске, картинки и PDF оседают в таблицах и тянут их вверх.
• 🧾 Журнал регистрации. Логи действий пользователей за годы — отдельный большой кусок на диске.
• 🗂️ Документы и регистры за старые периоды. Проводки, движения, версии объектов, которые давно не нужны для оперативной работы.

Как измерить, что сколько весит:

1. Для клиент-серверной базы откройте консоль СУБД. На MS SQL отчёт Disk Usage by Top Tables (правый клик по базе → Reports → Standard Reports) покажет самые тяжёлые таблицы. На PostgreSQL — запрос к pg_total_relation_size.
2. Для файловой базы прямого отчёта по таблицам в штатной поставке нет. Ориентируйтесь по размеру файла .1CD в динамике и по косвенным признакам: объём журнала, количество версий объектов, число присоединённых файлов.
3. Внутри самой 1С оцените нагрузку через раздел Администрирование → настройки хранения файлов и версионирования объектов: часто именно версионирование копит десятки гигабайт незаметно.

Определив, что весит больше всего, выбирайте метод под свой случай.

Чистка журнала регистрации событий

Журнал регистрации в 8.3 хранится отдельно от учётных данных — в каталоге базы, в файле формата SQLite (расширение .lgd). Это значит, что его чистка уменьшает место на диске, но на размер .1CD или базы SQL напрямую не влияет. Зато выигрыш бывает крупным: у баз, которые годами копили лог, журнал легко перерастает саму базу.

Порядок действий через Конфигуратор:

1. Откройте базу в Конфигураторе (Конфигуратор в окне запуска).
2. Меню Администрирование → Настройка журнала регистрации.
3. Задайте разумный срок хранения — например, разделять журнал по месяцам и держать последние 3–6 месяцев.
4. Нажмите кнопку сокращения журнала и укажите дату, до которой записи удаляются. При желании их можно выгрузить в файл перед удалением.

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

На будущее настройте разумную политику: избыточная детализация (логирование чтения данных, например) раздувает журнал в разы. Оставьте только нужные категории событий.

Удаление помеченных на удаление объектов

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

Запуск в режиме предприятия:

1. Раздел Администрирование, блок обслуживания данных, команда «Удаление помеченных объектов».
2. Выберите режим с контролем ссылок (программа проверит, не ссылаются ли на удаляемые объекты другие данные).
3. Если найдены ссылки — платформа покажет список и не даст удалить объект, пока на него кто-то ссылается. Снимите пометку или перенаправьте ссылки.
4. Запустите удаление.

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

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

Сжатие таблиц файловой базы

Для файловой базы (.1CD) освободившееся место возвращает сжатие таблиц. Оно пересобирает файл и выкидывает пустоты, оставшиеся после удаления данных.

Через Конфигуратор:

1. Администрирование → Тестирование и исправление.
2. Снимите лишние галочки, оставьте проверки по необходимости и обязательно включите сжатие таблиц информационной базы.
3. Выберите режим «только тестирование» для первого прогона либо сразу «тестирование и исправление».
4. Запустите. Процедура требует монопольного доступа — пользователи работать не смогут.

Альтернатива для файловой базы — выгрузка-загрузка (следующий раздел): она тоже пересобирает файл и часто даёт лучший результат по размеру.

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

Выгрузка и загрузка информационной базы

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

Порядок:

1. Конфигуратор → Администрирование → Выгрузить информационную базу. Укажите путь к .dt.
2. Создайте новую пустую базу или подготовьте целевую.
3. Конфигуратор целевой базы → Администрирование → Загрузить информационную базу, выберите .dt.

Нюансы по размеру:

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

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

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

Что делает свёртка:

1. Считает остатки по регистрам на дату свёртки.
2. Создаёт документы ввода остатков с этими суммами.
3. Помечает на удаление (или удаляет) старые документы и движения до даты.
4. Проверяет, что обороты и остатки после свёртки сходятся с исходными.

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

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

Обслуживание серверной базы на стороне СУБД

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

MS SQL Server:

• Проверьте модель восстановления базы. Если журнал транзакций (.ldf) разросся до десятков гигабайт, а полное восстановление по точке времени не требуется — переведите базу в режим SIMPLE либо настройте регулярный бэкап журнала при FULL.
• Освободить место в файле данных помогает DBCC SHRINKFILE, но злоупотреблять им нельзя: shrink фрагментирует индексы, после него нужна переиндексация.
• Настройте регламентное обслуживание: REBUILD/REORGANIZE индексов и обновление статистики (UPDATE STATISTICS). Фрагментированные индексы не только тормозят, но и занимают лишнее место.

PostgreSQL:

• VACUUM помечает «мёртвые» строки для повторного использования, но файл не отдаёт. Вернуть место на диск умеет VACUUM FULL — он пересобирает таблицу, но блокирует её на время работы.
• Проверьте, что autovacuum настроен и успевает обрабатывать активные таблицы 1С.
• Периодически выполняйте REINDEX для раздувшихся индексов.

Остановка службы сервера 1С или СУБД ради обслуживания оборвёт все сеансы пользователей — предупредите их заранее и действуйте в нерабочее время.

Как не дать базе разрастаться снова

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

• 🗃️ Храните файлы в томах на диске, не в базе. В настройках работы с файлами переключите хранение на тома — присоединённые документы перестанут раздувать таблицы.
• 🧹 Регулярно удаляйте помеченные объекты. Настройте регламентное задание удаления помеченных (раз в неделю или месяц).
• 📉 Ограничьте журнал регистрации. Разумный срок хранения и только нужные категории событий.
• 🔁 Обслуживайте СУБД по расписанию. Переиндексация, обновление статистики, контроль журнала транзакций — отдельными заданиями SQL.
• 🧮 Пересмотрите версионирование. Держите версии только для важных объектов и на разумную глубину.

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