Чем раздувается база 1С и как её почистить

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

Разберём по порядку, из чего складывается размер базы 1С, что безопасно удалить штатными средствами, когда нужна свёртка и чем отличается сжатие файловой базы от клиент-серверной на PostgreSQL или MS SQL.

Из чего складывается размер базы

Прежде чем чистить, посмотрите, что именно занимает место. Размер файла .1CD (файловый вариант) или базы на сервере СУБД складывается из нескольких частей, и чистить их нужно разными инструментами.

Основные «пожиратели» места:

• 🗂 Журнал регистрации — пишет каждое действие пользователя. В активной базе на 20 рабочих мест растёт на гигабайты в месяц. В 8.3 это отдельный файл 1Cv8.lgd рядом с базой.
• 🗑 Помеченные на удаление объекты — пока их физически не удалили, они лежат в таблицах вместе с движениями.
• 📎 Присоединённые файлы — сканы, договоры, картинки номенклатуры. По умолчанию хранятся внутри базы и раздувают её сильнее всего.
• 🕑 Версии объектов — если включено версионирование, каждая правка документа сохраняет копию.
• 📜 История данных и данные выполненных регламентных заданий.
• 🔎 Индексы полнотекстового поиска и временные таблицы.

Оценить вклад каждого блока проще всего косвенно: выгрузите базу в .dt, отключите по очереди журнал и файлы — и сравните. В клиент-серверном варианте точнее — средствами СУБД посмотреть размеры таблиц (в MS SQL — отчёт «Disk Usage by Table», в PostgreSQL — представление pg_tables с функцией pg_total_relation_size). Часто одна-две таблицы занимают больше половины базы, и тогда понятно, с чего начинать: имя таблицы вида _InfoRg... указывает на регистр сведений , _AccumRg... — на регистр накопления, а аномально большой _InfoRg с присоединёнными файлами — прямой кандидат на вынос в тома.

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

Не начинайте с физического сжатия базы. Сначала удалите данные, потом ужимайте файл — иначе сжимать будет нечего.

Чистка журнала регистрации

Журнал регистрации — первое, что стоит сократить, потому что это безопасно: на учётные данные он не влияет вообще.

Настройка хранения задаётся в конфигураторе: Конфигуратор → Администрирование → Настройка журнала регистрации. Здесь можно:

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

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

В клиент-серверном варианте журнал тоже можно чистить из конфигуратора, подключённого к серверной базе. Физически файл 1Cv8.lgd в 8.3 — это база SQLite, при сокращении срока хранения она ужимается автоматически.

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

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

В типовых конфигурациях на БСП путь стабильный:

• 1С:Бухгалтерия 3.0 — Администрирование → Обслуживание → Удаление помеченных объектов.
• 1С:ЗУП 3.1 — Администрирование → Обслуживание → Удаление помеченных объектов.
• 1С:УТ 11 — НСИ и администрирование → Обслуживание → Удаление помеченных объектов.

Порядок работы:

1. Запустите обработку и выберите режим «Автоматическое» — программа сама найдёт все помеченные объекты.
2. Дождитесь контроля ссылочной целостности. Если на помеченный объект ссылаются непомеченные документы, 1С покажет список — удалить такой объект нельзя, пока есть ссылки.
3. По каждому «неудаляемому» объекту решите: либо снять пометку, либо поправить ссылающийся документ.
4. Запустите удаление.

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

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

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

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

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

1. Выбрать дату свёртки — обычно начало года, за который учёт уже закрыт и сдан.
2. Обработка формирует остатки по регистрам на эту дату и записывает их документами ввода остатков.
3. Документы и движения до даты свёртки удаляются.
4. Проводится сверка: остатки до и после свёртки должны совпасть до копейки.

Свёртка оправдана, когда базе 5–10 лет и свежие периоды тонут в истории. Если учёту год-два — не трогайте данные, обойдётесь чисткой журнала, файлов и помеченных объектов.

Физическое сжатие: тестирование и уровень СУБД

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

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

Клиент-серверный вариант на MS SQL. Файла .1CD здесь нет, место занимают файлы данных СУБД. После удаления данных:

1. Перестройте индексы базы (ALTER INDEX ... REBUILD или план обслуживания) — это и ускоряет работу, и уплотняет данные.
2. Только при реальном избытке свободного места уменьшите файл данных. Делать это постоянно не нужно: Shrink фрагментирует индексы, и после него их опять надо перестраивать.

Клиент-серверный вариант на PostgreSQL. Обычный VACUUM помечает место для повторного использования, но файл не ужимает. Чтобы вернуть место ОС, нужен полный проход:

VACUUM FULL VERBOSE;

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

Вынос присоединённых файлов в тома на диске

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

В типовых конфигурациях настройка здесь: Администрирование → Настройки работы с файлами → включить «Хранить файлы в томах на диске» и добавить том с путём к сетевой папке или локальному каталогу сервера.

После включения:

1. Новые файлы сразу пишутся в том, а не в базу.
2. Ранее загруженные файлы переносятся отдельной операцией «Перенос файлов в тома» (кнопка в той же форме настроек) — её удобно запустить в нерабочее время.
3. После переноса выполните сжатие таблиц (файловый вариант) или перестроение индексов (клиент-сервер) — только тогда освободившееся место вернётся.

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

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

Ещё один скрытый вес — индексы полнотекстового поиска. Если поиск вам не нужен, его можно отключить (Администрирование → Общие настройки → Полнотекстовый поиск); если нужен — периодически обновляйте индекс, разросшийся служебный индекс тоже занимает место.

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

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

• ⏱ Ограничьте журнал регистрации заранее. Поставьте срок хранения 2–3 месяца и детализацию «ошибки и предупреждения» — тогда журнал не придётся чистить вручную.
• 📎 Включите тома на диске с самого начала. Если в базе активно работают со сканами, храните файлы в томах, а не внутри базы — это снимает главную причину роста.
• 🧹 Настройте автоудаление помеченных объектов. Регламентное задание по ночам не даст мусору копиться тысячами.
• 🗃 Версионируйте выборочно. Включайте историю правок только для документов, где это действительно нужно для контроля, а не «для всего подряд».
• 📅 Планируйте свёртку заранее. Для баз с длинной историей договоритесь о регламенте: например, сворачивать закрытые периоды старше пяти лет, оставляя исходную базу в архиве.

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

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