Почему при запуске базы 1С создается множество сеансов с пустым пользователем и как это исправить?

← На главную

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

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

Физика процесса: почему множатся пустые сеансы?

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

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

Рассмотрим основные причины, которые приводят к подобному поведению системы:

Несовпадение версий платформы 1С при выгрузке и загрузке. Это самая распространенная причина. Если файл .dt был выгружен на более новой (или существенно отличающейся) версии платформы, а загружается на сервер под управлением более старого релиза, бинарная структура внутренних таблиц конфигурации при распаковке может быть интерпретирована неверно. При запуске это вызывает тихий критический сбой ядра платформы.
Зацикливание фоновых и регламентных заданий. При старте базы БСП пытается запустить фоновые процедуры обновления. Если база повреждена или возник конфликт метаданных, эти фоновые задания аварийно завершаются, и система мгновенно порождает новые попытки запуска, создавая десятки пустых сеансов.
Повреждение внутренней структуры базы или таблицы пользователей. При переносе через формат .dt иногда нарушается целостность служебных таблиц СУБД, отвечающих за список пользователей.
Конфликт кэша сервера приложений. Если новая база загружается взамен старой с тем же уникальным идентификатором (UID) базы в кластере, серверные рабочие процессы могут использовать старые кэшированные схемы метаданных, вызывая сбой инициализации.

---

Шаг 1. Проверка и выравнивание версий платформ

Проанализируем главный фактор сбоя — разницу версий платформы 1С. Настоятельно рекомендуется всегда соблюдать правило: версия платформы, на которой выполняется загрузка файла .dt, должна в точности соответствовать версии платформы, на которой этот файл был выгружен.

Если базу вам прислал сторонний клиент или контрагент, обязательно выясните у него точный номер релиза платформы (например, 8.3.22.1709). Если такой возможности нет, выполните следующие действия:

Установите на сервере (или на локальной машине для тестов) наиболее актуальную и стабильную версию платформы 1С.
Попробуйте выполнить развертывание базы локально в файловом варианте. Файловый вариант гораздо более лоялен к мелким несоответствиям структуры и позволит локализовать проблему.

---

Шаг 2. Временное отключение регламентных и фоновых заданий

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

Способ А. Через консоль администрирования кластера серверов 1С

Если база развернута на сервере приложений 1С, выполните следующие шаги:

Откройте утилиту «Администрирование серверов 1С Предприятия».
Найдите вашу информационную базу в списке.
Откройте свойства базы данных (потребуется ввести имя и пароль администратора базы, если они заданы).
Установите флаг «Блокировка регламентных заданий включена» (в некоторых версиях параметр называется «Блокировка начала сеансов» или «Блокировка регламентных заданий»).
Нажмите «Применить» и «ОК». Это заблокирует автоматический запуск фоновых процессов, которые перегружают сервер.

Способ Б. Использование параметров командной строки при запуске

Мы можем запустить систему в обход планировщика задач с помощью специального ключа запуска. Для этого откроем командную строку (cmd) и запустим тонкий или толстый клиент со специальным ключом /AllowExecuteScheduledJobs -Off.

Посмотрим на пример командного файла для аварийного запуска:


"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" ENTERPRISE /S "ServerName\BaseName" /N "Администратор" /P "Пароль" /AllowExecuteScheduledJobs -Off /ClearCache

Параметр /AllowExecuteScheduledJobs -Off запрещает выполнение любых регламентных заданий в рамках данного запуска, а параметр /ClearCache очищает локальный кэш метаданных клиента, исключая влияние старых настроек.

---

Шаг 3. Локальное тестирование и лечение через файловый режим

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

Выполним процедуру по шагам:

Создайте на своем локальном компьютере пустую файловую информационную базу.
Запустите Конфигуратор этой базы и выполните импорт вашего файла .dt (меню Администрирование — Загрузить информационную базу...).
Если загрузка прошла успешно, не спешите запускать режим Предприятия. Сначала запустите процедуру Тестирования и Исправления (меню Администрирование — Тестирование и исправление...).
В настройках ТИИ выберите следующие пункты:
- Реиндексация таблиц информационной базы;
- Проверка целостности логической структуры;
- Проверка целостности ссылочной структуры;
- Реструктуризация таблиц информационной базы.
Нажмите кнопку «Выполнить». Дождитесь окончания процесса. Если в структуре были ошибки несовместимости, платформа исправит их под текущую версию.
Дополнительно рекомендуется закрыть Конфигуратор и пройтись по файлу базы данных 1Cv8.1CD утилитой проверки физической целостности chdbfl.exe (она находится в каталоге bin установленной платформы).
После успешного исправления запустите базу локально в режиме «1С:Предприятие». Дайте ей выполнить все внутренние процедуры обновления БСП.
После того как база успешно откроется в файловом режиме, вернитесь в Конфигуратор и выгрузите ее в новый файл .dt. Этот «чистый» файл теперь можно безбоязненно загружать на рабочий сервер СУБД.

---

Шаг 4. Очистка серверного кэша и пересоздание базы в СУБД

Часто сервер приложений 1С «запоминает» старое состояние базы данных, если загрузка .dt производилась поверх уже существовавшей ранее ИБ с тем же именем. Чтобы полностью исключить кэш-зависимость, выполним следующие действия:

В консоли администрирования 1С полностью удалите проблемную информационную базу (при удалении выберите вариант сохранения базы в СУБД или удалите ее полностью, если данные не нужны).
Зайдите на сервер СУБД (например, MS SQL Server или PostgreSQL) и вручную удалите физическую базу данных.
Создайте абсолютно новую базу данных в СУБД с другим именем (чтобы избежать наложения кэша индексов).
В кластере серверов 1С зарегистрируйте новую информационную базу под новым именем, привязав ее к свежесозданной БД на сервере СУБД.
Запустите Конфигуратор новой базы и выполните загрузку файла .dt.

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

---

Совет эксперта: почему стоит избегать формата .dt для больших баз?

В заключение отметим важный архитектурный нюанс работы с платформой 1С. Файл формата .dt не является полноценным бэкапом базы данных в промышленном понимании. Это лишь оптимизированный платформонезависимый архив логической структуры и данных. При его выгрузке и последующей загрузке платформа выполняет колоссальный объем работы по конвертации данных из СУБД в XML-подобный поток и обратно.

Если вы делаете копию базы в рамках одного сетевого контура (например, создаете тестовую базу из рабочей), всегда используйте встроенные средства СУБД. Резервная копия базы данных MS SQL (файл .bak) или дамп базы PostgreSQL создаются и разворачиваются в разы быстрее, не содержат логических ошибок конвертации платформы 1С и гарантируют 100% идентичность физической структуры баз данных, полностью предотвращая появление подобных проблем с пустыми сеансами.