← На главную

В практике администрирования кластера 1С:Предприятия часто возникает ситуация, когда администратор сначала удаляет базу данных непосредственно через средства СУБД (например, через pgAdmin4 для PostgreSQL или SQL Server Management Studio для MS SQL), а уже затем пытается удалить регистрацию этой базы в консоли администрирования 1С. В этот момент консоль выдает ошибку, сообщая, что информационная база не найдена на сервере баз данных. В результате в консоли остается «фантомная» запись, которую невозможно убрать стандартным нажатием клавиши Delete.

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

Метод 1. Использование опции «Оставить без изменений»

Разберем самый корректный и штатный способ, предусмотренный разработчиками платформы. Когда мы инициируем удаление информационной базы через консоль MMC (или через стандартную обработку управления), система предлагает выбор режима удаления. Основная ошибка заключается в попытке выбрать полную очистку.

Рассмотрим алгоритм действий подробнее:

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

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

Метод 2. Удаление через утилиту командной строки RAC

Бывают ситуации, когда графическая консоль зависает или выдает неинформативные ошибки «Объект не найден». В таких случаях воспользуемся мощным инструментом — утилитой rac. Она работает через сервер администрирования ras и позволяет управлять кластером напрямую. Для этого подойдет инструмент централизованного администрирования кластеров 1С.

Разберем последовательность команд для принудительного удаления регистрации базы:

1. Убедимся, что служба 1C:Enterprise 8.3 Remote Administration Service (она же ras) запущена.
2. Откроем командную строку от имени администратора и перейдем в каталог с установленной платформой (где лежит rac.exe).
3. Сначала получим идентификатор нашего кластера:
rac cluster list localhost:1545
4. Затем найдем идентификатор (UUID) информационной базы, которую нужно удалить:
rac infobase --cluster=ИДЕНТИФИКАТОР_КЛАСТЕРА summary list localhost:1545
5. Выполним команду удаления с флагом принудительного завершения:
Скопировать код

rac infobase --cluster=ИДЕНТИФИКАТОР_КЛАСТЕРА remove --infobase=ИДЕНТИФИКАТОР_БАЗЫ --force

Параметр --force позволяет игнорировать многие ошибки связи с СУБД и принудительно вычищать метаданные базы из кластера.

Метод 3. Метод «Обманного маневра» (Пересоздание базы)

Если сервер 1С упорно отказывается удалять запись, мотивируя это отсутствием базы в СУБД, мы можем временно восстановить статус-кво. Рассмотрим, как это сделать:

1. Зайдем в pgAdmin4 или SSMS.
2. Создадим новую пустую базу данных с точно таким же именем, которое указано в параметрах информационной базы в консоли 1С.
3. Вернемся в консоль 1С и попробуем удалить базу снова.

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

Метод 4. Ручное редактирование файла конфигурации кластера

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

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

1. Остановим службу 1C:Enterprise 8.3 Server Agent. Это обязательное условие, иначе изменения будут перезаписаны службой из оперативной памяти.
2. Перейдем в каталог данных кластера. Обычно это путь: C:\Program Files\1cv8\srvinfo\reg_1541.
3. Найдем файл srvribrg.lst. Это текстовый файл, содержащий структуру всех зарегистрированных объектов.
4. Сделаем резервную копию этого файла!
5. Откроем оригинал в текстовом редакторе (лучше всего подойдет Notepad++).
6. Найдем блок, начинающийся с UUID вашей проблемной базы. Структура файла представляет собой вложенные списки в фигурных скобках { }.
7. Аккуратно удалим весь блок, соответствующий этой базе. Будьте предельно внимательны с запятыми и закрывающими скобками — нарушение структуры файла приведет к тому, что кластер не запустится.
8. Сохраним файл и запустим службу агента сервера.

Метод 5. Очистка кэша и временных файлов сервера

Иногда база кажется неудаленной из-за того, что информация о ней закеширована рабочими процессами rphost. Посмотрим, как произвести глубокую очистку:

Остановим службу 1С и перейдем в папку srvinfo. Внутри папок рабочих серверов (вида reg_XXXX) могут находиться файлы snacc.bin. Это двоичные файлы кэша конфигурации кластера. Удаление этих файлов (при остановленной службе!) заставляет систему перечитать состояние реестра из srvribrg.lst «с чистого листа» при следующем запуске.

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

Метод 6. Перезапуск служб

Как отмечали участники обсуждения, иногда самым простым решением является перезапуск не только службы сервера 1С, но и всей СУБД. Это помогает разорвать «зависшие» сетевые соединения между процессами rmngr и postgres (или sqlservr), которые могут блокировать изменение статуса информационной базы в реестре кластера.

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