Информационная база есть в консоли, а в СУБД её нет: чистим регистрацию в кластере 1С 8.3

Несуществующую базу удаляют из кластера 1С той же командой «Удалить», что и обычную, но в диалоге выбирают вариант Оставить базу данных без изменений. Тогда сервер 1С убирает только регистрацию информационной базы и не пытается трогать базу данных на SQL-сервере, которой уже нет. Если консоль всё равно не даёт удалить, помогают rac infobase drop без флагов удаления данных, временное создание пустой базы с тем же именем в СУБД или, в крайнем случае, правка реестра кластера 1CV8Clst.lst при остановленной службе.

Ситуация типовая: базу данных удалили в PostgreSQL или MS SQL напрямую, переименовали, перенесли на другой сервер СУБД, а в кластере 1С 8.3 она так и осталась. В консоли висит «мёртвая» строка, пользователи видят её в списке баз на сервере, а при попытке открыть свойства появляются ошибки подключения к СУБД. Порядок действий ниже — от безопасного к радикальному. Он одинаков для Windows и Linux, различаются только пути к файлам.

Как понять, что база действительно «осиротела»

Сначала убедитесь, что база данных пропала именно в СУБД, а не просто недоступна. Удалить регистрацию живой базы из-за временного сбоя сети — неприятная ошибка: потом придётся регистрировать её заново и перенастраивать регламентные задания.

Что проверить:

• 🔍 Параметры базы в кластере. В консоли откройте свойства информационной базы и посмотрите поля «Сервер баз данных», «Тип СУБД» и «База данных». Запишите их — они понадобятся дальше.
• 🗄️ Наличие базы в СУБД. В PostgreSQL выполните \l в psql или запрос к pg_database. В MS SQL посмотрите список баз в SQL Server Management Studio или выполните запрос к sys.databases.
• 🌐 Доступность сервера СУБД. Если сервер баз данных выключен или сменил адрес, база не «несуществующая», а недоступная. Её не удаляют, а исправляют адрес в свойствах.
• 👥 Активные сеансы и соединения. У настоящей «сироты» их нет. Если в консоли видны сеансы этой базы, кто-то с ней работает — разберитесь, прежде чем удалять.

Запросы для проверки в СУБД:

-- PostgreSQL: есть ли база с таким именем
SELECT datname FROM pg_database WHERE datname = 'buh_old';

-- MS SQL: то же самое
SELECT name FROM sys.databases WHERE name = 'buh_old';

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

Проверить список зарегистрированных баз со стороны 1С удобно через rac:

rac cluster list
rac infobase summary list --cluster=<UUID_кластера>

Первая команда покажет идентификатор кластера, вторая — все базы с их UUID и именами. Для rac должна работать служба ras (сервер администрирования, по умолчанию порт 1545).

Удаление базы из кластера через консоль администрирования

Это основной способ, и в большинстве случаев его хватает.

1. Запустите «Администрирование серверов 1С Предприятия» (оснастка MMC на Windows).
2. Раскройте Центральные серверы 1С:Предприятия → <имя сервера> → Кластеры → <кластер> → Информационные базы.
3. Если кластер защищён, консоль запросит логин и пароль администратора кластера.
4. Щёлкните правой кнопкой по нужной базе и выберите Удалить.
5. Консоль попросит имя и пароль администратора информационной базы — это пользователь 1С с правами администратора внутри самой базы.
6. В окне выбора действия с базой данных отметьте Оставить базу данных без изменений и подтвердите.

В диалоге три варианта, и путать их нельзя:

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

Если консоль требует пароль пользователя базы

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

Рабочий приём практиков — временно создать пустую базу с тем же именем в СУБД:

1. На сервере СУБД создайте пустую базу данных с именем из свойств информационной базы (например, buh_old) и владельцем — тем же пользователем СУБД, что указан в свойствах.
2. Повторите удаление в консоли. В пустой базе нет пользователей 1С, поэтому имя и пароль администратора базы оставьте пустыми.
3. Выберите Оставить базу данных без изменений.
4. Удалите временную пустую базу средствами СУБД.

-- PostgreSQL
CREATE DATABASE buh_old OWNER postgres;

-- MS SQL
CREATE DATABASE buh_old;

Удаление через rac, когда консоль не помогает

Утилита rac удобна на Linux, где нет MMC-оснастки, и в случаях, когда оснастка зависает или падает с ошибкой. Перед работой запустите сервер администрирования ras, если он ещё не работает как служба. Без флагов удаления данных команда rac infobase drop удаляет только регистрацию, а саму базу данных не трогает — то, что нужно для «сироты».

Порядок:

rem 1. Узнать UUID кластера
rac cluster list

rem 2. Найти UUID нужной базы
rac infobase summary list --cluster=<UUID_кластера>

rem 3. Удалить только регистрацию базы
rac infobase drop --cluster=<UUID_кластера> --infobase=<UUID_базы> ^
    --cluster-user=admin --cluster-pwd=*** ^
    --infobase-user="" --infobase-pwd=""

Флаги --cluster-user и --cluster-pwd нужны, только если на кластере назначены администраторы. Флаги --infobase-user и --infobase-pwd — учётные данные администратора информационной базы.

У rac infobase drop есть ещё два флага, которые для нашего случая не нужны:

• --drop-database — удалит базу данных в СУБД;
• --clear-database — очистит её содержимое.

Если rac возвращает ту же ошибку подключения к СУБД, что и консоль, помогает тот же приём с временной пустой базой. Точный набор параметров для вашей версии платформы проверьте командой rac help infobase.

Правка реестра кластера вручную

Последний вариант — когда ни консоль, ни rac не справляются, например реестр повреждён или кластер не стартует из-за проблемной записи. Список баз кластера хранится не в отдельном файле .cdf, а в реестре кластера — файле 1CV8Clst.lst в каталоге reg_<порт менеджера>.

Где искать:

Если служба запущена с другим каталогом srvinfo (параметр -d в строке запуска службы), ищите там. Порт в имени папки совпадает с портом менеджера кластера, по умолчанию 1541.

Остановка службы агента сервера оборвёт сеансы всех пользователей всех баз на этом сервере. Делайте это вне рабочего времени и предупредите людей заранее.

Порядок:

1. Сообщите пользователям, дождитесь окончания работы.
2. Остановите службу «Агент сервера 1С:Предприятия 8.3» (на Linux — сервис srv1cv8 или соответствующий юнит для вашей версии платформы).
3. Скопируйте весь каталог reg_1541 в резервное место. Не один файл — весь каталог.
4. Откройте 1CV8Clst.lst текстовым редактором, который не меняет кодировку (Notepad++, nano, vim).
5. Найдите запись базы по её UUID или имени. Запись — блок в фигурных скобках, начинающийся с UUID базы, за которым идут имя, описание, тип СУБД, сервер и имя базы данных.
6. Удалите блок целиком вместе с разделяющей запятой. Количество открывающих и закрывающих скобок должно остаться равным.
7. Удалите в reg_1541 подкаталог с именем, равным UUID этой базы, если он есть (там журнал регистрации и служебные данные базы).
8. Запустите службу и проверьте список баз в консоли.

Ручная правка — крайняя мера. Если сервер работает, сначала исчерпайте варианты с консолью, rac и временной пустой базой.

Что почистить в PostgreSQL и MS SQL

Сам кластер 1С не хранит список баз в СУБД, поэтому «метаданные кластера» в SQL искать бесполезно. Но после истории с удалённой базой на сервере СУБД часто остаётся мусор, который стоит убрать.

Что проверить:

• 🧹 Временная пустая база, созданная для удаления регистрации. Её нужно удалить, иначе через год никто не вспомнит, зачем она.
• 🔑 Логин или роль, созданные только для этой базы. Если пользователь СУБД больше никому не нужен, удалите его.
• 💾 Задания резервного копирования. Планы обслуживания в MS SQL и скрипты pg_dump по расписанию продолжат падать на несуществующей базе.
• 📁 Файлы базы на диске. В MS SQL после отсоединения (detach) файлы .mdf и .ldf остаются на диске и занимают место.

Удаление ненужной базы средствами СУБД:

-- PostgreSQL: завершить подключения и удалить
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'buh_old';
DROP DATABASE buh_old;

-- MS SQL: перевести в однопользовательский режим и удалить
ALTER DATABASE buh_old SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE buh_old;

DROP DATABASE необратим. Выполняйте его только для временной пустой базы или той, по которой есть подтверждение, что данные не нужны и копия сохранена.

Обратная ситуация тоже встречается: база данных в СУБД есть, а в кластере её нет. Тогда ничего удалять не надо — достаточно заново зарегистрировать её в консоли (Информационные базы → Создать → Информационная база), указав то же имя базы данных и сняв флажок создания базы.

Если база «вернулась» или не удаляется

Несколько ситуаций, которые путают даже опытных администраторов.

Как не допускать «сиротских» баз в кластере

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

Правила, которые стоит закрепить в регламенте:

1. Удаляйте базу только через 1С. Консоль или rac infobase drop --drop-database уберут и регистрацию, и базу данных одной операцией.
2. Переносите базу на другой сервер СУБД через свойства. Если база переехала, поменяйте сервер баз данных в свойствах информационной базы, а не регистрируйте её второй раз рядом со старой записью.
3. Ведите реестр баз. Простая таблица «имя в кластере — имя в СУБД — ответственный — назначение» за минуту отвечает на вопрос, нужна ли база.
4. Называйте тестовые базы по шаблону. Префиксы test_, tmp_ и дата создания (tmp_buh_2610) сразу показывают, что базу можно убрать.
5. Проверяйте расхождения раз в квартал. Сравните вывод rac infobase summary list со списком баз в СУБД. Всё, что есть только с одной стороны, — кандидат на разбор.
6. Сохраняйте каталог srvinfo в резервной копии сервера. Тогда ошибка при ручной правке реестра не станет катастрофой.

Частые вопросы