← На главную

Если вы столкнулись с тем, что после перехода на платформу 1С версии 8.3.27.1688 размер файла данных MDF вашей базы увеличился в несколько раз, а таблица dbo.BinaryData стала занимать критический объем дискового пространства, вы не одиноки. В данном руководстве мы разберем причины этого явления и рассмотрим пошаговые методы устранения проблемы.

Анализ причин роста таблицы

Таблица dbo.BinaryData в MS SQL Server является системной таблицей 1С, предназначенной для хранения двоичных данных (BLOB). Сюда попадают вложения, файлы, сохраненные настройки пользователей и значения типа ХранилищеЗначения. В релизе 8.3.27.1688 был изменен механизм работы с этими данными, что привело к ошибке: система перестала корректно удалять «мусорные» записи, которые остаются после обновления или перезаписи объектов.

Мы проанализировали ситуацию и выделили ключевые факторы:

1. Ошибка платформы: Некорректная работа алгоритма очистки неактуальных записей в BinaryData.
2. Изменения архитектуры: Подготовка платформы к работе с S3-хранилищами вызвала временные сбои в обработке локальных данных.
3. Накопление версий: Файлы, которые должны были быть удалены, продолжают «висеть» в базе, занимая место в физическом хранилище.

Как решить проблему разрастания BinaryData

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

Шаг 1: Обновление платформы 1С

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

Шаг 2: Выгрузка и загрузка информационной базы (.dt)

Это самый эффективный способ «пересобрать» структуру базы и физически очистить таблицу от неактуальных записей. Когда мы выполняем выгрузку в .dt, 1С выгружает только актуальные данные. При загрузке файла обратно в чистую базу, таблица dbo.BinaryData будет создана заново, и мусор в неё не попадет.

Порядок действий:

1. Сделайте полную резервную копию базы данных SQL.
2. Переведите базу в монопольный режим, завершив работу всех пользователей.
3. Запустите выгрузку информационной базы через Конфигуратор.
4. После успешного завершения выгрузки создайте новую пустую информационную базу и выполните в нее загрузку данных из файла .dt.
5. Проверьте размер файла .mdf. Как правило, после этой процедуры он возвращается к адекватным значениям.

Шаг 3: Настройка внешних томов хранения

Если ваша база данных активно использует присоединенные файлы, лучшим архитектурным решением будет перенос этих данных из MS SQL во внешние тома (на файловую систему). Это позволит хранить файлы отдельно от базы 1С, что значительно упростит администрирование и уменьшит размер MDF-файла.

Для настройки выполните следующие шаги:

1. Откройте раздел Администрирование -> Настройки работы с файлами.
2. Установите флажок Хранить файлы в томах на диске.
3. Создайте новый том и укажите путь к сетевой папке или локальному диску с достаточным объемом.
4. Запустите регламентное задание по переносу файлов в тома.

Рекомендации по безопасности

Мы настоятельно не рекомендуем пытаться удалять данные из dbo.BinaryData прямыми SQL-запросами (DELETE или TRUNCATE). Поскольку 1С управляет связями между объектами, прямое вмешательство в системные таблицы с вероятностью 99% приведет к нарушению ссылочной целостности, повреждению базы данных и потере важной информации.

Итог: если вы уже столкнулись с проблемой, начните с обновления платформы, чтобы остановить рост, а затем запланируйте окно обслуживания для проведения выгрузки/загрузки базы данных. Эти шаги в совокупности позволят вернуть работоспособность системы и избавиться от лишнего «балласта» в таблице BinaryData.