3,85 ТБ мёртвого кэша в базе 1С на 4,2 ТБ: диагностика и чистка

Мёртвый кэш в базе 1С — это временные таблицы обмена, журналы регистрации, версии объектов и служебные регистры, которые СУБД физически хранит, но платформа больше не читает. Найти его можно через анализ занятого места по таблицам (DBCC SHOWCONTIG в MS SQL или pg_total_relation_size в PostgreSQL) и сверку с реальным объёмом данных в конфигураторе.

Почему возникает мёртвый кэш в базе 1С

Клиент обратился с конкретной цифрой: SQL-сервер показывает 4,2 ТБ занятого пространства под базой 1С:ERP, диск на 5 ТБ забит на 84%, а бэкапы перестали помещаться в ночное окно. При этом штат — 60 пользователей, обороты средние для оптового дистрибьютора. По ощущениям бухгалтера база «весит как для холдинга».

Мы подняли DBCC SHOWCONTIG по каждой таблице и сопоставили с объектами метаданных через консоль администрирования кластера. Но вместо документов и регистров основной вес держали три источника: таблица истории версий объектов (_VersionInfo) — 1,6 ТБ, журнал регистрации за 9 лет без архивации — 1,1 ТБ, и временные таблицы полнотекстового поиска, которые не пересобирались с 2021 года — 0,9 ТБ. Плюс россыпь по регистрам расчёта, где старые периоды ни разу не сворачивались.

Итого 3,85 ТБ — это не бизнес-данные, а накопленный технический мусор. Платформа 1С не удаляет такие структуры автоматически: версионирование объектов растёт, пока администратор не почистит его вручную через «Управление версиями объектов», журнал регистрации не архивируется без явной настройки period-cutoff, а индексы полнотекстового поиска раздуваются при частых правках справочников без периодического REINDEX.

Поэтому база растёт годами незаметно — до момента, когда бэкап начинает падать по таймауту, а тест Гилёва (gilev.ru/tpc) показывает деградацию скорости проведения документов на треть относительно эталона на том же железе.

Как исправить раздутую базу 1С: пошаговая чистка

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

1. Снять точную карту веса

Строим отчёт по объёму метаданных в конфигураторе (Администрирование → Анализ и мониторинг объёма) и сверяем с DBCC SHOWCONTIG. Разница между «весом в 1С» и «весом на диске» — это и есть кандидат в мёртвый кэш.

2. Архивировать журнал регистрации

Через «Журнал регистрации» выгружаем события старше 1-2 лет во внешний файл (.lgf) и уменьшаем таблицу в СУБД. Для больших журналов это отдельная процедура на 4-8 часов на выделенном сервере, не на боевом.

3. Почистить версии объектов

«Управление версиями объектов» позволяет задать глубину хранения (например, 90 дней) и запустить регламентную очистку. На базе клиента после этого шага таблица версий сократилась с 1,6 ТБ до 40 ГБ.

4. Пересобрать полнотекстовый индекс

Полное обновление индекса полнотекстового поиска (а не инкрементальное) убирает накопленный мусор от удалённых и изменённых объектов.

5. Сжать базу данных

После чистки — SHRINK DATABASE (MS SQL) или VACUUM FULL (PostgreSQL) в отдельное окно обслуживания, иначе освобождённое место останется зарезервированным файлом, а не вернётся ОС.

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

Что делать, если ошибка повторяется

Почистили один раз — через полгода база снова растёт тем же темпом. Значит, устранили симптом, не причину. Три типовых источника повторного раздувания:

• ✓Регламентные задания архивации журнала регистрации не настроены на автозапуск — чистка была разовой ручной операцией.
• ✓Глубина хранения версий объектов возвращена на «без ограничений» после обновления конфигурации — типовое поведение при обновлении типовых форм 1С поверх доработок.
• ✓Полнотекстовый индекс не входит в регламент обслуживания — REINDEX выполняется только когда кто-то вручную об этом вспоминает.

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

Как предотвратить повторное разрастание базы 1С

Ставка, если игнорировать проблему: у клиента бэкап уже не укладывался в ночное окно, а это прямой риск потери суток данных при сбое. Плюс аренда места на СХД под 4,2 ТБ вместо 350 ГБ реальных данных — это переплата за инфраструктуру, которую никто не считал отдельной строкой.

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

Отдельная тема — железо, на котором крутится СУБД. Если сервер уже не тянет объём даже после чистки, разумнее не покупать оборудование под пиковую нагрузку раз в пять лет, а перенести базу на арендованный сервер для 1С — аренда виртуального сервера у нас от 3300 руб/мес, а собственно аренда самой 1С — от 1100 руб/мес, с учётом NVMe-дисков и регламентных бэкапов на стороне провайдера.

Сравнение: ручная чистка своими силами vs подрядчик

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

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

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

Можно ли почистить базу 1С без остановки работы пользователей?

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

Сколько времени занимает чистка базы на 4 ТБ?

Зависит от объёма мусора и железа: анализ занимает 1-2 дня, сама чистка версий и журнала — от нескольких часов до суток, SHRINK на многотерабайтной базе может идти 6-10 часов на отдельном окне.

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

Без SHRINK DATABASE (MS SQL) или VACUUM FULL (PostgreSQL) место останется зарезервированным внутри файла и на диске не появится. Это отдельный обязательный шаг после самой чистки данных.

Есть ли риск потерять важные данные при удалении версий объектов и журнала регистрации?

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

Как понять, что база снова начала раздуваться мёртвым кэшем?

Если размер базы на диске растёт быстрее, чем количество документов и оборотов бизнеса — например, +7% в месяц при стабильных продажах — это повод проверить регламентные задания архивации и версионирования, не дожидаясь проблем с бэкапом.