Как исправить ошибку В схеме базы данных отсутствует таблица DocumentChngR при обновлении конфигурации 1С

← На главную

При обновлении конфигурации базы данных на платформе 1С:Предприятие разработчики и администраторы нередко сталкиваются со сбоем реструктуризации, сопровождающимся сообщением: «В схеме базы данных отсутствует таблица DocumentChngR[номер]». Ситуация осложняется тем, что типовые средства тестирования и исправления завершаются аварийно, а попытки вручную создать пустую таблицу в СУБД средствами SQL не дают результата. Проанализируем природу этой ошибки, выясним, за что отвечает данная таблица, и подробно разберем по шагам действенные способы восстановления работоспособности базы данных.

Причина возникновения ошибки и механизм SDBL

Для понимания корня проблемы разберем внутреннее устройство платформы. Имя таблицы с префиксом DocumentChngR указывает на то, что это вспомогательная таблица регистрации изменений для конкретного объекта метаданных типа «Документ», включенного в состав одного или нескольких планов обмена. Числовой идентификатор в конце имени (например, 35788) представляет собой внутренний уникальный номер объекта метаданных в конфигурации базы данных.

Ошибка генерируется не самой СУБД (PostgreSQL, MS SQL Server и др.), а внутренним уровнем трансляции запросов платформы 1С — механизмом SDBL (Simple Data Base Language). Платформа 1С хранит внутреннее описание структуры базы данных в специальной двоичной схеме DBSchema (в таблице Params СУБД). При обновлении конфигурации платформа сравнивает исходную схему, метаданные новой конфигурации и физические таблицы в СУБД. Если в результате некорректных динамических обновлений, резкой смены режима совместимости конфигурации или скачка через несколько релизов нарушается целостность схемы DBSchema, SDBL пытается обратиться к описанию таблицы регистрации изменений, которого во внутренней схеме уже или еще нет. Именно поэтому прямое создание физической таблицы в СУБД через SQL Management Studio не помогает: механизм SDBL не находит запись об объекте в метаописании 1С.

Шаг 1. Локализация проблемного объекта метаданных

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

Посмотрим на пример программного кода, который запускается во внешней обработке в режиме «1С:Предприятие» для поиска проблемного объекта:


ЧтоИщем = "_DocumentChngR35788";
СтруктураХранения = ПолучитьСтруктуруХраненияБазыДанных(, Истина); 

Для Каждого Таблица Из СтруктураХранения Цикл
    Если Таблица.ИмяТаблицыХранения = ЧтоИщем Тогда
        Сообщить("Имя таблицы: " + Таблица.ИмяТаблицы + " (метаданные: " + Таблица.Метаданные + ", назначение: " + Таблица.Назначение + ")");
        Прервать;
    КонецЕсли;
КонецЦикла;

Если код не вернул результат в текущей базе, развернем архивную копию базы (до попытки обновления) либо промежуточную тестовую базу и выполним поиск там. Альтернативный способ диагностики — выгрузить конфигурацию в файлы XML через меню «Конфигурация — Выгрузить конфигурацию в файлы...» и выполнить глобальный поиск числа 35788 по содержимому каталога. Это позволит точно узнать имя документа.

Шаг 2. Корректировка состава планов обмена

Рассмотрим основной прикладной способ решения, не требующий прямого вмешательства в базу данных на уровне SQL. Так как сбой возникает при попытке реструктуризации таблиц регистрации изменений, рассинхронизацию можно снять путем временного вывода объекта из состава планов обмена:

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

Шаг 3. Очистка кэша кластера и аварийного состояния реструктуризации

Если конфигуратор аварийно завершил работу во время обновления, в служебных таблицах СУБД фиксируется состояние незавершенной транзакции реструктуризации. Проанализируем, как сбросить зависшие данные.

Обязательно создадим полную резервную копию базы данных средствами СУБД перед выполнением следующих действий:

Полностью остановим службу сервера 1C:Enterprise 8.3 Server Agent.
Очистим серверный кэш метаданных: в каталоге данных кластера (по умолчанию C:\Program Files\1cv8\srvinfo\...) удалим временные папки с префиксами snacc.
Если конфигуратор завис в состоянии обновления, в рабочей базе данных СУБД выполним SQL-запрос для очистки таблицы несохраненной конфигурации: DELETE FROM ConfigSave; Это действие возвращает конфигуратор к последней стабильно зафиксированной конфигурации базы данных.
Запустим службу сервера 1С.

Шаг 4. Сброс бинарного кэша схемы данных (DBSchema)

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

На резервной копии базы в СУБД выполним запрос на удаление бинарного слепка схемы: DELETE FROM Params WHERE FileName = 'DBSchema';
Запустим конфигуратор базы в монопольном режиме.
При открытии конфигуратора и первой попытке верификации платформа обнаружит отсутствие кэшированной схемы DBSchema и выполнит полное сканирование текущих объектов метаданных, заново генерируя корректное описание внутренней структуры.
Выполним проверку конфигурации и тестирование и исправление базы данных.

Шаг 5. Пошаговое накатывание релизов и режим совместимости

Если ошибка возникла при попытке обновить информационную базу сразу через несколько релизов («пакетное обновление»), критически важно изменить подход к обновлению. В различных релизах типовых конфигураций может изменяться режим совместимости (например, переход с версии 8.3.14 на 8.3.17). При пропуске промежуточных релизов платформа не успевает выполнить процедуры переноса данных версионирования и регистрации изменений.

Разберем правильный порядок действий:

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

Для гарантированного исключения проблем с динамическим обновлением применим запуск обновления конфигурации базы данных через командную строку с ключом монопольной реструктуризации:

1cv8.exe DESIGNER /S "ИмяСервера\ИмяБазы" /UpdateDBCfg -Dynamic-

Параметр -Dynamic- запрещает использование механизма фонового обновления и форсирует прямое применение структуры данных, что сводит к минимуму риск рассинхронизации таблиц планов обмена.