Мы столкнулись с распространенной и достаточно неприятной проблемой, которая проявляется в неконтролируемом росте таблицы binarydata в информационных базах 1С:Предприятия, особенно на платформах версии 8.3.27, в частности 8.3.27.1688. Пользователи сообщают о том, что размер этой таблицы может увеличиваться до десятков и сотен гигабайт, что значительно замедляет работу системы. Чтобы оценить масштаб проблемы, можно использовать специальную обработку, которая позволяет узнать размер занимаемых данных в разрезе метаданных объектов БД.
Таблица binarydata предназначена для хранения двоичных данных, таких как присоединенные файлы, картинки, файлы кэша и другие объекты. В некоторых случаях в этой таблице могут быть сотни тысяч записей, где поля f_off и f_num равны нулю. Чтобы лучше понять внутреннее устройство этих процессов, полезно ознакомиться со структурой хранения базы данных, что поможет быстрее ориентироваться в таблицах СУБД.
Давайте выясним причину такого поведения. Основная причина кроется в ошибке, признанной разработчиками 1С, в механизме управления двоичными данными платформы 1С:Предприятие 8.3.27. Эта ошибка приводит к некорректной очистке устаревших или неиспользуемых бинарных данных. Когда присоединенные файлы удаляются или изменяются, их "мусор" остается в таблице binarydata, и база данных неконтролируемо растет.
Мы не будем паниковать, а разберем несколько эффективных решений и рекомендаций, которые помогут нам справиться с этой проблемой. Рассмотрим каждое из них подробно.
Наиболее простым и рекомендованным решением является обновление платформы 1С:Предприятие до версии 8.3.27.1859 или выше. Разработчики исправили корневую причину некорректной очистки данных в более поздних релизах.
Это ключевой метод, который позволяет предотвратить рост таблицы binarydata внутри самой базы. Вместо хранения данных в СУБД, мы переносим их в файловую систему или S3-хранилища. Перед началом этой процедуры рекомендуется выполнить расчет размера таблиц базы данных по метаданным, чтобы грамотно выбрать стратегию уменьшения размера (свертка, выгрузка на тома или переход на новую базу).
binarydata.Иногда помогает принудительный запуск внутренних механизмов платформы. Для этого нужно выгнать всех пользователей, заблокировать регламентные задания и зайти в базу в монопольном режиме. В некоторых случаях после выхода из такого сеанса платформа инициирует автоматическую очистку мусора.
Метод "сжатия" через выгрузку в .dt и загрузку в новую базу может помочь, но будьте осторожны: на дефектных версиях платформы это не всегда эффективно. Перед этим обязательно сделайте резервную копию.
Этот метод требует глубокого понимания работы СУБД. Для безопасного выполнения подобных манипуляций полезно использовать инструменты для анализа SQL сервера глазами 1С-ника, которые позволяют отслеживать текущие запросы и ожидания. Также крайне важно, чтобы в системе была настроена правильная инструкция по настройке регламентных операций MS SQL SERVER, включая дефрагментацию и обновление статистики.
Пример запроса для удаления частей больших объектов (если f_num > 0):
DELETE FROM binarydata WHERE f_num > 0;
Если же все записи имеют f_off = 0 и f_num = 0, то данный запрос не поможет, и проблему нужно решать обновлением платформы.
Для самописных конфигураций можно модифицировать код, чтобы провоцировать очистку данных.
Получить() после записи объекта с полем типа ХранилищеЗначения иногда помогает платформе корректно обработать объект.Версия 8.3.27.1606 часто упоминается как альтернатива, но проблема с binarydata была характерна для всей ранней линейки 8.3.27. Мы рекомендуем не откатываться на сомнительные релизы, а обновляться до официально исправленных версий (8.3.27.1859 и выше).
Подводя итог: наиболее надежными способами остаются обновление платформы и вынос файлов на тома. Все остальные методы следует применять с осторожностью и только после создания полной резервной копии базы данных.