Каждый администратор СУБД или разработчик 1С рано или поздно сталкивается с парадоксальной ситуацией: при попытке обновить конфигурацию базы данных или выгрузить информационную базу система выдает ошибку монопольного доступа, утверждая, что база занята другим сеансом Конфигуратора. При этом в самом Конфигураторе список активных пользователей пуст, а на сервере запущен ровно один сеанс. Данная коллизия в профессиональной среде называется «Блокировка есть, а сеанса нет».
В этой статье мы подробно разберем причины возникновения этой проблемы, проанализируем поведение платформы «1С:Предприятие» и предложим пошаговые методы устранения этой ошибки: от базовых манипуляций в консоли до продвинутых решений на уровне веб-сервера и MS SQL Server. Для решения подобных задач есть обработка принудительного завершения сеансов для обновления баз.
Для начала проанализируем ситуацию и разберемся, из-за чего платформа начинает «считать», что база заблокирована. Существует несколько основных факторов:
Ниже мы рассмотрим пошаговые сценарии решения проблемы, начиная от простых и заканчивая более сложными административными методами.
Первым делом проверим не список активных пользователей в самом Конфигураторе, а реальное состояние дел в консоли администрирования серверов «1С:Предприятия».
Разберем этот процесс по шагам:
Designer (Конфигуратор). Если вы видите «зависший» процесс вашего коллеги или свой собственный старый сеанс, нажмите на нем правой кнопкой мыши и выберите команду «Удалить» (или завершить).Если сервер 1С работает под управлением операционной системы Windows Server и доступ к нему осуществляется через RDP, велика вероятность столкнуться со «спящими» сессиями. Для автоматического завершения таких сеансов и освобождения файлов базы подойдёт утилита для принудительного закрытия сессий 1С на терминальном сервере.
Выполним следующие действия:
1cv8.exe завершите его принудительно, выбрав пункт «Снять задачу» (End Task). Это мгновенно освободит удерживаемые файлы базы данных (в случае файлового варианта) или снимет транзакции на сервере СУБД.Если ваша база данных опубликована на веб-сервере (например, IIS от Microsoft или Apache), службы публикации могут удерживать низкоуровневые соединения с базой.
Для исправления ситуации выполним быструю перезагрузку веб-компонентов:
iisreset /restart
Apache2.4 (или вашей версии) и нажмите кнопку «Перезапустить».После перезапуска веб-сервера все зависшие низкоуровневые сессии гарантированно закроются, освободив конфигурацию для обновления.
В крупных организациях перезапуск службы сервера приложений 1С (ragent) недопустим, так как это прервет работу сотен пользователей в других информационных базах, находящихся на этом же кластере. В таком случае мы можем прибегнуть к хитрости — созданию временного подключения.
Рассмотрим этот алгоритм детально:
trade_db в trade_db_temp). Физическая база данных на MS SQL при этом никак не пострадает.trade_db_backdoor, указав те же самые параметры сервера SQL и имя физической базы данных.trade_db_backdoor является абсолютно новой, на нее старая зависшая блокировка не распространяется!trade_db_backdoor. Система успешно зайдет в монопольном режиме. Проведите необходимое обновление базы данных.trade_db_backdoor, верните старой базе ее исходное имя trade_db и снимите блокировку сеансов.Фантомные блокировки метаданных кэшируются оперативной памятью конкретного рабочего процесса rphost сервера приложений 1С. Мы можем заставить кластер освободить эти ресурсы без жесткого перезапуска всей службы 1С.
Разберем этот системный метод:
rphost (если у вас настроен только один процесс).rphost.kill в Linux). Вместе с процессом исчезнет и зависший фантом блокировки конфигурации.Если блокировка удерживается непосредственно на уровне таблиц базы данных в СУБД (например, заблокированы таблицы Config или DBNames), проблему можно решить средствами СУБД.
Рассмотрим пример устранения блокировки в среде Microsoft SQL Server:
USE master;
GO
-- Получаем список активных процессов и блокировок
EXEC sp_who2;
DBName (имя вашей базы 1С) и колонку ProgramName (ищите процессы, запущенные от имени 1С:Предприятия). Обратите внимание на колонку BlkBy (блокировано кем) — она указывает на идентификатор процесса (SPID), который удерживает монопольный доступ.
KILL 54;
После выполнения команды KILL СУБД моментально откатит незавершенную транзакцию зависшего процесса, и Конфигуратор сможет продолжить обновление структуры базы данных.
В случае, если в процессе автоматического фонового обновления конфигурации (например, когда главный бухгалтер запустил процесс обновления из режима Предприятия через интернет) произошел сбой питания сервера, база может оказаться заблокированной из-за повреждения файла журнала транзакций (файла лога .ldf). Для предотвращения таких ситуаций полезна автоматическое отслеживание ошибок в журнале регистрации.
Если обычные методы ужимания лога (shrink) и переключение моделей восстановления базы данных (Recovery Model) из Full в Simple не помогают, используем следующий радикальный, но проверенный способ:
.ldf (например, trade_db_log.ldf) и переименуйте его либо удалите (предварительно сделав резервную копию основного файла данных .mdf!)..mdf заново. При этом СУБД обнаружит отсутствие файла лога и автоматически создаст новый, чистый и пустой файл журнала транзакций.
DBCC CHECKDB ('Имя_Вашей_Базы') WITH NO_INFOMSGS, ALL_ERRORMSGS;
Используя предложенные нами системные методы контроля процессов и блокировок, вы сможете оперативно решать подобные проблемы администрирования без необходимости полной перезагрузки физических серверов компании.