С выходом платформы 1С:Предприятие 8.3.27 многие администраторы баз данных столкнулись с пугающим явлением: системная таблица BinaryData начинает увеличиваться в размерах на десятки и сотни гигабайт за считанные дни. Это происходит даже в тех базах, где включено хранение файлов в томах на диске. Ситуация осложняется тем, что стандартные средства обслуживания, такие как «Тестирование и исправление», не всегда помогают, а база перестает выгружаться в формат .dt, выдавая ошибку «Ошибка блочного хранения двоичных данных».
В этой статье мы подробно разберем, что это за таблица, почему механизм очистки дает сбой и какими способами можно вернуть размер базы в разумные пределы — для этого подойдёт инструмент для свертки и сжатия базы 1С. Мы пройдем путь от диагностики причин до радикальных методов миграции данных.
Прежде всего, проанализируем ситуацию: начиная с версии 8.3.23, компания 1С начала внедрять новый механизм блочного хранения двоичных данных. Если раньше значения реквизитов с типом ХранилищеЗначения записывались непосредственно в таблицу соответствующего объекта (справочника или документа), то теперь платформа разбивает их на блоки и складывает в общую таблицу BinaryData.
Этот механизм задуман для оптимизации: блоки данных могут дублироваться (дедупликация), а также их проще передавать частями. Однако в релизах платформы 8.3.27 (особенно в ранних сборках до .1851) алгоритм очистки устаревших версий данных оказался недоработан. Рассмотрим подробнее, как это работает в SQL:
ХранилищеЗначения, старые данные в BinaryData не удаляются мгновенно.f_num. Если f_num равен 0 — данные актуальны. Если больше 0 — это метка времени, когда блок стал неактуальным.DELETE FROM BinaryData WHERE f_num > 0.Проблема заключается в том, что в версиях 8.3.27.1606, 8.3.27.1688 и некоторых других этот процесс либо не запускается, либо блокируется из-за огромного объема данных, вызывая переполнение лога транзакций SQL-сервера.
Первым делом нам необходимо выяснить версию установленной платформы. Если вы используете релиз ниже 8.3.27.1851, то вы столкнулись с официально зарегистрированной ошибкой 60026399. В новых сборках (например, 8.3.27.2073 и выше) механизмы очистки были существенно доработаны.
После обновления платформы при первом запуске или при обращении к данным система инициирует очистку. Посмотрим на критически важный момент: очистка может занять длительное время и вызвать «зависание» системы, так как SQL будет выполнять массированный DELETE. В некоторых случаях администраторы наблюдают гигантские транзакции, которые «отъедают» всё место на диске под лог транзакций (LDF) или tempdb.
Если обновление платформы не помогает или база уже настолько раздута, что стандартная очистка не справляется, рассмотрим классический метод — выгрузку в .dt и загрузку в новую базу. Как показывает практика, при формировании файла .dt платформа игнорирует помеченные на удаление блоки (где f_num > 0).
Однако здесь нас может подстерегать ловушка: ошибка «Ошибка хранилища двоичных данных». Если вы столкнулись с ней, выполним следующие шаги:
ХранилищеЗначения.Если размер таблицы BinaryData исчисляется сотнями гигабайт и база «стоит», некоторые специалисты прибегают к прямой очистке через SQL-запрос. Внимание: этот метод официально не поддерживается и требует обязательного бэкапа!
Разберем логику запроса. Нам нужно удалить только те записи, которые сама 1С считает мусором:
-- Проверка количества мусорных записей
SELECT COUNT(*) FROM BinaryData WHERE f_num > 0;
-- Удаление мусорных записей (выполнять порциями, чтобы не переполнить лог)
DELETE TOP (10000) FROM BinaryData WHERE f_num > 0;
Важно помнить, что если вы удалите записи, где f_num = 0, вы безвозвратно потеряете живые данные (картинки, файлы, печатные формы). Поэтому работаем только с записями, помеченными значением больше нуля.
Выясним причину, почему даже при внешних томах таблица растет. Платформа всё равно использует BinaryData для данных размером менее 2048 байт. Чтобы снизить нагрузку на SQL, можно вынести и это хранилище во внешние файлы через настройки сервера 1С.
Рассмотрим порядок действий:
BinDataStrg).Важный нюанс: папка BinDataStrg теперь является неотъемлемой частью вашей базы. Делайте её бэкап одновременно с бэкапом SQL-базы, иначе при восстановлении вы получите «битые» ссылки в объектах.
Если ни один из методов не помогает и BinaryData продолжает бесконтрольно расти, проанализируем радикальный метод миграции данных обратно в старый формат хранения (до 8.3.23). Это требует временного изменения метаданных.
Рассмотрим алгоритм, предложенный участниками сообщества:
BinaryData обратно в таблицы объектов.Для ускорения процесса, если данных слишком много, можно использовать программный перенос. Напишем небольшой обработчик, который принудительно «передергивает» данные в реквизитах:
Для Каждого СсылкаИзВыборки Из Справочники.ПрисоединенныеФайлы.Выбрать() Цикл
Объект = СсылкаИзВыборки.ПолучитьОбъект();
Если Объект <> Неопределено Тогда
Данные = Объект.СодержимоеФайла.Получить();
Объект.СодержимоеФайла = Новый ХранилищеЗначения(Данные);
Объект.Записать();
КонецЕсли;
КонецЦикла;
Такой подход заставляет платформу перезаписать данные в текущем формате. После завершения миграции и очистки таблицы BinaryData (через .dt), можно снова возвращаться на современные режимы работы, но уже на стабильном релизе платформы.
Проанализировав ситуацию, мы видим, что проблема роста BinaryData — это «болезнь роста» новых механизмов платформы. Чтобы минимизировать риски, придерживайтесь следующих правил:
f_num).Следуя этим инструкциям, вы сможете эффективно управлять объемом вашей базы данных и избежать критических сбоев при работе с двоичными данными.