Как исправить ошибку «Обнаружена незавершенная операция обновления конфигурации» в 1С на PostgreSQL?

← На главную

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

Разберем причину возникновения ошибки

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

Если в момент этого переноса происходит сбой — например, кратковременная потеря сетевого соединения, аварийное завершение процесса сервера 1С или СУБД — в таблице config остаются специальные маркеры-флаги (записи с именами commit или dbStruFinal). При следующем запуске система видит эти записи и понимает, что предыдущая транзакция по обновлению не была завершена корректно. Чтобы не допустить работу пользователей в «битой» конфигурации, 1С блокирует вход.

Способ 1: Использование штатного механизма отката конфигурации

Прежде чем переходить к прямому редактированию таблиц базы данных через SQL, рассмотрим более безопасный и штатный метод, который предоставляет сама платформа 1С. Посмотрим на параметр командной строки /RollbackCfg. Этот ключ предназначен именно для таких случаев — он заставляет платформу попытаться откатить незавершенные изменения конфигурации базы данных до последнего стабильного состояния.

Рассмотрим порядок действий для выполнения этой операции:

Завершим все зависшие сеансы пользователей и процессы rphost на сервере 1С.
Запустим командную строку (cmd) от имени администратора.
Выполним команду запуска конфигуратора с параметром отката. Для клиент-серверного варианта команда будет выглядеть так:


"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /S "ИмяСервера\ИмяБазы" /N "Логин" /P "Пароль" /RollbackCfg

Где 8.3.XX.XXXX — ваша версия платформы. После выполнения этой команды система проанализирует состояние служебных таблиц и, если повреждения не критичны, удалит блокирующие записи самостоятельно.

Способ 2: Ручная очистка служебных таблиц в PostgreSQL

Если штатный откат не помог, нам придется прибегнуть к «хирургическому» вмешательству на уровне СУБД. Выясним, какие таблицы нам нужны. В PostgreSQL, в отличие от MS SQL, названия таблиц могут зависеть от регистра и схемы (обычно это схема public). Нам понадобятся таблицы config и configsave.

Для работы нам потребуется инструмент pgAdmin или консольная утилита psql. Проанализируем алгоритм действий:

Обязательно создадим резервную копию базы данных средствами PostgreSQL (pg_dump)! Работа с таблицами напрямую всегда сопряжена с риском.
Откроем редактор SQL-запросов для нужной базы данных.
Проверим наличие данных в таблице временной конфигурации. Если там есть записи, их нужно удалить:

DELETE FROM "configsave";

Обратите внимание, что в PostgreSQL имена таблиц часто пишутся в нижнем регистре, но если при создании базы использовались кавычки, то и в запросе их нужно использовать. Если команда выше выдает ошибку, попробуйте DELETE FROM configsave; без кавычек.

Теперь удалим маркеры незавершенной транзакции из основной таблицы конфигурации. Выполним следующие запросы:


DELETE FROM "config" WHERE "filename" = 'commit';
DELETE FROM "config" WHERE "filename" = 'dynamicCommit';
DELETE FROM "config" WHERE "filename" = 'dbStruFinal';

В некоторых случаях маркеры могут называться иначе в зависимости от версии платформы. Вы можете проверить содержимое таблицы командой: SELECT * FROM "config" WHERE "filename" IN ('commit', 'dynamicCommit', 'dbStruFinal');. Если записи найдены — удаляйте их.

Особенности поиска таблиц в pgAdmin

Многие начинающие администраторы не могут найти нужные таблицы в интерфейсе pgAdmin. Разберем, где они находятся. После подключения к серверу разверните дерево объектов: Databases (Базы данных) -> Ваша_База -> Schemas (Схемы) -> public -> Tables (Таблицы). Именно здесь находятся все таблицы 1С. Если вы видите пустой список, убедитесь, что у пользователя, под которым вы зашли, достаточно прав для просмотра объектов схемы public.

Помните, что PostgreSQL чувствителен к регистру. Если вы создаете запрос вручную, лучше всегда использовать кавычки для имен таблиц и полей, например: SELECT * FROM "Config";, иначе СУБД может привести имя к нижнему регистру и не найти таблицу.

Важный этап: Очистка кэша сервера 1С

Даже после успешного выполнения SQL-запросов ошибка может сохраняться. Проанализируем, почему это происходит. Дело в том, что сервер приложений 1С активно кэширует структуру конфигурации в оперативной памяти и локальных файлах. Чтобы изменения в базе данных вступили в силу, нам необходимо «сбросить» этот кэш.

Выполним следующие шаги:

Остановим службу 1C:Enterprise 8.3 Server Agent.
Перейдем в каталог, где хранятся данные сервера (по умолчанию это C:\Program Files\1cv8\srvinfo).
Найдем папку с идентификатором вашей базы (UID). Внутри нее нас интересует папка snccntx — это и есть сеансовые данные и кэш конфигурации.
Удалим содержимое папки snccntx.
Запустим службу сервера 1С заново.

Профилактика и правильные бэкапы

Рассмотрим, как не допустить повторения ситуации. Главное правило: избегайте динамического обновления, если изменения касаются структуры данных (добавление реквизитов, изменение типов, создание новых объектов). Динамическое обновление безопасно только для правки кода в модулях, и то с оговорками.

Также важно пересмотреть подход к резервному копированию. На форумах часто упоминается выгрузка в .dt. Помните, что .dt — это не бэкап в строгом смысле слова. Это логическая выгрузка данных. Для базы на PostgreSQL правильным способом является использование встроенных средств СУБД:

Используйте pg_dump для создания ежедневных копий.
Настройте WAL-архивирование (Continuous Archiving), что позволит восстановить базу на любой момент времени (Point-in-Time Recovery).
Перед каждым обновлением (особенно динамическим) делайте быстрый «снимок» базы средствами PostgreSQL (через создание шаблона или CREATE DATABASE ... STRATEGY = 'FILECOPY' в новых версиях).

Таким образом, мы разобрали комплексный подход к решению проблемы: от мягкого отката средствами 1С до прямого редактирования таблиц в PostgreSQL. Соблюдение правил гигиены обновлений и использование профессиональных инструментов СУБД позволит вам минимизировать риски простоя базы данных.