Почему таблица binarydata в 1С 8.3.27.1688 растет до огромных размеров и что с этим делать?

Мы столкнулись с распространенной и достаточно неприятной проблемой, которая проявляется в неконтролируемом росте таблицы binarydata в информационных базах 1С:Предприятия, особенно на платформах версии 8.3.27, в частности 8.3.27.1688. Пользователи сообщают о том, что размер этой таблицы может увеличиваться до десятков и сотен гигабайт, что значительно замедляет работу системы, увеличивает требования к дисковому пространству и усложняет обслуживание базы данных.

Таблица binarydata предназначена для хранения двоичных данных, таких как присоединенные файлы, картинки, файлы кэша и другие объекты, которые не могут быть сохранены непосредственно в стандартных полях базы данных. В некоторых случаях, как мы видим из исходного запроса, в этой таблице могут быть сотни тысяч записей, где поля f_off и f_num, предназначенные для указания смещения и номера части бинарного объекта, равны нулю. Это может свидетельствовать о некорректной работе механизма очистки или хранения данных.

Причины проблемы

Давайте выясним причину такого поведения. Основная причина кроется в ошибке, признанной разработчиками 1С, в механизме управления двоичными данными платформы 1С:Предприятие 8.3.27. Эта ошибка приводит к некорректной очистке устаревших или неиспользуемых бинарных данных. Например, когда присоединенные файлы удаляются или изменяются, их старые версии или "мусор" могут оставаться в таблице binarydata, продолжая занимать место. В результате база данных неконтролируемо растет.

Как мы будем решать проблему?

Мы не будем паниковать, а разберем несколько эффективных решений и рекомендаций, которые помогут нам справиться с этой проблемой. Рассмотрим каждое из них подробно, чтобы вы могли выбрать наиболее подходящий вариант для вашей ситуации.

Решение 1: Обновление платформы

Наиболее простым и рекомендованным решением является обновление платформы 1С:Предприятие. Разработчики знают об этой ошибке, и, как утверждается, она была исправлена в более поздних версиях платформы.

1. Обновите платформу до версии 8.3.27.1859 или выше. Это наиболее эффективный способ, так как он исправляет корневую причину проблемы.
2. Проверьте актуальные релизы. Всегда следите за последними обновлениями платформы, так как 1С регулярно выпускает патчи и исправления для известных ошибок.

Переход на более новую, исправленную версию платформы часто является самым надежным решением.

Решение 2: Настройка внешнего хранения двоичных данных (тома)

Это ключевой метод, который позволяет предотвратить катастрофический рост таблицы binarydata внутри самой базы данных. Вместо того чтобы хранить большие двоичные данные непосредственно в СУБД, мы можем перенести их в файловую систему или во внешние S3-совместимые хранилища.

1. Включите функционал "Управление хранилищем бинарных данных". Мы можем найти этот функционал через меню "Все функции" (или "Функции для технического специалиста") в режиме 1С:Предприятие.
2. Настройте встроенное хранилище двоичных данных.
   • Вам потребуется указать путь к каталогу на сервере приложений 1С, где будут храниться файлы.
   • Убедитесь, что на сервере приложений 1С достаточно свободного места для создаваемого хранилища, так как бинарные данные будут храниться в каталоге BinDataStrg.
   • Этот механизм позволяет переносить большие двоичные данные из таблицы binarydata в файловую систему.
3. Перенесите существующие данные. После настройки хранилища система обычно предлагает перенести уже имеющиеся бинарные данные из базы данных во внешнее хранилище. Обязательно выполните эту операцию, чтобы очистить таблицу binarydata.

Этот подход не только решает проблему роста таблицы, но и улучшает производительность базы данных, так как СУБД не приходится обрабатывать большие бинарные объекты.

Решение 3: Монопольный доступ и автоматическая очистка

В некоторых случаях, если проблема не слишком запущена, мы можем попробовать вызвать автоматическую очистку "мусора" из таблицы binarydata. Однако этот метод не гарантирован для всех версий платформы и не всегда срабатывает.

1. Выгоните всех пользователей из базы данных. Убедитесь, что нет активных сессий, и завершите все зависшие сессии.
2. Заблокируйте регламентные задания. Это предотвратит фоновые процессы, которые могут создавать или изменять данные.
3. Войдите в базу данных под одним клиентом в монопольном режиме.
4. Выйдите из базы данных. Иногда после таких действий платформа пытается выполнить автоматическую очистку.

Проанализируйте размер таблицы binarydata после этой процедуры. Если она уменьшилась, значит, автоматическая очистка сработала.

Решение 4: Выгрузка/загрузка в файл .dt

Традиционный метод "сжатия" базы данных - выгрузка информационной базы в файл .dt и последующая загрузка. Этот метод может помочь уменьшить размер таблицы, но его эффективность не всегда высока, а в некоторых случаях он может даже усугубить проблему из-за некорректного поведения платформы.

1. Выгрузите информационную базу в файл .dt.
2. Создайте новую пустую базу данных.
3. Загрузите файл .dt в новую базу данных.

После этой операции проверьте размер таблицы binarydata. Если вы решили попробовать этот метод, обязательно сделайте резервную копию вашей текущей базы данных.

Решение 5: Прямые запросы к СУБД (Крайняя мера)

Этот метод является крайней мерой и требует глубокого понимания структуры базы данных и работы СУБД. Мы настоятельно не рекомендуем использовать его без предварительного тестирования на копии базы данных и консультации со специалистом по СУБД. Некорректное использование может привести к потере данных.

Для выполнения запроса может потребоваться остановка сервера 1С из-за возможных блокировок таблицы binarydata.

Если вы решитесь на этот путь, сначала обязательно протестируйте запрос на копии базы данных. Важно понимать, что записи, у которых поля f_off и f_num равны нулю, обычно содержат небольшие бинарные данные, хранящиеся непосредственно в таблице. Записи с f_num > 0, как правило, являются частями более крупных бинарных объектов, которые по каким-то причинам могли быть оставлены в таблице без связи с основным объектом.

Пример запроса для очистки потенциально неактуальных записей (частей больших объектов, которые могли быть ошибочно оставлены):

DELETE FROM binarydata WHERE f_num > 0;

Однако, если, как в нашем случае, *все* записи в таблице binarydata имеют f_off = 0 и f_num = 0, то этот конкретный запрос не принесет желаемого результата, так как он нацелен на другие типы "мусора". В такой ситуации проблема может быть глубже, и ее решение, скорее всего, лежит в обновлении платформы или переносе данных во внешнее хранилище, как мы уже рассмотрели.

Решение 6: Чтение полей типа "ХранилищеЗначения"

Для самописных конфигураций или в случаях, когда мы имеем возможность модифицировать код, этот метод может помочь предотвратить дальнейший рост таблицы. Проблема может быть связана с тем, что данные типа ХранилищеЗначения записываются, но не всегда корректно обрабатываются платформой при их последующем удалении или изменении.

1. Немедленное чтение после записи: В коде, где вы записываете данные в поле типа ХранилищеЗначения, рассмотрите возможность немедленного чтения этих данных. Это может помочь платформе корректно "зарегистрировать" или обработать объект.
   Скопировать код

   
   // Пример кода
   МоиДанные = Новый ХранилищеЗначения(ДвоичныеДанные);
   Объект.ПолеХранилище = МоиДанные;
   Объект.Записать();
           
   // Дополнительное чтение, которое может помочь
   ПрочитанныеДанные = Объект.ПолеХранилище.Получить();
   

2. Периодический проход по таблицам: В монопольном режиме вы можете создать регламентное задание или обработку, которая будет проходить по таблицам, содержащим поля типа ХранилищеЗначения, и выполнять чтение этих полей. Это может спровоцировать внутренние механизмы платформы на очистку.

Этот метод требует анализа вашей конфигурации и понимания того, где используются ХранилищеЗначения.

Относительно версии 8.3.27.1606

В ходе обсуждений иногда упоминается версия 8.3.27.1606 как возможная альтернатива. Однако, проанализировав ситуацию, мы понимаем, что проблема роста binarydata была широко распространена во всей линейке 8.3.27. Более ранние версии этой ветки также могли быть подвержены ей. Некоторые пользователи сообщали о проблемах с производительностью и целостностью данных в 8.3.27.1644, а исправление ошибки с хранилищем двоичных данных упоминалось в тестовой версии 8.3.27.1671, а затем в стабильной 8.3.27.1859. Поэтому переход на 8.3.27.1606 может не решить проблему полностью и даже потенциально привнести другие ошибки. Мы рекомендуем ориентироваться на версии, где исправление было официально подтверждено (8.3.27.1859 и выше).

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