Свертка, обрезка, тома или шринк: чем отличаются и как выбрать
Иван Недомолков · Dərc edilib: · Yenilənib:
“Что лучше - свертка или обрезка базы 1С?” - один из самых частых вопросов, и он поставлен неверно. Свертка, обрезка служебных данных, вынос файлов в тома внешнего хранения и шринк - это не конкурирующие способы сделать одно и то же, а разные инструменты под разные причины роста базы. Выбирать между ними “что лучше” - всё равно что спрашивать, что лучше: отвёртка или ножовка. Зависит от того, что именно вы чините.
Ниже - чем отличается каждый метод, что он делает с данными, какой даёт эффект и чем рискует, сведено в одну таблицу. Плюс - как выбрать метод под свою ситуацию и почему на терабайтных базах типовые средства перестают работать. Материал для ИТ-специалиста, администратора или руководителя, принимающего решение о работах.
Четыре метода - и что каждый делает с данными
Ключевое различие между методами - что именно они трогают. Одни уменьшают учётные данные бизнеса (и потому требуют сверки), другие - только служебное окружение (и потому безопаснее), третьи вообще не уменьшают данные, а лишь возвращают место.
Свертка на дату
Перенос остатков на выбранную дату: система формирует документы ввода остатков на эту дату, а более старые документы и движения удаляются или уходят в архив. Это единственный метод, который уменьшает собственно учётные данные - историю документов. Именно поэтому он самый мощный по эффекту и самый рискованный: если остатки посчитаны неверно или после удаления остались битые ссылки, ошибки всплывают в отчётах месяцами.
Свертка уместна, когда основной объём базы - действительно старая история операций, которая операционной работе больше не нужна.
Обрезка служебных данных
Удаление служебного “жира”, который платформа и конфигурация накопили вокруг данных: кэши механизма разграничения доступа (RLS), очереди пересчёта ключей, история версий шаблонов, устаревшие логи и журналы. Учётные данные при этом не трогаются вообще - ни один документ, справочник или движение регистра не удаляется. Отсюда и главное отличие от свертки: обрезка не меняет ни одной цифры в отчётности, если доказано, что удаляемое - мёртвое.
Обрезка уместна, когда карта объёмов показала, что значительную долю базы занимает не бизнес-история, а служебные структуры.
Тома внешнего хранения файлов
Механизм платформы 1С, который выносит присоединённые файлы - изображения номенклатуры, сканы документов, вложения - из таблиц базы данных на дисковые тома (папки файловой системы). Физически картинки и сканы перестают лежать бинарными полями внутри .mdf и хранятся файлами на диске, а база держит только ссылки на них. Учётные данные не меняются, но если в базе накоплены гигабайты вложений, вынос их в тома заметно разгружает и файл базы, и бэкапы, и транзакции.
Метод уместен, когда в топе объёма - таблицы хранимых файлов (сканы, фото товаров), а не документы или регистры.
Шринк (сжатие файла)
DBCC SHRINKFILE не удаляет ни одной строки. Он возвращает операционной системе место, которое уже свободно внутри файла базы или журнала. Шринк ничего не “уменьшает” в смысле данных - он лишь отдаёт диску то, что освободили другие методы. Если файл 2 ТБ и занято 1,95 ТБ, шринк даст 50 ГБ, что бы вы ни делали.
Шринк осмыслен ровно в одном случае: после массового удаления данных, когда внутри файла образовались освобождённые сотни гигабайт. В проекте розничной сети fashion-сегмента после удаления мёртвого кэша занятое место упало с 4 108 до 108 ГБ - и вот тогда сжатие файла имело смысл. Как самоцель шринк бесполезен и вреден: он фрагментирует индексы, которые потом надо перестраивать.
Сравнение методов: одна таблица
| Метод | Что делает | Что трогает | Типичный эффект | Риск | Когда применим |
|---|---|---|---|---|---|
| Свертка на дату | Переносит остатки на дату, старую историю архивирует/удаляет | Учётные данные бизнеса | В разы - десятки раз | Высокий: сверка остатков, ссылочная целостность | Топ объёма - старые документы и движения |
| Обрезка служебного | Удаляет мёртвые кэши RLS, очереди, версии, логи | Только служебное окружение | 0 - 90+ % (по диагнозу) | Средний: доказать “мёртвость” | Топ объёма - служебные структуры |
| Тома внешнего хранения | Выносит вложения/картинки из базы на диск | Только файлы-вложения | Зависит от объёма вложений | Низкий: настроить доступ к томам | Топ объёма - таблицы хранимых файлов |
| Шринк файла | Возвращает ОС свободное место внутри файла | Ничего (только “воздух”) | Только то, что уже свободно | Низкий, но фрагментирует индексы | После удаления данных другим методом |
Читать таблицу нужно по столбцу “что трогает”: методы, меняющие учётные данные (свертка), требуют полной сверки “до/после”; методы, трогающие только окружение (обрезка, тома), - доказательства, что удаляемое/выносимое не используется; шринк не трогает данные вовсе и является лишь завершающим шагом.
Обратимость: архив вместо удаления
Ещё одно различие между методами - насколько легко откатить результат. Свертка необратима по сути: удалённую историю восстанавливает только исходный бэкап, поэтому исходная база всегда сохраняется целиком как архив, доступный бухгалтерии и аудиторам. Обрезка служебного обратима в том смысле, что удаляются заведомо мёртвые структуры, которые платформа при необходимости построит заново (кэши RLS пересчитываются регламентным заданием). Тома внешнего хранения обратимы почти полностью - файлы можно вернуть обратно в базу штатными средствами. Шринк “обратим” тривиально: файл снова вырастет при первой же нагрузке. Чем менее обратим метод, тем строже контур сверки и тем важнее свежий полный бэкап перед необратимой фазой.
Тома: о чём часто забывают
У томов внешнего хранения есть неочевидная цена: вынесенные файлы больше не попадают в бэкап базы данных автоматически. Папки томов нужно резервировать отдельно и держать их согласованными с базой - иначе восстановление базы из бэкапа оставит “висящие” ссылки на файлы, которых нет. Поэтому вынос в тома - это не только разгрузка базы, но и обязательство настроить резервное копирование самих томов и права доступа кластера 1С к каталогам. Метод простой, но требует довести схему бэкапов до конца.
Как уменьшить базу 1С без свертки
Свертку часто советуют первой, но на практике она нужна далеко не всегда - и хорошая новость в том, что уменьшить базу нередко можно вообще без неё, без единого риска для учётных данных.
Если карта объёмов показала, что бизнес-история занимает меньшую часть, а основной вес - служебный “жир” или вложения, то работает связка безопасных методов:
- Тома внешнего хранения - если в базе накоплены сканы и картинки.
- Вынос логов и журналов в архивную базу с ретеншном.
- Пересчёт итогов регистров - сокращение избыточных периодов таблиц итогов.
- Обрезка мёртвых служебных кэшей - после доказательства “мёртвости”.
- Шринк - завершающим шагом, чтобы вернуть освобождённое место диску.
Именно так был получен рекордный результат в проекте розничной сети: связка “обрезка служебного + индексы + пересчёт итогов + шринк” дала 4 197 → 105 ГБ (−97,5 %) без удаления единого документа бизнеса и без остановки торговли. Свертка там не понадобилась вообще - потому что больше 90 % базы оказалось мёртвым кэшем RLS, а не историей операций. Полный разбор - в кейсе “Обрезка базы 4,2 ТБ → 105 ГБ”. Развёрнутое сравнение всех методов уменьшения - в статье “Как уменьшить базу 1С”.
Как выбрать метод под свою ситуацию
Метод выбирается не по популярности совета, а по карте объёмов - таблице “что сколько занимает” со связкой SQL-таблиц с объектами 1С. Короткий разводящий алгоритм:
- Постройте карту объёмов. Без неё выбор метода - гадание. Как это сделать - в статье “База 1С разрослась до 200 ГБ: что делать”.
- В топе таблицы хранимых файлов (сканы, фото)? → Тома внешнего хранения. Быстро и безопасно.
- В топе служебные кэши, очереди пересчёта, история версий, логи? → Обрезка служебного после доказательства “мёртвости”. Учётные данные не пострадают. Само доказательство - самая тонкая часть работы, особенно в чужой конфигурации без документации и без автора кода. Как мы выносим вердикт незнакомой таблице и почему любое сомнение обязано понижать агрессивность решения, разобрано в статье как чистить чужую базу и не сломать учёт.
- Распухли таблицы итогов регистров? → Пересчёт и сокращение периодов итогов.
- В топе - действительно старые документы и движения, ненужные операционной работе? → Свертка на дату. Только тут она оправдана.
- Внутри файла много свободного места после удаления? → Шринк как завершающий шаг.
- Всегда: сначала копия прода, репетиция, сверка “до/после”, свежий бэкап - потом боевая база.
Обратите внимание: свертка - лишь один из шести пунктов, и попадает в дело только когда основной вес базы действительно составляет старая учётная история. В остальных случаях есть более дешёвые и безопасные варианты.
Почему на терабайтах типовое не работает
На небольших базах (до ~100 ГБ) со стандартной конфигурацией часто хватает типовой обработки “Свертка информационной базы” - на копии и со сверкой остатков. На сотнях гигабайт и терабайтах она перестаёт доходить до конца, и это закономерность, а не невезение:
- Объём не помещается в окно. Удаление штатными средствами - построчный каскад через платформу. Контрольный замер на базе крупной сети ломбардов Казахстана (2,3 ТБ) показал: один только каскад удаления занял бы месяцы.
- Память и длинные транзакции. Типовая обработка собирает большие объёмы в память и оперирует длинными транзакциями - на терабайтах это заканчивается падением по памяти или распуханием журнала транзакций.
- Ссылочная целостность. В схеме реальной базы тысячи ссылочных колонок; наивное удаление гарантированно оставляет битые ссылки.
- Долгоживущие объекты. В базе сети ломбардов договор залога живёт годами: документ пятилетней давности мог быть действующим и обязан сохраниться со всей историей - пролонгациями, гашениями, кассовыми документами. Резать историю по дате вслепую нельзя, а типовая свертка про такое не знает.
Решение на этом масштабе - гибрид “логика в 1С, массовые операции в SQL”: бизнес-логику выполняет код 1С, а массовые удаления и пересчёты - оптимизированный SQL с посекционными процедурами, контролем прогресса и table swap вместо построчного DELETE. Так в проекте свертки было обработано ~1,4 млрд строк за ~2 часа, база сокращена 2 341 → 573 ГБ (−75 %) за одно ночное окно с 0 расхождений остатков. Полные цифры - в кейсе “Свертка базы 2,3 ТБ”.
Итог
“Свертка или обрезка” - ложная дилемма. Это разные инструменты:
- свертка уменьшает учётные данные - мощно, но рискованно, и оправдана только когда основной вес базы составляет старая история;
- обрезка служебного и тома внешнего хранения уменьшают окружение, не трогая ни одного документа, - безопаснее и часто достаточно;
- шринк не уменьшает ничего, а лишь возвращает диску место после других методов.
Правильный метод - тот, что соответствует топу таблиц вашей базы. А узнать этот топ можно только по карте объёмов: демо-отчёт на боевой базе показывает, как эти строки выглядят и почему решение по нему принимается за минуту, а не за неделю разглядывания. Если база на MS SQL или PostgreSQL и вопрос конкретно в свёртке, калькулятор свёртки сам посчитает по статистике сервера, сколько уйдёт со старыми годами и сколько останется в таблицах, которые свёртка не трогает.
Проще всего начать с бесплатного экспресс-аудита: по его итогам вы получите диагноз “из чего состоит ваша база” и прогноз эффекта в гигабайтах по каждому применимому методу - до того, как выбирать между сверткой и обрезкой. Если захотите передать работу нам, мы делаем свертку и обрезку больших баз 1С как отдельную услугу: от карты объёмов до ночного окна с протоколом сверки остатков.