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

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

Почему зависают другие базы на сервере 1С

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

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

1. Перезапустим службу агента сервера 1C:Enterprise Server Agent.
2. Очистим сеансовые данные и кэш сервера: для этого остановим службу 1С, перейдем в каталог srvinfo (или каталог соответствующего кластера) и временно переместим содержимое кэша и временных файлов в резервную папку.
3. Запустим службу сервера 1С заново и проверим доступность неповрежденных баз.

Способ 1. Откат изменений через командную строку Конфигуратора

Если сервер ожил, но проблемная информационная база по-прежнему не запускается и не пускает в конфигуратор через графический интерфейс, применим пакетный режим запуска платформы с ключом отката незафиксированной конфигурации.

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

"C:\Program Files (x86)\1cv82\common\1cestart.exe" DESIGNER /S "ИмяСервера\ИмяБазы" /RollbackCfg /DisableStartupMessages

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

Способ 2. Очистка временных таблиц конфигурации в Microsoft SQL Server

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

В момент динамического обновления платформа использует таблицу ConfigSave для хранения промежуточного состояния метаданных. При сбое в ней могут остаться некорректные записи. Очистим эту таблицу прямым запросом:

USE [ИмяБазы1С]
GO
TRUNCATE TABLE [dbo].[ConfigSave]
GO

Также удалим «зависшие» служебные записи фиксации транзакций из основных таблиц метаданных:

USE [ИмяБазы1С]
GO
DELETE FROM [dbo].[Config] WHERE [FileName] LIKE '%commit%'
GO
DELETE FROM [dbo].[Params] WHERE [FileName] LIKE '%commit%'
GO

После выполнения скрипта перезапустим службу сервера 1С и проверим запуск базы в режиме конфигуратора.

Способ 3. Восстановление таблицы Config из резервной копии

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

Разберем пошаговый алгоритм:

1. Развернем свежий бэкап базы данных (например, ночную копию) на SQL-сервере под временным именем BackupBase.
2. Создадим резервную копию текущей сбойной рабочей базы WorkBase.
3. Остановим службу сервера 1С:Предприятие, чтобы разорвать все активные сеансы и соединения.
4. Выполним перенос записей таблицы конфигурации из бэкапа в рабочую базу следующим T-SQL скриптом:

USE [WorkBase]
GO
TRUNCATE TABLE [dbo].[Config]
GO
INSERT INTO [WorkBase].[dbo].[Config] 
SELECT * FROM [BackupBase].[dbo].[Config]
GO
TRUNCATE TABLE [dbo].[ConfigSave]
GO

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

Рекомендации по предотвращению подобных сбоев

Чтобы избежать аварийных остановок рабочих процессов и повреждения метаданных в будущем, придерживаемся следующих правил:

1. Полностью откажемся от динамического обновления на рабочих базах, особенно при изменениях в структурах данных, общих модулях и подсистемах.
2. Для плановых обновлений используем монопольный режим с предварительной блокировкой соединений с помощью свойства УстановитьБлокировкуСеансов() или через стандартную консоль кластера серверов 1С.
3. Разделяем критически важные базы по разным рабочим серверам или процессам с помощью настройки требований назначения функциональности в кластере, чтобы сбой в одной конфигурации не блокировал доступ к остальным информационным базам.