С выходом платформы версии 8.3.27 многие администраторы и разработчики столкнулись с критической проблемой: «Ошибка хранилища двоичных данных - Ошибка блочного хранения двоичных данных». Эта ошибка блокирует не только обмен данными в распределенных информационных базах (РИБ), но и делает невозможным создание резервных копий в формате .dt. В рамках данной статьи мы подробно разберем природу этого сбоя, проанализируем причины его возникновения и рассмотрим пошаговый алгоритм восстановления работоспособности системы.
Рассмотрим внутренние механизмы платформы. Начиная с версии 8.3.27.1606, разработчики 1С внедрили оптимизацию хранения больших двоичных данных (BLOB-объектов). Теперь данные могут разбиваться на блоки, что в теории ускоряет работу с базой. Однако в первых сборках этой ветки алгоритм записи заголовков блоков и индексов содержал ошибки. Проанализируем типичный стек ошибки:
{ОбщийМодуль.ВерсионированиеОбъектов.Модуль(1517)}:НаборЗаписей.Прочитать;
{Обработка.КонвертацияОбъектовРаспределенныхИнформационныхБаз.МодульОбъекта(226)}:ПланыОбмена.ПрочитатьИзменения(ЧтениеСообщения, КоличествоЭлементовВТранзакции);
[ОшибкаХранимыхДанных] по причине: Ошибка хранилища двоичных данных - 'Ошибка блочного хранения двоичных данных'
Из стека видно, что проблема чаще всего проявляется в подсистеме «Версионирование объектов». Когда система пытается записать или прочитать версию объекта, она обращается к таблице двоичных данных. Если структура блоков нарушена, 1С не может собрать объект воедино, что приводит к аварийному завершению операции. Это особенно критично для РИБ, так как пакеты обмена включают в себя изменения объектов, которые могут тянуть за собой «битую» историю версий. Для стабильной работы версионирования есть альтернативная подсистема версионирования для MS SQL.
Разберем, какие версии платформы наиболее стабильны в этом вопросе. Практика показывает, что версия 8.3.27.1606 является наиболее проблемной. Для исправления ситуации нам потребуется временное или постоянное обновление до версий не ниже 8.3.27.1719 (или более свежих тестовых сборок, таких как 1786). Для удобства администрирования служб при обновлении можно использовать консольное переключение между платформами. Именно в этих релизах был доработан механизм Тестирования и исправления, способный восстановить структуру битых блоков.
Важный момент: если ваша центральная база (ЦБ) жестко привязана к определенной версии платформы и обновление всей инфраструктуры невозможно, мы применим метод «транзитной очистки» через копию.
Проанализируем алгоритм действий, который помог успешно решить проблему на реальных внедрениях. Рассмотрим его по шагам:
Администрирование — Тестирование и исправление.Очищать объекты. Для двоичных данных это будет означать удаление поврежденных блоков, которые невозможно прочитать.Посмотрим, что происходит во время этого процесса. Платформа сканирует таблицы _DataHistoryVersions и другие хранилища BLOB, пересчитывая контрольные суммы блоков. Если блок поврежден, система пометит его как некорректный и очистит, что позволит в дальнейшем успешно выполнить НаборЗаписей.Прочитать и выгрузить базу в .dt.
После успешного завершения тестирования выполним следующие действия:
.dt теперь проходит без ошибок. Для этого выберем Администрирование — Выгрузить информационную базу. В дальнейшем, для повышения надежности, можно настроить резервное копирование в файл выгрузки (dt) без закрытия открытых сессий..dt файл обратно в рабочую базу (предварительно убедившись, что у нас есть бэкап).Разберем ситуацию, когда база в .dt выгружается, но обмен в РИБ все равно выдает ошибку блочного хранения при приеме сообщения. Это означает, что «битый» объект уже попал в файл обмена Message_XXX_YYY.xml.
Рассмотрим дополнительные меры:
Администрирование — Общие настройки. В штатном режиме для управления версиями удобно использовать групповой переход на другие версии объектов по дате, но в случае повреждения структуры хранения отключение надежнее.Регистрация изменений для обмена данными — для этой задачи есть инструмент для регистрации изменений на планах обмена._DataHistoryVersions), можно выполнить очистку этой таблицы напрямую. Но помните: это приведет к потере всей истории изменений объектов!Пример SQL-запроса для анализа (не для удаления!):
-- Проверка наличия данных в таблице версионирования
SELECT COUNT(*) FROM _DataHistoryVersions
-- Если вы решите очистить историю (Крайняя мера!), используйте TRUNCATE TABLE
-- TRUNCATE TABLE _DataHistoryVersions
Чтобы избежать повторения ситуации, проанализируем следующие советы, которые помогут выстроить более надежную архитектуру (подробнее об этом в статье про концепцию защищенной IT инфраструктуры):
EXCP. Это поможет локализовать конкретный UUID объекта, вызывающего «ошибку блочного хранения», еще до того, как она заблокирует работу всего магазина или офиса.Таким образом, мы выяснили, что проблема носит платформенный характер и лечится сочетанием обновления версии 1С и глубокой проверки целостности данных. Использование «транзитного» обновления через копию позволяет исправить базу даже в тех случаях, когда основная инфраструктура ограничена в обновлении.