Как исправить ошибку relation does not exist в PostgreSQL после сбоя обновления 1С?

← На главную

При обновлении конфигурации или реструктуризации базы данных 1С на СУБД PostgreSQL может произойти аварийное завершение процесса. В результате конфигуратор и клиентское приложение перестают запускаться, выдавая критическую ошибку вида ERROR: relation "_referenceXXXX" does not exist. При этом выгрузка базы в файл .dt блокируется, попытки реструктуризации завершаются аварией, а прямое внесение изменений в метаданные становится невозможным. Рассмотрим подробно причины возникновения этого сбоя и пошаговые методы восстановления работоспособности информационной базы.

Причины возникновения ошибки и рассинхронизации метаданных

Прежде чем приступать к восстановлению, разберем механизм работы платформы со структурой СУБД:

Нарушение транзакции DDL: В процессе применения изменений конфигурации платформа отправляет в PostgreSQL команды создания новых физических таблиц (например, CREATE TABLE). Если в этот момент происходит сбой по таймауту, нехватке оперативной памяти или обрыву соединения, транзакция в СУБД может откатиться, в то время как внутренний список объектов 1С в таблице Params (запись DBNames) уже зафиксировал факт создания объекта.
Именование служебных таблиц: Префикс _reference в структуре базы 1С резервируется исключительно за объектами типа «Справочник» (таблицы документов имеют префикс _document). Если в конфигурацию добавлялся документ с новым реквизитом ссылочного типа или создавался новый справочник, платформа ожидает увидеть соответствующую таблицу в схеме данных.
Зависание промежуточного состояния: При аварийном завершении реструктуризации несохраненные данные конфигурации остаются в таблице ConfigSave, блокируя последующие попытки открыть или изменить метаданные через конфигуратор.

Способ 1. Создание таблицы-заглушки напрямую в PostgreSQL

Если конфигуратор наглухо заблокирован и падает при запуске с сообщением об отсутствии таблицы, наиболее быстрый способ обойти блокировку — создать отсутствующую таблицу вручную через pgAdmin или консоль psql. Это позволит платформе успешно инициализировать метаданные и перейти в штатный режим работы.

Для создания минимального каркаса таблицы справочника с именем, указанным в ошибке (например, _reference5091), выполним следующий SQL-запрос:


CREATE TABLE _reference5091 (
    _idrref bytea NOT NULL,
    _version bytea NOT NULL,
    _marked boolean NOT NULL,
    _predefinedid bytea NOT NULL,
    _code varchar,
    _description varchar,
    CONSTRAINT _reference5091_pkey PRIMARY KEY (_idrref)
);

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

Подключаемся к базе данных через консоль администрирования PostgreSQL и выполняем скрипт создания таблицы.
Запускаем 1С в режиме Конфигуратор. Платформа обнаружит физическую таблицу и завершит инициализацию без ошибки does not exist.
Если при открытии метаобъекта система выдает ошибки об отсутствии конкретных реквизитов (колонок таблицы), добавляем недостающие поля через ALTER TABLE с соответствующим типом данных (например, _fldXXXX bytea или _fldXXXX numeric).
Заходим в меню Администрирование — Тестирование и исправление..., выбираем флаг Реструктуризация таблиц информационной базы и запускаем процесс. Платформа приведет структуру физической таблицы к полному соответствию с метаданными конфигурации.
При необходимости удаляем ошибочно созданный объект метаданных стандартными средствами конфигуратора и повторно применяем изменения.

Способ 2. Сброс незафиксированного обновления в СУБД

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

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

TRUNCATE TABLE configsave;

После выполнения команды запускаем конфигуратор. Он перестанет обращаться к незавершенным изменениям и загрузит стабильную версию метаданных из таблицы Config.

Решение сопутствующих проблем при переносе и восстановлении данных

Нередко при попытках реанимировать базу данных специалисты сталкиваются с цепочкой вторичных технических препятствий. Рассмотрим методы их преодоления.

1. Превышение размера файла 1CD при попытке загрузки в файловую базу

Ошибка вида «Превышен максимально допустимый размер внутреннего файла 1Cv8.1CD» возникает из-за архитектурного ограничения формата файловой базы 1С: размер любой внутренней таблицы (включая индексы и бинарные данные) не может превышать 4 ГБ. Если база превысила этот объем, развернуть выгрузку .dt локально в файловом варианте технически невозможно. Восстановление и тестирование необходимо выполнять исключительно на клиент-серверной архитектуре (на тестовом экземпляре PostgreSQL или MS SQL Server).

2. Ошибка СУБД «ERROR: out of memory» при тяжелых запросах

При проведении групповых документов, закрытии месяца или загрузке больших массивов данных PostgreSQL может аварийно завершать процессы с ошибкой выделения памяти (например, при запросе блока размером 256 МБ). Это связано с выбором оптимизатором планов соединения методом слияния (Merge Join), требующим значительных непрерывных объемов оперативной памяти.

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

SET enable_mergejoin = off;

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

3. Сбой чтения XML при переносе документов

Если данные переносятся с помощью универсальной обработки обмена через XML, процесс загрузки может прерываться ошибкой Ошибка преобразования данных XML с указанием конкретной строки и позиции (колонки) в файле. Причиной служат непечатные управляющие символы (ASCII-символы с кодами от 0x00 до 0x1F), попавшие в строки документов из внешних источников или буфера обмена. XML-парсер платформы не может разобрать такие символы по стандарту XML 1.0.

Для обнаружения и нейтрализации подобных данных используем встроенную функцию платформы НайтиНедопустимыеСимволыXML():


ПозицияОшибки = НайтиНедопустимыеСимволыXML(ТекстДанных);
Если ПозицияОшибки > 0 Тогда
    // Обрабатываем или вырезаем некорректный символ
КонецЕсли;

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

4. Ошибка SDBL «тип поля несовместим с типом литерала»

Появление этой ошибки на отдельных рабочих местах после частичной реструктуризации указывает на использование устаревшего локального кэша метаданных. Транслятор запросов SDBL на клиенте генерирует запрос к СУБД, не соответствующий обновленным типам колонок в базе. Решением является полное удаление пользовательского кэша 1С (каталоги 1C/1cv8 в профилях пользователей AppData\Local и AppData\Roaming), а также перезапуск службы сервера 1С для обновления серверного кэша структур хранения.