Что делать, если не работает динамическое обновление на сервере 1С и пропала кнопка обновления?

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

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

Метод 1. Полная принудительная очистка кэша сервера 1С и перезапуск служб через BAT-скрипт

Очень часто штатная перезагрузка службы сервера 1С:Предприятие через стандартную консоль Services.msc в Windows не приводит к желаемому результату. Причина кроется в том, что процессы rphost.exe или rmngr.exe могут зависнуть в памяти в состоянии ожидания ("зомби-процессы"), продолжая удерживать блокировки файлов метаданных. При этом кэш сеансов в каталоге реестра кластера остается заблокированным.

Для гарантированного решения этой проблемы применим проверенный метод жесткой остановки всех взаимосвязанных процессов 1С и удаления временных файлов кэша. Создадим и запустим специальный командный файл (с расширением .bat) от имени администратора на сервере приложений 1С:

@echo off
set LOG_FILE="scripts.log"
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-64)"
set SERVICE_RAS_NAME="1C:Enterprise 8.3 Remote Server"
set CNTX_PATH="C:\srvinfo\reg_1541"
set PFL_PATH="C:\ProgramData\1C\1cv8"
set TEMP_PATH="C:\Windows\Temp"

echo stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%

sc stop %SERVICE_1C_NAME%
sc stop %SERVICE_RAS_NAME%
timeout 5

taskkill /f /im "rphost.exe"
taskkill /f /im "rmngr.exe"
taskkill /f /im "ragent.exe"
taskkill /f /im "ras.exe"
timeout 5

echo done stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
echo clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%

DEL /Q /F /S %CNTX_PATH%\snccntx*
DEL /Q /F %PFL_PATH%\*.pfl
DEL /Q /F /S %TEMP_PATH%\*.*

echo done clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
sc start %SERVICE_1C_NAME%

Разберем подробнее, что делает данный сценарий:

1. Остановка служб: Командами sc stop отправляется запрос на остановку основных служб сервера 1С.
2. Принудительное завершение процессов: Утилита taskkill с флагом /f жестко выгружает из оперативной памяти все уцелевшие рабочие процессы rphost.exe, менеджеры кластера rmngr.exe, агент сервера ragent.exe и сервер администрирования ras.exe.
3. Очистка серверного кэша сеансов: Удаляются файлы кэша сеансовых данных snccntx в каталоге реестра кластера 1С (папка reg_1541). Именно в этих файлах часто зависает ложная информация об активных пользовательских соединениях.
4. Очистка временных файлов ОС: Удаляются временные файлы из папки C:\Windows\Temp, которые сервер 1С использует при сборке пакетов метаданных конфигурации.
5. Запуск службы: Служба сервера 1С запускается заново, инициализируя чистый кэш в оперативной памяти.

Метод 2. Чистая переустановка службы сервера «1С:Предприятие»

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

Выполним этот процесс по шагам:

1. Создание резервной копии данных: Обязательно сделаем резервную копию каталога реестра кластера 1С (по умолчанию это папка C:\Program Files\1cv8\srvinfo или C:\srvinfo), а также создадим бэкапы всех критически важных баз на уровне СУБД (MS SQL Server / PostgreSQL).
2. Удаление старой платформы: Через «Панель управления» Windows удалим текущую версию сервера «1С:Предприятие». При удалении файлы настроек баз и лицензии не затрагиваются, но подстраховка в виде бэкапа необходима.
3. Очистка остаточных файлов: Проверим системный каталог установки C:\Program Files\1cv8\ и удалим папку с номером удаленного релиза платформы, если там остались какие-то библиотеки.
4. Установка платформы заново: Запустим инсталлятор платформы 1С аналогичного релиза. В списке компонентов выберем «Сервер 1С:Предприятия» и «Администрирование сервера 1С:Предприятия». Рекомендуется устанавливать серверную службу от имени специально созданного локального пользователя (например, USR1CV8), предоставив ему необходимые права на чтение и запись папки с данными кластера srvinfo.
5. Восстановление работоспособности: После успешной установки служба сервера запустится автоматически, подтянув настройки старого кластера из сохраненного реестра. Практика показывает, что переустановка платформы полностью решает проблему заблокированных внутренних механизмов синхронизации вызовов.

Метод 3. Сброс зависших фоновых обновлений конфигурации базы данных

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

В этом состоянии сервер 1С программно блокирует любые попытки динамического обновления. Чтобы исправить это, нам необходимо принудительно отменить зависшее фоновое обновление через командную строку запуска конфигуратора. Выполним следующие действия:

1. Откроем командную строку (cmd) на сервере или рабочем компьютере администратора.
2. Выполним команду отмены фонового обновления, указав параметры подключения к нашей серверной базе данных:

"C:\Program Files\1cv8\8.3.14.1630\bin\1cv8.exe" DESIGNER /S"ИмяСервера\ИмяБазы" /N"Администратор" /P"Пароль" /UpdateDBCfg -BackgroundCancel

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

Метод 4. Снятие скрытых блокировок на уровне СУБД (MS SQL / PostgreSQL)

Иногда корень проблемы кроется непосредственно на уровне сервера баз данных. При некорректно завершенных сеансах или незакрытых транзакциях СУБД может удерживать монопольные блокировки на системные таблицы 1С, хранящие конфигурацию приложения. Речь идет о таблицах Config, ConfigSave, DBSchema и ConfigCas.

Если сервер 1С опрашивает СУБД перед обновлением и получает отказ в монопольном доступе к таблице ConfigSave, он автоматически скрывает кнопку динамического обновления, считая среду небезопасной.

Для исправления этой ситуации выполним следующие шаги:

1. Перезапуск службы СУБД: Самый простой способ сбросить все транзакционные блокировки таблиц — перезагрузить службу СУБД (например, SQL Server (MSSQLSERVER) или службу PostgreSQL). Выполнять это рекомендуется во время технологического окна, когда пользователи гарантированно не работают с другими базами на этом сервере.
2. Анализ блокировок в MS SQL Server: Если перезапуск службы СУБД невозможен, откроем SQL Server Management Studio (SSMS) и выполним встроенную системную процедуру sp_who2 или проверим активные транзакции с помощью следующего запроса:

SELECT 
    request_session_id AS Spid,
    DB_NAME(resource_database_id) AS DatabaseName,
    resource_type AS ResourceType,
    request_mode AS RequestMode,
    request_status AS RequestStatus
FROM sys.dm_tran_locks
WHERE resource_database_id = DB_ID('ИмяВашейБазы1С');

Если обнаружены зависшие сеансы, которые удерживают эксклюзивные блокировки (режим X или IX), мы можем принудительно завершить их командой KILL [номер_сеанса_spid].

Метод 5. Отключение веб-сервисов и "призрачных" сеансов OData/COM

Часто администратор базы данных ориентируется исключительно на утилиту «Консоль администрирования кластера 1С», проверяя вкладку «Сеансы». Если там пусто, делается ложный вывод об отсутствии подключений. Однако внешние интеграционные механизмы, такие как опубликованные Web-сервисы, HTTP-сервисы или REST API (интерфейс OData), могут генерировать так называемые "призрачные" короткие сеансы, которые создаются на доли секунды в пуле соединений веб-сервера (IIS или Apache).

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

1. Если база опубликована на IIS, откроем диспетчер служб IIS и остановим соответствующий пул приложений или весь веб-сайт, на котором размещена публикация базы 1С.
2. Если используется Apache, выполним остановку службы веб-сервера командой httpd -k stop или через системную консоль служб Windows.
3. Попробуем запустить Конфигуратор 1С и выполнить обновление конфигурации базы данных. После успешного обновления запустим веб-сервер обратно.

Метод 6. Реструктуризация таблиц после перехода на новые релизы платформы

Если информационная база была перенесена со старых версий платформы (например, с релизов 8.3.10 или 8.3.12) на более современную платформу 8.3.14+, внутренняя структура хранения бинарных данных конфигурации (блобов) в таблице СУБД может не соответствовать новым механизмам платформы. Без проведения первичной реструктуризации новые алгоритмы динамического обновления могут быть заблокированы программно самой платформой.

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

1. Запустим конфигуратор 1С в монопольном режиме.
2. Перейдем в меню Администрирование -> Тестирование и исправление...
3. Установим флаг напротив пункта «Реструктуризация таблиц информационной базы». Остальные флаги можно временно снять для экономии времени.
4. Нажмем кнопку Выполнить и дождемся окончания процесса. Для крупных баз данных (таких как 1С:ERP) этот процесс может занять значительное время, поэтому его следует запускать во внерабочие часы.

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