При работе с платформой 1С:Предприятие 8.3 в серверном режиме пользователи и администраторы иногда сталкиваются с критической ошибкой: «Неверный формат хранилища данных». Чаще всего это происходит при попытке открыть форму «Регламентные и фоновые задания» или при программном вызове метода РегламентныеЗадания.ПолучитьРегламентныеЗадания(). Ошибка блокирует работу со всеми заданиями, что делает невозможным контроль синхронизации, обновлений и других фоновых процессов.
В этой статье мы подробно проанализируем причины возникновения этой проблемы и разберем по шагам несколько методов ее решения: от простых манипуляций в Конфигураторе до прямого исправления данных на уровне SQL-сервера.
Прежде чем приступать к лечению, разберем природу заболевания. Ошибка возникает в момент десериализации данных. Платформа 1С хранит параметры регламентных заданий и их настройки в специальных таблицах базы данных в полях типа varbinary (хранилище значения). Если в момент записи произошел программный сбой, сетевой лаг или аварийная остановка службы rphost, бинарные данные в поле _Parameters могут записаться некорректно или «обрывочно».
Когда вы вызываете метод ПолучитьРегламентныеЗадания, платформа пытается прочитать все записи из соответствующих таблиц и преобразовать их в объекты 1С. Натыкаясь на «битую» запись, которую невозможно расшифровать, менеджер регламентных заданий выдает фатальную ошибку и прекращает работу. Ситуация осложняется тем, что обычное Тестирование и исправление (ТИИ) часто не видит проблем в этих данных, так как с точки зрения SQL структура таблицы не нарушена — повреждено именно внутреннее содержимое «черного ящика» (бинарного блока).
Первым делом нам нужно понять, какое именно задание повреждено. Если заданий много, удалять все подряд — не лучший выход. Мы можем воспользоваться программным кодом, чтобы методом перебора найти «виновника».
Рассмотрим следующий алгоритм: мы будем запрашивать список заданий по каждому объекту метаданных отдельно в блоке попытки. Однако стоит учесть, что стандартная Попытка...Исключение может не перехватить низкоуровневую ошибку формата данных (приложение просто упадет). В этом случае используйте отладчик, проходя по списку метаданных.
Пример кода для поиска битого задания:
Для Каждого МетаЗадание Из Метаданные.РегламентныеЗадания Цикл
Сообщить("Проверка задания: " + МетаЗадание.Имя);
Попытка
// Пытаемся получить задания только этого типа
ТекущиеЗадания = РегламентныеЗадания.ПолучитьРегламентныеЗадания(Новый Структура("Метаданные", МетаЗадание));
Для Каждого ТЗ Из ТекущиеЗадания Цикл
Сообщить("--- ОК: " + ТЗ.Наименование);
КонецЦикла;
Исключение
Сообщить("!!! ОБНАРУЖЕНО ПОВРЕЖДЕНИЕ В ЗАДАНИИ: " + МетаЗадание.Имя);
Сообщить("Текст ошибки: " + ОписаниеОшибки());
КонецПопытки;
КонецЦикла;
Если код падает без захода в блок исключения, просто смотрите на последнее выведенное в консоль имя задания — следующее за ним в дереве метаданных, скорее всего, и есть проблемное.
Если вы определили проблемное задание (часто это ОтложенноеОбновлениеИБ или СинхронизацияДанных), наиболее эффективным способом будет очистка таблицы этого задания на уровне SQL. Внимание: перед любыми действиями с SQL обязательно сделайте резервную копию базы!
_ScheduledJobsXXXX. Чтобы найти нужную, можно воспользоваться программным методом ПолучитьСтруктуруХраненияБазыДанных() или выполнить поиск в SQL по списку таблиц.SELECT name FROM sys.tables WHERE name LIKE '_ScheduledJobs%'.
USE [Имя_Вашей_Базы];
DELETE FROM _ScheduledJobs5086;
После очистки таблицы ошибка исчезнет. Платформа при следующем обращении или обновлении конфигурации может пересоздать запись задания с параметрами по умолчанию, либо вам потребуется заново настроить расписание в пользовательском режиме.
Если доступа к SQL нет или вы не хотите работать с таблицами напрямую, можно попытаться «пересоздать» объект метаданных. Проанализируем этот процесс:
.cf файлом поставщика.Важный нюанс: при удалении и повторном добавлении задания через сравнение/объединение его внутренний идентификатор (UUID) может измениться. Это приведет к тому, что старые битые записи в SQL-таблицах перестанут быть связаны с объектом метаданных, и ошибка уйдет.
Интересный способ решения проблемы — использование механизма создания подчиненного узла. Рассмотрим ситуацию: в основной базе данные повреждены, но при создании начального образа РИБ 1С выполняет выгрузку объектов. В некоторых случаях в подчиненной базе структура _ScheduledJobs создается «с нуля» без переноса битых бинарных данных. Если в подчиненном узле ошибка отсутствует, можно сделать его главным, заменив им поврежденную базу.
Чтобы избежать повторения ситуации «Неверный формат хранилища данных», рекомендуем придерживаться следующих правил:
1C:Enterprise Service и очистить содержимое папки srvinfo/reg_1541 (за исключением файлов журналов и настроек кластера).Проанализировав ситуацию, мы видим, что проблема «Неверного формата» — это всегда следствие рассинхронизации физического хранения в SQL и логического представления в платформе. Использование скрипта для поиска битого задания и точечная очистка SQL-таблицы _ScheduledJobs — самый быстрый и надежный способ вернуть базу в рабочее состояние.