← На главную

При активном использовании механизма расширений разработчики нередко сталкиваются со сбоем при попытке выгрузить информационную базу в файл выгрузки или во время реструктуризации таблиц. В окне сообщений 1С появляется системное оповещение: «ошибка блочного хранения двоичных данных». Проблема обостряется в тех случаях, когда в расширение добавляются собственные объекты данных, связанные ссылками с объектами основной конфигурации. Разберем детально, почему возникает этот сбой и как его гарантированно устранить.

Выясним причину сбоя блочного хранения

Проанализируем техническую сторону вопроса. Начиная с версии 8.3.26 технологической платформы 1С, разработчики переработали механизм хранения больших двоичных объектов (BLOB, служебные структуры метаданных, поля с типом ХранилищеЗначения). В клиент-серверном варианте работы эти данные начали записываться специальными блоками через системную таблицу BinaryData.

Однако в первых релизах ветки 8.3.27 (в частности, в сборках 8.3.27.1606, 8.3.27.1644, 8.3.27.1688 и 8.3.27.1719) проявились критические ошибки платформы (зарегистрированные под номерами 60025066 и 60023075). Ошибка заключается в некорректной сериализации двоичных блоков метаданных при формировании файла .dt или реструктуризации.

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

Способ 1. Обновление платформы и выполнение реиндексации

Рассмотрим основной способ решения, который устраняет корень проблемы. Ошибка платформы 60025066 была официально исправлена фирмой «1С» начиная с релиза платформы 8.3.27.1786. Соответственно, переход на актуальные сборки (например, 8.3.27.1989 и выше) является первоочередным шагом.

Разберем последовательность действий по шагам:

1. Обновим серверную и клиентскую части технологической платформы 1С до стабильного релиза (не ниже 8.3.27.1786, рекомендуется 8.3.27.1989).
2. Запустим информационную базу в режиме Конфигуратор.
3. Перейдем в главное меню: Администрирование — Тестирование и исправление...
4. Обязательно установим флажок напротив пункта Реиндексация таблиц информационной базы, а также рекомендуется включить проверку логической и ссылочной целостности.
5. Запустим процесс тестирования и дождемся его полного завершения.
6. Повторим операцию выгрузки информационной базы в файл .dt.

Способ 2. Отключение режима использования блочного хранения в свойствах конфигурации

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

Разберем по шагам, как проверить и скорректировать эту настройку:

1. Откроем корневые свойства основной конфигурации в дереве метаданных.
2. Найдем свойство Режим совместимости. Если режим совместимости конфигурации установлен в значение 8.3.25 или ниже, ниже станет доступным свойство Режим использования блочного хранения двоичных данных.
3. Изменим значение этого свойства на Не использовать.
4. Выполним обновление конфигурации базы данных (нажатием клавиши F7). При этом платформа выполнит обратный перенос данных из специальной таблицы блочного хранения BinaryData в стандартные поля таблиц объектов.
5. Проверим повторную выгрузку базы.

Важное замечание: если в вашей конфигурации установлен режим совместимости 8.3.26 или выше, данное свойство блокируется платформой принудительно и не подлежит изменению. В таком случае единственным системным решением остается только обновление версии платформы 1С.

Способ 3. Очистка кэша сервера и клиентских сеансов

Иногда сбой блочного хранения связан с повреждением закэшированной структуры данных метаданных в оперативной памяти сервера приложений. Выполним полную очистку кэша по следующему регламенту:

1. Завершим все активные пользовательские и фоновые сеансы в консоли кластера серверов 1С.
2. Остановим службу Агент сервера 1С:Предприятия в оснастке системных служб операционной системы.
3. Перейдем в каталог данных кластера (по умолчанию путь для 64-разрядной службы Windows: C:\Program Files\1cv8\srvinfo\).
4. Найдем каталог нужного кластера и удалим временные папки серверного кэша метаданных (подкаталоги с длинными буквенно-цифровыми идентификаторами snccntx*).
5. Запустим службу сервера 1С и очистим локальный кэш на рабочем месте администратора (удалением содержимого каталогов %LocalAppData%\1C\1cv8 и %AppData%\1C\1cv8).

Способ 4. Использование резервных копий средствами СУБД

Разберем архитектурный аспект создания резервных копий. Выгрузка в формат .dt через конфигуратор не предназначена для создания штатных резервных копий продуктивных баз в клиент-серверном варианте (MS SQL Server, PostgreSQL и др.). Формат .dt разработан исключительно для переноса данных между разными типами СУБД или разворачивания баз для целей разработки.

Резервное копирование средствами самой системы управления базами данных (например, создание бэкапа через pg_dump / резервное копирование в PostgreSQL или создание плана обслуживания Backup Database в MS SQL Server) выполняется напрямую на уровне страниц диска и структур СУБД. Эти средства работают в обход внутренних сериализаторов 1С и гарантированно не вызывают ошибок блочного хранения.

Способ 5. Архитектурная оптимизация связей между базой и расширением

Если доработки расширением активно развиваются, а перекрестные ссылки вызывают нестабильность, проанализируем архитектуру структуры данных. Хранение собственных данных в расширениях исторически является чувствительным местом платформы при масштабных реструктуризациях.

Рассмотрим два пути устранения конфликта зависимостей:

1. Перенос ключевых структур в основную конфигурацию: если объем новых объектов велик (документы, измерения регистров), целесообразно включить возможность изменения основной конфигурации с сохранением поддержки и перенести созданные объекты туда. Это исключит конфликт механизмов слияния метаданных при обновлении.
2. Отказ от жестких ссылочных типов в пользу строковых идентификаторов: если основную конфигурацию необходимо оставить на полной поддержке, заменим прямой ссылочный реквизит типа ДокументСсылка.ПриказНаИнвентаризацию на строковое поле (например, ИдентификаторПриказа с типом Строка(36)). В нем программно будем сохранять строковое представление уникального идентификатора объекта расширения (Строка(СсылкаНаПриказ.УникальныйИдентификатор())). Это полностью разорвет прямую зависимость метаданных на уровне СУБД и снимет проблему блокировок при выгрузке.