Обновление типовых конфигураций 1С — процедура стандартная, но иногда она превращается в настоящий квест из-за особенностей конкретных релизов платформы. Одной из наиболее резонансных проблем в начале 2021 года стала нестабильность платформы 8.3.17.1851. Пользователи массово сталкивались с ситуацией, когда при обновлении «1С:Бухгалтерии» (например, с версии 3.0.88 на 3.0.89) в момент реструктуризации данных происходил критический сбой. В этой статье мы подробно разберем, почему возникает ошибка v8srvr://.../Params/DBNames, что на самом деле означает сообщение «Сеанс завершен администратором» и как успешно завершить обновление, сохранив целостность базы.
Когда при принятии изменений конфигурации система выдает ошибку выполнения файловой операции в папке Params, это свидетельствует о критическом сбое в работе рабочего процесса сервера 1С (rphost.exe). Проблема заключается в том, что платформа теряет связь с файлами описания структуры базы данных, которые хранятся в служебных таблицах СУБД под общим заголовком Params.
В результате такого «вылета» база данных может остаться в промежуточном состоянии. Самое неприятное последствие — разрушение таблицы пользователей. Платформа перестает сопоставлять учетные записи пользователей ИБ с записями в SQL-базе, и при следующей попытке входа вы получаете сообщение «Пользователь ИБ не идентифицирован». Это происходит из-за того, что транзакция записи метаданных прерывается аварийно, оставляя индексы в несогласованном виде.
Многие администраторы впадают в замешательство, видя сообщение о завершении сеанса администратором, когда точно знают, что никто из коллег не заходил в консоль кластера. Давайте выясним истинную причину. В 1С это сообщение является универсальной «заглушкой» в случаях, когда клиентское приложение (Конфигуратор или Тонкий клиент) внезапно теряет связь с рабочим процессом сервера.
Проанализируем ситуацию: на релизе 8.3.17.1851 наблюдались проблемы с управлением памятью. Если процесс реструктуризации требует значительных ресурсов, rphost может аварийно завершиться (упасть) по ошибке Access Violation. Для кластера 1С это выглядит как исчезновение процесса, и всем подключенным клиентам выдается стандартное уведомление о завершении сеанса. Таким образом, «администратор» здесь ни при чем — это системный сбой платформы.
Как показывает практика и обсуждения специалистов, обычный перезапуск службы 1C:Enterprise 8.3 Server Agent часто оказывается недостаточным. Рассмотрим, почему помогает только полная перезагрузка операционной системы сервера:
srvinfo (в частности, в подпапках snacc), что критично при возникновении ошибок с DBNames.rphost была фрагментация памяти или утечки, чистый запуск ОС даст необходимый ресурс для выполнения тяжелой операции реструктуризации.Перед повторным запуском обновления после перезагрузки настоятельно рекомендуется выполнить очистку кэша конфигурации на сервере вручную.
Одной из причин падения процессов во время обновления является конфликт реструктуризации с фоновыми заданиями. Рассмотрим, как правильно подготовить базу. Даже если вы поставили галочку блокировки в консоли, некоторые системные процессы могут инициироваться платформой. Для надежности воспользуемся программным методом управления блокировкой через объект БлокировкаСеансов.
Проанализируем пример кода, который позволяет установить блокировку регламентных заданий перед началом работ:
КодПароль = "SecretKey";
ПараметрыБлокировки = МенюАдминистрирование.СоздатьБлокировкуСеансов();
ПараметрыБлокировки.Начало = ТекущаяДата();
ПараметрыБлокировки.КодРазрешения = КодПароль;
ПараметрыБлокировки.Установлена = Истина;
ПараметрыБлокировки.Сообщение = "Выполняется критическое обновление системы. Доступ ограничен.";
УстановитьБлокировкуСеансов(ПараметрыБлокировки);
Также полезно использовать утилиты rac и ras для административного управления кластером. Это позволяет автоматизировать отключение заданий сразу во всех базах на сервере, что особенно актуально, если у вас их несколько десятков.
Если база данных большая и обновление постоянно вылетает, попробуем изменить стратегию распределения нагрузки в консоли администрирования кластера 1С. Разберем шаги:
Это заставит сервер выделить для вашей базы отдельный процесс rphost. В этом случае влияние других баз и их фоновых заданий будет полностью исключено, что повышает шансы на успешное завершение реструктуризации метаданных.
Учитывая коварство ошибки DBNames, выработаем алгоритм «безопасного пути»:
Помните, что при возникновении ошибки DBNames и «выносе» таблицы пользователей, наиболее быстрым способом восстановления является откат к SQL-бэкапу, сделанному непосредственно перед нажатием кнопки «Принять изменения». Попытки лечить разрушенную таблицу v8users вручную часто приводят к еще большим проблемам с логической целостностью данных.