Почему после обновления платформы 1С пропадает связь с SQL-сервером и как вернуть исчезнувшие базы

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

Представьте стандартную ситуацию: вам потребовалось обновить платформу «1С:Предприятие 8.3» на сервере. Вы аккуратно деинсталлировали старый релиз, установили новый, проверили запуск служб — процессы ragent.exe, rphost.exe и rmngr.exe успешно запустились в диспетчере задач. Однако при открытии консоли администрирования серверов 1С вы обнаруживаете полную пустоту: список информационных баз пуст, а при попытке зарегистрировать базу заново или подключиться к MS SQL Server система выдает ошибку связи.

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

Главная причина: разрядность платформы 1С и пути к файлам конфигурации srvinfo

Основная причина, по которой после обновления могут «исчезнуть» все информационные базы, заключается в несовпадении разрядности (архитектуры) старой и новой установленных платформ. Служба Агента сервера 1С (ragent) хранит все настройки кластера, включая список зарегистрированных баз, адреса СУБД, настройки рабочих процессов и журналы регистрации в специальном рабочем каталоге srvinfo. Местоположение этого каталога по умолчанию жестко привязано к архитектуре установленного приложения:

  1. 64-разрядный сервер 1С (x64) по умолчанию ищет файлы конфигурации по пути: C:\Program Files\1cv8\srvinfo
  2. 32-разрядный сервер 1С (x86) по умолчанию обращается к пути: C:\Program Files (x86)\1cv8\srvinfo

Если до обновления у вас функционировал 64-битный сервер, а при установке нового релиза вы по ошибке выбрали 32-битную версию платформы (или наоборот), то вновь запущенная служба Агента сервера создаст абсолютно чистый каталог srvinfo в своей директории по умолчанию. В результате старый файл настроек кластера 1CV8Clst.lst останется нетронутым в соседней папке, а консоль администрирования покажет чистый лист без баз.

Разберем по шагам: восстановление баз путем правильной установки платформы

Если на сервере изначально использовалась 64-разрядная версия платформы, самым правильным и безопасным решением будет установка аналогичной архитектуры нового релиза. Давайте проанализируем этот процесс:

  1. Остановите службу сервера 1С. Для этого откройте оснастку «Службы» (выполните команду services.msc), найдите службу 1C:Enterprise 8.3 Server Agent (или аналогичную вашей версии) и нажмите «Остановить».
  2. Удалите ошибочно установленную 32-разрядную версию платформы через панель управления Windows («Программы и компоненты»).
  3. Запустите инсталлятор платформы 1С нужной разрядности (в нашем случае — x64) и выполните установку, выбрав установку сервера 1С:Предприятия.
  4. Убедитесь, что служба Агента сервера успешно запустилась. Поскольку разрядность теперь совпадает с предыдущей версией, служба автоматически обратится к каталогу C:\Program Files\1cv8\srvinfo, подтянет старый файл настроек 1CV8Clst.lst, и все ваши базы мгновенно появятся в консоли администрирования с сохранением всех настроек связи с SQL-сервером.

Альтернативное решение: ручной перенос конфигурационных файлов

Если вам по какой-то причине действительно необходимо перейти с одной разрядности сервера на другую, настройки кластера можно перенести вручную. Рассмотрим подробнее этот алгоритм:

  1. Остановите службу Агента сервера 1С через консоль служб Windows.
  2. Перейдите в каталог старой версии (например, C:\Program Files\1cv8\srvinfo) и полностью скопируйте все его содержимое, включая подпапки с именами кластеров (например, каталог reg_1541) и файлы настроек.
  3. Перейдите в каталог новой версии (например, C:\Program Files (x86)\1cv8\srvinfo) и удалите оттуда автоматически созданные пустые файлы, если они там появились.
  4. Вставьте скопированные ранее данные в новый каталог.
  5. Запустите службу сервера 1С. Теперь служба считает старые настройки из нового места, и базы отобразятся в консоли.

Тонкая настройка: изменение пути к srvinfo через реестр Windows

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

  1. Откройте редактор реестра Windows. Для этого нажмите сочетание клавиш Win + R, введите команду regedit и нажмите Enter.
  2. Перейдите по следующему пути: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\.
  3. Найдите ветку вашей службы. Для 64-битного сервера это обычно 1C:Enterprise 8.3 Server Agent (x86-64), для 32-битного — 1C:Enterprise 8.3 Server Agent.
  4. В правой части окна найдите строковый параметр с именем ImagePath. Этот параметр содержит команду запуска исполняемого файла службы с ключами.
  5. Дважды кликните по параметру ImagePath для его редактирования. Строка запуска выглядит примерно следующим образом:
  6. 
    "C:\Program Files\1cv8\8.3.22.1709\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo"
    
  7. Обратите внимание на ключ -d. Именно этот параметр указывает Агенту сервера, где находится рабочий каталог кластера.
  8. Измените путь в кавычках после ключа -d на тот каталог, где лежат ваши актуальные файлы настроек (например, перенаправьте службу на папку "C:\Program Files\1cv8\srvinfo").
  9. Нажмите «ОК», закройте редактор реестра и запустите службу сервера 1С.

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

Проблема разрядности драйверов СУБД (MS SQL Client / OLE DB)

Смена разрядности сервера 1С влечет за собой необходимость проверки драйверов базы данных. Многие администраторы забывают, что сервер 1С общается с SQL-сервером не напрямую, а через клиентские компоненты (драйверы СУБД), установленные в операционной системе Windows. Здесь действует строгое правило:

  1. 32-разрядный процесс сервера 1С (rphost.exe) требует наличия 32-битных версий драйверов доступа к СУБД.
  2. 64-разрядный процесс сервера 1С (rphost.exe) требует исключительно 64-битных версий драйверов СУБД.

Если на вашем сервере установлен только 32-битный клиент SQL, то при переходе сервера 1С на 64-разрядную версию вы получите ошибку отсутствия связи с базой данных, даже если перенесете все файлы настроек идеально. При появлении ошибок соединения обязательно проверьте наличие соответствующего OLE DB-провайдера нужной разрядности в операционной системе. Мы рекомендуем использовать современные универсальные драйверы, такие как Microsoft OLE DB Driver for SQL Server (msoledbsql) или классический SQL Server Native Client (sqlncli).

Права доступа учетной записи службы (USR1CV8)

При переустановке или обновлении платформы инсталлятор часто предлагает создать нового локального пользователя USR1CV8 или переопределить параметры запуска службы. Изменение учетной записи службы — частая причина блокировки связи с СУБД и файлами настроек. Проанализируем возможные проблемы с правами доступа:

  1. Права на каталог srvinfo: новая или измененная учетная запись службы Агента 1С должна обладать полными правами (Full Control) на папку со старым каталогом настроек кластера. Если прав недостаточно, служба либо вообще не запустится, либо запустится, но не сможет прочитать файл 1CV8Clst.lst. Щелкните правой кнопкой мыши по папке srvinfo, перейдите во вкладку «Безопасность» и предоставьте учетной записи службы 1С полные права.
  2. Авторизация на SQL-сервере: если в настройках подключения к базам данных используется Windows-авторизация (когда сервер 1С подключается к SQL под своей сервисной учетной записью, а не под SQL-логином вроде sa), то смена пользователя службы USR1CV8 приведет к полной потере доступа к базам данных SQL. В таком случае базы отобразятся в консоли 1С, но при попытке войти пользователи увидят ошибку СУБД. Для исправления ситуации необходимо либо добавить новую учетную запись в список пользователей MS SQL Server с ролью db_owner для соответствующих баз, либо перевести подключение на SQL-авторизацию.

Лицензионные ограничения при смене разрядности

Не забывайте о лицензировании! Разрядность сервера 1С жестко контролируется аппаратными или программными ключами защиты:

  1. Лицензия на 32-разрядный сервер 1С («дешевая» лицензия) не позволяет запускать 64-разрядный сервер. При попытке запуска x64-платформы вы получите ошибку отсутствия лицензии на запуск сервера.
  2. Лицензия на 64-разрядный сервер является универсальной и позволяет запускать как 64-разрядную, так и 32-разрядную службу сервера 1С.

Перед переходом на 64-битную платформу убедитесь, что ваша серверная лицензия это позволяет.

Тонкости протокола Shared Memory (Общая память)

Если сервер 1С и MS SQL Server развернуты на одном физическом компьютере, самым производительным и быстрым способом их взаимодействия является использование протокола Shared Memory (Общая память). Однако при смене разрядности сервера или изменении учетной записи службы этот протокол может начать сбоить, выдавая ошибку «С обоих концов канала отсутствуют процессы».

Выясним, как диагностировать и временно обойти эту проблему:

Для проверки работоспособности каналов связи мы можем принудительно заставить систему общаться по протоколу TCP/IP. Для этого в консоли администрирования серверов 1С откройте свойства проблемной информационной базы и в поле «Сервер баз данных» вместо сетевого имени сервера (например, SRV-SQL) пропишите явное указание протокола:

tcp:localhost или tcp:127.0.0.1

Использование префикса tcp: отключает механизм Shared Memory и заставляет платформу использовать сетевой стек, что помогает быстро вернуть базы в рабочее состояние до устранения локальных проблем с правами доступа к общей памяти.

← На главную