В практике администрирования серверов 1С:Предприятие часто возникает неприятная ситуация: в консоли администрирования кластера (MMC) отображается информационная база, которой физически уже не существует в СУБД (например, в PostgreSQL). При попытке удалить такую базу штатными средствами консоль выдает ошибку, сообщая, что не может подключиться к базе данных. В результате запись в списке «зависает», мешая нормальной работе и внося путаницу.
В рамках данной статьи мы разберем несколько эффективных методов решения этой проблемы. Мы пройдем путь от самого простого и безопасного способа до более продвинутых техник, связанных с прямым редактированием конфигурационных файлов и использованием программных интерфейсов администрирования.
Проанализируем самый быстрый и безопасный способ, который рекомендуют опытные администраторы. Суть метода заключается в том, чтобы «обмануть» сервер 1С, предоставив ему временную пустую базу данных с тем же именем, которое он ожидает увидеть.
Рассмотрим пошагово, как это реализовать:
pgAdmin или командную строку psql).UTF8, а владельцем базы (Owner) был именно тот пользователь, который указан в настройках 1С.Для ускорения процесса можно воспользоваться SQL-запросом. Посмотрим на пример команды:
-- Создание пустой базы данных на основе шаблона
CREATE DATABASE "имя_вашей_базы"
WITH OWNER = "имя_пользователя_onec"
ENCODING = 'UTF8'
TEMPLATE = template1;
Разберем ситуацию подробнее: если у вас уже есть заготовленная пустая база-шаблон (например, template_1c), процесс пройдет еще быстрее. После того как база в PostgreSQL создана, вернемся в консоль администрирования 1С и повторим процедуру удаления информационной базы. Теперь сервер 1С успешно подключится к созданной нами «пустышке», не найдет там критических несоответствий и позволит полностью удалить регистрационную запись вместе с физической базой.
Бывают случаи, когда графическая консоль MMC ведет себя нестабильно. В такой ситуации нам поможет утилита rac (Remote Administration Client). Она работает через сервер администрирования ras и часто игнорирует некоторые проверки, которые блокируют удаление в визуальном интерфейсе.
Для начала убедимся, что служба ras запущена. Затем выполним следующие действия:
drop для принудительного удаления.Пример программного интерфейса для удаления выглядит следующим образом:
rac infobase --cluster=<ID_кластера> drop --infobase=<ID_базы> --infobase-user=<ИмяАдмина1С> --infobase-pwd=<ПарольАдмина1С>
Проанализируем параметры: --cluster — это уникальный идентификатор вашего кластера серверов, а --infobase — идентификатор конкретной базы. Этот метод хорош тем, что он обращается напрямую к программному интерфейсу сервера, что позволяет обойти ошибки отрисовки MMC-консоли.
Если предыдущие методы не помогли или сервер СУБД недоступен вовсе, мы можем прибегнуть к «хирургическому» вмешательству в конфигурационные файлы кластера. Вся информация о зарегистрированных базах хранится в текстовых файлах специального формата.
Внимание: Этот метод требует крайней осторожности. Ошибка в одном символе может привести к тому, что сервер перестанет видеть все базы кластера.
Выясним алгоритм действий:
1C:Enterprise Server. Это критически важно, так как при запущенной службе файлы блокируются или перезаписываются из оперативной памяти.C:\Program Files\1cv8\srvinfo\reg_1541\ (номер порта может отличаться).1cv8.reg. Это основной реестр кластера.Рассмотрим пример того, как выглядит описание базы в файле:
{
{9d8f6e4a-1234-4a5b-8c9d-0f1e2d3c4b5a, "MyBaseName", "Description", "PostgreSQL", "db_server", "db_name", "db_user", ...},
...
}
Нам необходимо аккуратно удалить весь блок, начиная от открывающей фигурной скобки описания этой базы до закрывающей, учитывая запятые, разделяющие элементы массива. После удаления сохраним файл и запустим службу сервера 1С. Если все сделано верно, «фантомная» база исчезнет из списка.
Иногда после удаления базы (особенно ручного) в каталоге кластера остаются «хвосты», которые могут вызывать ошибки в логах или мешать повторному созданию базы с тем же именем. Выясним, как провести полную очистку.
В папке кластера (например, reg_1541) помимо файла 1cv8.reg существуют подпапки, чьи имена соответствуют GUID информационных баз. После успешного удаления базы из списка реестра, следует найти папку с соответствующим идентификатором и удалить её.
Также рекомендуется очистить содержимое папки snccntx. Там хранятся данные сеансов и временные файлы конфигураций. Посмотрим, как это сделать правильно:
snccntx.Это гарантирует, что никакие старые данные о сессиях или кэшированные описания объектов не повлияют на стабильность работы сервера.
Мы рассмотрели различные подходы к решению проблемы «фантомных» баз. Подведем итоги:
Помните, что любые работы с реестром кластера и файлами конфигурации должны проводиться в периоды минимальной активности пользователей или во время технологического окна, так как остановка службы 1C:Enterprise Server прервет работу всех активных соединений.