_binarydata распухла после перехода на режим совместимости 8.3.27: где искать причину и как чистить

18 мая 2026 · infolimp.ru

Автор: 1С Инсайдер · роль: практик 1С · проверка: типовые конфигурации и рабочие сценарии · 0 комментариев

Если ваш DBA в одно прекрасное утро пишет «слушай, у меня _binarydata выросла на сорок гигов за неделю, у тебя там что-то случилось?» — и недавно вы поднимали режим совместимости до 8.3.27 — это, скорее всего, не совпадение. Картина типовая. Первое, что хочется сделать, — откатить совместимость; это решает симптом, но не причину, и при следующем подъёме история повторится. Если у вас прямо сейчас рост угрожает доступности — откатить как временная мера допустимо, но дальше всё равно придётся разбираться. Об этом и поговорим. Разберёмся, что у платформы под капотом, что в этой таблице вообще лежит и что из неё можно выкинуть без последствий.

Что вообще такое _binarydata

В терминологии СУБД у платформы 1С есть служебные таблицы, имена которых начинаются с подчёркивания. `_binarydata` (и парные ей `_binarydataN` для отдельных баз/областей) — место, куда сериализуются двоичные данные платформы: значения типа «ХранилищеЗначения» в прикладных объектах, бинарное представление внутренних структур (настройки СКД, сохранённые варианты отчётов, иногда фрагменты форм и расширений). Это не таблица «ваших» данных — это таблица «как платформа упаковывает то, что не лезет в строки и числа».

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

Когда в редакцию приходят разборы распухшей `_binarydata` — с инфостарта, из писем, из материалов на доработку, — режим совместимости почти никогда не оказывается единственной причиной. Чаще выясняется, что несколько лет никто не следил за версиями объектов и хранилищем настроек уволенных пользователей. Переход на новую совместимость не создал проблему — он сделал её видимой.

Почему миграция на 8.3.27 заставляет её расти

При смене режима совместимости платформа имеет право поменять формат сериализации служебных объектов: настроек динамических списков, сохранённых компоновок СКД, версий объектов, журнала регистрации (в части его расширенных полей). На переходных версиях платформа пишет новый формат, но не всегда подчищает старый — отдельный известный сценарий на 8.3.27 — orphaned-записи: ссылки на хранилище из прикладных объектов уже не указывают сюда, а сама запись в `_binarydata` остаётся. Сколько такого мусора накопится, зависит от конкретной конфигурации и истории её обновлений.

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

Ещё одна частая причина — версионирование объектов. Если у вас включено хранение истории изменений (типовое для документооборота и УХ), переход на новую совместимость может перепрожать историю по объектам, к которым обращалась миграционная обработка. Каждое такое перепрожатие — новая запись в `_binarydata`.

Где смотреть, прежде чем что-то трогать

Первый шаг — не админ-консоль платформы, а сама СУБД. Снимите размер таблицы и индексов:

MS SQL Server: EXEC sp_spaceused N'_binarydata'; — покажет четыре числа: всего, данные, индексы, неиспользованное.

PostgreSQL: SELECT pg_size_pretty(pg_total_relation_size('_binarydata')), pg_size_pretty(pg_indexes_size('_binarydata')); — отдельно общий размер и индексы.

Зафиксируйте обе цифры — это ваш baseline. Если индексы тянут на сравнимый с данными объём (или больше), вторая часть работы будет про индексы, и без этой проверки картина будет неполной. Тревожным считаю порог: общий размер таблицы превысил 10% размера базы — это уже повод вмешаться, не дожидаясь, пока DBA напишет сам.

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

Кеш полнотекстового поиска. Открыть «Все функции → Стандартные → Управление полнотекстовым поиском» (или «Администрирование → Поддержка и обслуживание» в БП/ERP). Смотреть: дата последнего полного индексирования, объём индекса. Если индекс старше года и базу с тех пор активно правили — кеш обычно сильно избыточен.
История данных. Открыть «Все функции → Стандартные → История данных». Смотреть: список объектов с включённым версионированием. Часто там стоит «все объекты», хотя бизнесу нужна история двух-трёх документов. Лишние объекты в этом списке — лишние записи в `_binarydata`.
Хранилище значений настроек. Открыть «Все функции → Стандартные → Хранилище значений настроек». Смотреть: количество настроек на пользователя и долю настроек уволенных людей. Если в списке есть учётки, которые в системе уже не работают, — это чистый мусор.
Журнал регистрации (расширенные поля). Если у вас включено хранение комментариев и расширенных данных в журнале — посмотрите его размер через «НастройкиЖурналаРегистрации» в Конфигураторе. После миграции совместимости формат комментариев иногда меняется, старые записи остаются в новой кодировке.

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

По каждой можно понять: нужно ли вам это вообще в продуктиве в текущем объёме, или вы храните 8 лет настроек давно уволенных пользователей.

Что можно выбросить безболезненно

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

Старые настройки пользователей. У уволенных людей за годы накапливаются сохранённые формы отчётов, варианты СКД, настройки списков. Через «Стандартные → Удаление помеченных» это не уходит — это в хранилище настроек. Чистится отдельно, через типовую обработку «Управление настройками отчётов» или собственным запросом по регистрам сведений `СохранённыеНастройкиОтчётов`/`Настройки*`.
Версии объектов старше нужного горизонта. Если у вас «История данных» с настройками «хранить всё», пересмотрите. Для оперативного анализа полугода обычно хватает, но горизонт хранения — это не технический параметр: уточните у ответственного за compliance, нет ли договорных или отраслевых требований к более длительному сроку. Лишнее чистится регламентом «УдалениеУстаревшихВерсийОбъектов» (есть в БСП).
Кеш полнотекстового поиска. Если индекс не критичен в текущий период, его можно полностью пересоздать — после миграции совместимости это иногда даёт заметный выигрыш. Важно: на крупных базах пересоздание занимает от нескольких часов до суток и создаёт значительную нагрузку, ставить его на регламент в рабочее окно нельзя.

Что НЕ трогать руками

Не лезьте напрямую в `_binarydata` через SQL. Платформа считает её своей, и удаление записи в обход прикладного слоя оставит у вас в базе «висящие» ссылки на несуществующие хранилища значений. Симптомы поймаете не сразу — через неделю при открытии конкретного документа выскочит «Ошибка чтения данных», и связать это с ночной зачисткой будет уже невозможно.

Так же не трогайте хранилища значений у прикладных объектов (картинки в номенклатуре, файлы в задачах) — это ваши данные, не служебка. То, что они весят гигабайты, — отдельная история, решается перенесением в файловое хранилище или вынесением в `1С:Документооборот`, но не зачисткой `_binarydata`.

Подводный камень

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

Откат режима совместимости действительно снимает симптом — рост останавливается. Но причина остаётся, и при следующей попытке поднять совместимость вы получите ровно ту же историю. Откат имеет смысл только как временная мера, если рост угрожает доступности здесь и сейчас, — с обязательным планом разобраться с источником, а не оставить «как было».

Профессиональные решения для 1С и marketplace-интеграций — каталог отчётов и инструментов на витрине НОПи.

Перейти в каталог решений →