Как уменьшить размер базы 1С: свертка, обрезка или шринк

База 1С слишком большая - что делать? Вариантов больше одного, и “свертка”, которую советуют первой, нужна далеко не всегда. Иногда терабайты занимает вовсе не история документов, и удалять её бессмысленно. Ниже - откуда растёт база в действительности, сравнение пяти методов уменьшения с эффектом и рисками каждого, и чек-лист выбора. Цифры - из двух наших проектов 2026 года на базах 4,2 и 2,3 ТБ.

Сначала диагноз: из чего состоит объём

Первый шаг - не выбирать метод, а построить карту “что сколько занимает”: связать SQL-таблицы с объектами 1С и отсортировать по размеру. Без этой карты любое решение - гадание.

Объём базы складывается из двух принципиально разных частей:

Данные бизнеса - документы, справочники, движения регистров. Это то, ради чего база существует. Уменьшается только сверткой или обрезкой истории - с осторожностью и сверкой.

Служебный “жир” - то, что платформа и конфигурация накапливают вокруг данных:

• кэши механизма разграничения доступа (RLS): ключи доступа, очереди пересчёта, история версий шаблонов;
• таблицы итогов регистров за избыточные периоды;
• версии объектов, если включено версионирование “на всё”;
• журналы регистрации, логи обменов, история задач и бизнес-процессов;
• очереди и результаты фоновых заданий, устаревшие данные полнотекстового поиска;
• “воздух” в файлах: место, освобождённое внутри файла, но не возвращённое операционной системе, и раздутый журнал транзакций.

Соотношение этих частей бывает контринтуитивным. В нашем проекте с базой розничной сети карта объёмов показала: из 4,2 ТБ ≈ 3,85 ТБ занимал мёртвый кэш RLS - история версий шаблонов ограничения доступа (3,34 ТБ) и две очереди пересчёта ключей доступа на 1,18 и 1,19 млрд строк (287 и 221 ГБ). Регламентные задания пересчёта были выключены с 2020 года; кэш копился без остановки. Больше 90 % базы не были данными бизнеса вообще - и классическая свертка документов дала бы здесь считаные проценты эффекта при максимальном риске.

Поэтому не начинайте со свертки. Начните с карты.

Пять методов: сравнение

Метод	Что делает	Типичный эффект	Риски и ограничения
Шринк (сжатие файлов SQL)	Возвращает ОС место, уже свободное внутри файла	От нуля до десятков % - только если файл “раздут”	Данные не уменьшает; фрагментирует индексы; на терабайтах конфликтует с бэкапами
Вынос логов и журналов	Журнал регистрации, логи обменов, техлоги - в архив или на ретеншн	Единицы-десятки ГБ	Низкий; проверить, что логи не нужны аудиту
Пересчёт и сокращение итогов	Убирает избыточные периоды таблиц итогов регистров	Проценты-десятки %	Низкий при штатном выполнении; долгий на больших регистрах
Обрезка служебных данных	Удаляет мёртвые кэши (RLS, версии, очереди) после проверки, что они не используются	От нуля до 90+ % - зависит от диагноза	Требует доказать “мёртвость”: ошибка ломает доступ или историю
Классическая свертка на дату	Остатки на дату - в новую базу, история - в архив	В разы - десятки раз	Самый высокий: сверка остатков, ссылочная целостность, длинные окна

Теперь подробнее о каждом - в порядке возрастания сложности.

Шринк базы 1С: когда он вообще работает

Шринк (DBCC SHRINKFILE и аналоги) - самый популярный совет из форумов и самый переоценённый. Он не удаляет ни одной строки: он возвращает операционной системе место, которое уже свободно внутри файла. Если файл 2 ТБ и занято 1,95 ТБ - шринк даст 50 ГБ, что бы вы ни делали.

Шринк осмыслен ровно в одном случае: после массового удаления данных, когда внутри файла образовались освобождённые сотни гигабайт. В нашем проекте после удаления мёртвого кэша занятое место упало с 4 108 до 108 ГБ - и вот тогда сжатие файла имело смысл: 2 999,6 ГБ → 300 ГБ за 89 минут.

Практические грабли терабайтного шринка, на которые мы наступили сами:

• Сжимать одним проходом оказалось быстрее, чем “порционно по 100 ГБ”, вопреки распространённой рекомендации.
• Параллельный плановый бэкап валит операцию с ошибкой 3140. После прерванных попыток в базе остаётся “залипший” флаг сжатия, который лечится только переводом базы offline/online.
• После шринка индексы фрагментированы: закладывайте время на перестроение (у нас - 200 индексов, 44 минуты).

Отдельно про журнал транзакций: раздутый лог-файл - частая “ложная тревога” большой базы. В проекте свертки лог сократился со 119 до 8 ГБ. Но если лог регулярно вырастает обратно - причина в модели восстановления и расписании бэкапов лога, и лечить надо её, а не симптом.

Вынос логов и журналов

Дешёвый и почти безрисковый метод: журнал регистрации, логи обменов и интеграций, устаревшие версии объектов выносятся в архивную базу или удаляются по сроку хранения. Эффект скромный, но иногда заметный: в нашем проекте вынос одного только лога кассовых операций в архивную базу (через веб-сервисы, с автоочисткой и ретеншном 180 дней) дал −52 ГБ и 14,5 млн записей из боевой базы.

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

Пересчёт и сокращение итогов

Таблицы итогов регистров - служебный ускоритель отчётов. Со временем они накапливают избыточные периоды и заметно распухают. Пересчёт и установка правильного периода хранения итогов - штатная операция, но на больших регистрах платформенный пересчёт может не влезть в ночное окно: в одном из наших проектов он занимал 112 минут, а после переноса на прямой SQL с побитовой сверкой против эталонного механизма - 21 минуту. Эффект по объёму реальный: в проекте розничной сети таблицы итогов сократились на 75 % - с 73,5 до 18,3 млн строк.

Обрезка служебных данных

Самый недооценённый метод - и потенциально самый эффективный, если диагноз это подтверждает. Кандидаты: кэши RLS, очереди пересчёта ключей доступа, история версий, “хвосты” отключённых механизмов.

Главная сложность не техническая, а доказательная: нужно строго обосновать, что данные мертвы. В проекте с кэшем RLS на 3,85 ТБ мы последовательно проверили и отбросили три правдоподобные гипотезы - “RLS отключён, можно удалять всё” (неверно: 208 ролей реально использовали ограничения), “мусор накопили уволенные сотрудники” (живых ключей оказалось 660 строк из миллиардов), “виноват один медленный регистр” (он вообще был из соседней базы на том же сервере). Каждая проверка сэкономила неделю работы в неверном направлении - или предотвратила поломку доступа у работающих кассиров.

Итог того проекта: 4 197 → 105 ГБ (−97,5 %), полный ночной бэкап 556 → 18,3 ГБ, ноль дней простоя торговли - без удаления единого документа бизнеса. Полный разбор - в кейсе “Обрезка базы 4,2 ТБ → 105 ГБ”.

Классическая свертка на дату

Свертка базы 1С - перенос остатков на выбранную дату с удалением (архивированием) более старой истории. Единственный метод, уменьшающий собственно данные бизнеса, - и потому самый рискованный: ошибка в остатках или битые ссылки всплывают в отчётах месяцами.

Свертка уместна, когда карта объёмов показала: основной объём - это действительно старые документы и движения, которые операционной работе больше не нужны. На небольших базах (до ~100 ГБ) со стандартной конфигурацией часто хватает типовой обработки “Свертка информационной базы”. Дальше начинаются проблемы.

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

На сотнях гигабайт и терабайтах типовая обработка перестаёт доходить до конца, и это закономерность, а не невезение:

1. Объём не помещается в окно. Удаление штатными средствами - построчный каскад через платформу. Наш контрольный замер на базе 2,3 ТБ показал: один только каскад удаления занял бы месяцы.
2. Память и транзакции. Обработка собирает большие объёмы в память и оперирует длинными транзакциями - на терабайтах это заканчивается падением по памяти или распуханием журнала транзакций.
3. Ссылочная целостность. В схеме реальной базы тысячи ссылочных колонок (в нашем проекте - 8 500+). Наивное удаление гарантированно оставляет битые ссылки.
4. Не всю историю можно резать по дате. В базе сети ломбардов договор залога живёт годами: документ пятилетней давности мог быть действующим и обязан был сохраниться со всей историей - пролонгациями, гашениями, кассовыми документами. Прямого признака “активности” в данных не было; критерий пришлось конструировать из трёх независимых источников. Типовая свертка про такое не знает в принципе.

Что делать вместо этого - гибрид “логика в 1С, массовые операции в SQL”. Бизнес-логику (расчёт защищаемых данных, документы ввода остатков, бухгалтерская свертка) выполняет код 1С - корректно по правилам платформы. Массовые удаления и пересчёты выполняет оптимизированный SQL: посекционные процедуры с контролем прогресса и возможностью продолжить после остановки, а для крупнейших таблиц - table swap: выжившие данные переносятся в новую таблицу с пересозданием индексов, что в 5-9 раз быстрее построчного DELETE. Так в проекте свертки было обработано ~1,4 млрд строк за ~2 часа - при том что типовой каскад считался месяцами.

Итог того проекта: 2 341 → 573 ГБ (−75 %) за одно ночное окно ~5 часов, бэкап ~570 → 74 ГБ, 46+ млн документов истории, 0 расхождений остатков. Полные цифры - в кейсе “Свертка базы 2,3 ТБ”. Если у вашей базы история режется по дате, а сервер 1С на Windows, проект может и не понадобиться: когда хватает купленной обработки, разобрали в статье готовая обработка свертки или подрядчик.

Чужая база: как доказать, что таблицу можно чистить

Всё вышесказанное предполагает, что вы знаете, за что отвечает каждая крупная таблица. В своей базе так и есть. В чужой самописной конфигурации, где автор кода давно не работает, документации нет, а имена объектов говорят мало, каждый вердикт приходится доказывать. Это самая долгая часть работы, и ошибка здесь стоит дороже всего остального вместе взятого. Короткая версия этого раздела опубликована на Инфостарте.

Ошибка в девятнадцать тысяч раз

Свёртка планировалась в одно ночное окно на базе чуть больше двух терабайт. Карта ссылок, с которой такая работа начинается, выдала по справочнику кассовых чеков цифру 99,9 %: столько записей из 8,34 миллиона не держит никто. Соблазн понятен - одна таблица, один проход, и база худеет сразу и ощутимо.

Настоящих сирот там набралось 439: 0,005 % от таблицы.

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

Между 8,33 миллиона строк, которые предлагал вынести инструмент, и 439 разрешёнными к удалению - те самые девятнадцать тысяч раз. Тот же дефект выборки едва не добавил в список сирот по залогам лишние 17 миллионов строк.

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

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

Асимметрия, из которой растёт весь протокол

Цена двух возможных промахов в такой работе различается на порядки.

Оставить лишнее. Клиенту это стоило дискового места, и только. Заметно сразу, поправимо в любой день, по деньгам разовая мелочь.

Удалить читаемое. Документы перестают проводиться, остатки врут, дебиторка исчезает. Всплывает это спустя недели, на первой же сверке с контрагентом. Лечение одно - откат на бэкап, вместе со всей работой, сделанной после свёртки. А часто лечения нет вовсе.

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

Работает это так. Таблица получает ровно одно значение из закрытого перечня: “пересоздать”, “оставить свежие”, “удалять порциями”, “только после каскада”, “нужен анализ кода”, “не трогать”. Слова “почистить” и “разобраться” вердиктом не являются, прозу не проверишь и не исполнишь машиной. Перечень выстроен лестницей от агрессивного к безопасному, и каждое незакрытое сомнение сдвигает таблицу на ступень ниже. Подняться она может лишь тогда, когда нашлось доказательство, снимающее именно это сомнение. За доказательство при этом не идут “скорее всего мусор”, “похоже на лог” и “в прошлый раз похожее удаляли”.

Пять классов читателей, и “не нашёл” не считается

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

Поэтому деструктивный вердикт заперт, пока не перечислены читатели по всем классам и по каждому не показано, что читателя нет:

1. код конфигурации;
2. внешние обработки;
3. ссылочные держатели в СУБД;
4. обмены и подписки на события;
5. штатные механизмы платформы.

Пропущен хоть один класс - вердикт едет вниз по лестнице.

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

Включённый регламент очистки не означает работающий

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

За девять лет непрерывного накопления это дало 113,7 миллиона строк и 451 гигабайт.

Судить тут надо по строкам в таблице, а состояние процесса про строки не сообщает ничего. Между “задание закрылось без ошибок” и “задание удалило строки” следствия нет.

Проверка короткая: построить распределение строк по годам и сравнить возраст самой старой с настроенным сроком хранения. Старше двух-трёх сроков - механизм не работает. В обратную сторону это тоже единственное доказательство вердикта “не трогать, механизм есть”: на гистограмме видно, что старый хвост действительно уходит.

Порядок операций меняет результат

Те восемь с лишним миллионов чеков держал на себе регистр статусов. Пока старые статусы на месте, сирот среди чеков нет вовсе, они появляются уже после чистки регистра. Значит сначала каскад документов, потом статусы, и только третьим шагом осиротевшие чеки. Поменяйте шаги местами, и под нож пойдут чеки, у которых ещё есть живой статус, а статус этот нужен проведению касс. Вердикты по отдельности верны, губит их последовательность.

Поэтому вердикты складываются в направленный граф без циклов и выполняются в топологическом порядке. По каждому деструктивному шагу задаётся один вопрос: поменяется ли список строк под удаление, если раньше отработает какой-то другой шаг. Ответ “да” рисует ребро зависимости.

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

Счёт за осторожность

Про цену протокола говорить не принято, а она есть.

Регистр накопления, где лежат связи залоговых билетов, показывал повисший хвост на 16,7 миллиарда в валюте учёта. Сумма такого порядка в учёте невозможна, и читается она как след давнего бага. Разбор дал другое: структура перезалога рабочая, к ней обращается бизнес-логика проведения, а 307 записей внутри отвечают за настоящие 4,34 миллиона на балансовом счёте.

Реальная часть этого хвоста - 0,026 %: 4,34 миллиона против 16,7 миллиарда. Смелый вывод “хвост целиком фантомный” попадал в правду на 99,974 %. И ради двадцати шести тысячных процента регистр не тронули вообще, оставив в базе гигабайты, которые с высокой вероятностью были мусором.

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

Второе ограничение неприятнее. Метод опирается на допущение, что всё поведение системы вычитывается из конфигурации и данных СУБД. Расширение, которому разрешено менять структуру данных, это допущение рушит: проведение документа может быть переопределено внутри него, читатель таблицы окажется там же, а основная конфигурация про такого читателя не скажет ничего. Пока расширение не разобрано, класс “код конфигурации” считается открытым, и по правилу выше каждый деструктивный вердикт в базе опускается на ступень.

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

Как не потерять данные: контроль, а не надежда

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

• Репетиции на копии продуктива. Не одна: перед сверткой 2,3 ТБ было 7+ полных прогонов, и каждый ускорял процедуру (каскад: 10 ч → 2 ч; пересчёт итогов: 112 → 21 мин). Ночное окно на проде - исполнение отрепетированного плана, а не эксперимент. Как именно устроены эти прогоны и что на них ловится, разобрано отдельно: “Семь репетиций одной ночи”.
• Числовые гейты перед необратимыми фазами. Автоматика сверяет контрольные показатели; расхождение - стоп, продолжать нельзя. Не “посмотрели глазами”, а формальное условие.
• Сверка “до/после” бит-в-бит. Остатки по всем регистрам, бухгалтерия, ключевые бизнес-метрики. В проекте свертки - плюс полный скан базы по 8 500+ ссылочным колонкам: 0 битых ссылок. Три гейта приёмки на продуктиве прошли зелёными с первого прогона.
• Точки отката перед каждой деструктивной фазой и свежий полный бэкап сразу после завершения - чистая точка восстановления.
• Архив вместо удаления. Исходная база сохраняется целиком: история прошлых лет остаётся доступной бухгалтерии и аудиторам.

Если подрядчик предлагает свертку без репетиций на копии и без протокола сверки остатков - это не экономия, это перенос риска на вас.

Чек-лист: какой метод выбрать

1. Постройте карту объёмов - размер таблиц с привязкой к объектам 1С. Всё дальнейшее зависит от неё.
2. Свободное место внутри файла + раздутый лог? Шринк и настройка бэкапов журнала. Быстро, но эффект ограничен тем, что уже свободно.
3. Топ занимают журналы, версии, логи обменов? Вынос в архив с ретеншном.
4. Распухли таблицы итогов? Пересчёт и сокращение периодов итогов.
5. Топ занимают служебные кэши (RLS, очереди, история шаблонов)? Обрезка служебных данных - после строгого доказательства, что они не используются. Как это доказательство строится в чужой базе, где имена объектов говорят мало, а спросить не у кого, разобрано выше в разделе про вердикты по незнакомой таблице.
6. Топ - действительно старые документы и движения? Свертка на дату. До ~100 ГБ и на типовой конфигурации - можно пробовать типовую обработку на копии; больше или с “долгоживущими” объектами (договоры, залоги, взаиморасчёты) - посекционные процедуры на SQL с полным контуром контроля.
7. В любом сценарии: сначала копия, репетиция, сверка - потом прод.

Методы комбинируются: в проекте розничной сети сработала связка “обрезка служебного + индексы + пересчёт итогов + шринк”, в проекте ломбардов - свертка с table swap (полная методика этого проекта - в нашей статье на Инфостарте). Общее одно: метод выбирается по карте объёмов, а не по популярности совета. Как выглядит такая карта на боевой базе и чем она отличается от “посмотреть размер файла”, показано на демо-странице нашей обработки. Прикинуть эффект именно свёртки можно бесплатным калькулятором: он читает статистику СУБД и отдаёт прогноз размера базы после среза по годам. Тот же расчёт вручную, функцией по объекту и циклом по конфигурации, разобран в статье сколько места освободит свёртка.

Если не хочется проходить этот путь в одиночку - мы делаем свертку и обрезку больших баз 1С как отдельную услугу: от карты объёмов до ночного окна с протоколом сверки. Начать проще всего с бесплатного экспресс-аудита: по его итогам вы получите диагноз “из чего состоит ваша база” и прогноз эффекта в гигабайтах по каждому применимому методу - до того, как принимать решение о работах.

Про деньги и географию, раз уж об этом спрашивают в каждом втором письме. Вилки по всем нашим услугам собраны на странице цен, и от города они не зависят: работаем удалённо по всему Казахстану. Если нужен разговор с привязкой к своему рынку, есть отдельные страницы про услуги 1С в Алматы, в Астане и в Шымкенте.

Перед очисткой отдельно оцените зависимости

Список помеченных объектов ещё не определяет ни безопасный объём удаления, ни длительность окна. В плане оценки чистки базы разобраны ссылочный контроль, замер на копии и приёмка результата. Такая оценка позволяет заранее увидеть, когда основная работа связана с зависимостями, а не с количеством записей. Исходные цифры для неё, помеченные объекты, ссылки на них, присоединённые файлы, версии и старые периоды, собирает чек-ап чистоты базы.