Как исправить ошибку исключительной блокировки базы данных 1С, если в списке нет активных пользователей?

Системный администратор IT и автоматизация бизнеса
← На главную

Каждый системный администратор или разработчик 1С рано или поздно сталкивается с ситуацией, когда при попытке обновить конфигурацию, восстановить базу из резервной копии или выполнить тестирование и исправление (удобно через обработка тестирования и исправления базы без монопольного режима), система выдает критическую ошибку: «Ошибка исключительной блокировки информационной базы». Самое загадочное в этой ситуации — список активных пользователей в «Конфигураторе» или « консоли кластера» может быть абсолютно пуст. Рассмотрим подробно, почему так происходит, и разберем по шагам все методы решения этой проблемы для различных режимов работы базы данных.

Анализируем природу проблемы: почему база считается занятой?

Прежде чем переходить к радикальным мерам вроде перезагрузки серверов, давайте проанализируем ситуацию. Исключительная блокировка требуется 1С для того, чтобы гарантировать целостность структуры данных. Если хотя бы один процесс имеет открытое соединение с базой, монопольный доступ невозможен. Проблема в том, что «процессом» может быть не только живой пользователь с открытым окном программы. Выясним основные причины:

  1. Фоновые и регламентные задания. Они запускаются сервером автоматически и часто не отображаются в стандартных списках пользователей.
  2. Зависшие сеансы (LTSC). Соединение клиента с сервером разорвано (например, из-за сбоя сети), но сервер 1С все еще считает сеанс активным.
  3. Спящие сеансы. Сеансы, которые помещены сервером в режим ожидания, но продолжают удерживать лицензии и блокировки.
  4. Внешние соединения. COM-объекты, веб-сервисы (IIS/Apache) или внешние источники данных.
  5. Служебные процессы СУБД. На уровне SQL Server могут висеть незавершенные транзакции или процессы обслуживания индексов.
  6. Блокировки файловой системы. Антивирусы, системы бэкапа или сетевые протоколы (SMB) могут «держать» файл базы данных 1Cv8.1CD.

Решение 1: Работа с консолью администрирования серверов 1С

Если вы работаете в клиент-серверном варианте, первым делом обратимся к консоли кластера. Рассмотрим, как правильно очистить соединения. Часто администраторы смотрят только в раздел «Соединения», но этого недостаточно.

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

  1. Переходим в раздел «Информационные базы», выбираем нашу базу и открываем ветку «Сеансы». Именно здесь часто «прячутся» призраки закрытых приложений. Удаляем все записи, нажав правую кнопку мыши и выбрав «Удалить».
  2. Проверяем раздел «Блокировки». Бывает так, что сеансов уже нет, а объект блокировки в памяти менеджера кластера остался. Если вы видите там записи, связанные с вашей базой, — это и есть причина. К сожалению, штатного интерфейса «удалить блокировку» без удаления сеанса иногда не предусмотрено, поэтому может потребоваться более решительный шаг.
  3. Попробуем применить «хитрый» метод: удалим регистрацию информационной базы из консоли 1С (при этом обязательно выбираем «Оставить информационную базу без изменений», чтобы не удалить физические данные на SQL-сервере). Затем сразу создаем описание базы заново с теми же параметрами. Это полностью обнуляет кэш соединений менеджера кластера для конкретной базы.

Решение 2: Управление регламентными и фоновыми заданиями

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

Для гарантированного отключения фоновых заданий выполним следующие действия:

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

Решение 3: Очистка процессов на стороне SQL Server

Если манипуляции с консолью 1С не помогают, выясним причину на уровне системы управления базами данных. Бывает, что процесс rphost уже закрыл соединение, но SQL Server продолжает считать транзакцию открытой (состояние Sleeping с открытой транзакцией).

Рассмотрим, как найти и «убить» такие процессы через SQL Server Management Studio (SSMS):

Откроем новый запрос и выполним стандартную процедуру мониторинга:


EXEC sp_who2;
-- Или более современный вариант
SELECT * FROM sys.dm_exec_sessions WHERE database_id = DB_ID('Имя_Вашей_Базы');

Проанализируем колонку dbname. Если мы видим процессы, подключенные к нашей базе, обратим внимание на их SPID (идентификатор процесса). Чтобы принудительно разорвать соединение, используем команду:


KILL 54; -- Где 54 - это найденный SPID

Также полезно проверить наличие незавершенных транзакций, которые могут блокировать таблицы метаданных:


DBCC OPENTRAN('Имя_Вашей_Базы');

Если команда вернула информацию об открытой транзакции, ее также следует завершить через KILL соответствующего сеанса.

Решение 4: Особенности файлового режима (IIS, сетевые папки)

В файловом режиме блокировка часто вызывается внешними факторами. Посмотрим, что может удерживать файлы базы данных .1CD, .1CL и .1CC.

Если база опубликована на веб-сервере (IIS), то процесс веб-сервера (обычно это w3wp.exe) постоянно держит открытый дескриптор к файлу базы. Рассмотрим действия для исправления:

  1. Остановим службу IIS (команда iisreset /stop в командной строке от имени администратора) или просто остановим конкретный пул приложений в диспетчере служб IIS.
  2. Проверим наличие файлов 1Cv8.1cl в папке с базой. Это файлы блокировок. Если база закрыта, а они остались — их нужно удалить вручную. Если система пишет «Файл занят другим процессом», значит, кто-то все еще держит базу.
  3. Используем стандартную оснастку Windows «Управление компьютером». Перейдем в раздел «Общие папки» -> «Открытые файлы». Здесь можно наглядно увидеть, кто из пользователей сети открыл файл базы, и принудительно закрыть это соединение.
  4. Проверим диспетчер задач на наличие «зависших» процессов 1cv8.exe. Иногда после аварийного завершения окно программы исчезает, но процесс остается в памяти и продолжает удерживать файл.

Решение 5: Перезапуск служб и очистка серверного кэша

Если никакие точечные методы не помогают, перейдем к более масштабным действиям. Иногда причиной блокировки является некорректное состояние самого «Агента сервера 1С:Предприятие».

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

  1. Останавливаем службу 1C:Enterprise 8.3 Server Agent.
  2. Проверяем в диспетчере задач, что все процессы rphost, rmngr и ragent завершились. Если нет — завершаем их принудительно.
  3. Пока служба остановлена, имеет смысл очистить серверный кэш. Перейдем в каталог данных кластера (по умолчанию это C:\Program Files\1cv8\srvinfo).
  4. Внутри каталога reg_1541 (номер порта может отличаться) найдем папки с именами-идентификаторами баз (UID). Внутри этих папок можно смело удалять содержимое папки snaccnt.dat и временные файлы, но будьте осторожны: не удаляйте файлы конфигурации самого кластера (1CV8Reg.lst).
  5. Запускаем службу заново. В 99% случаев после такой глубокой очистки все фантомные блокировки исчезают.

Дополнительный нюанс: «Скрытые» окна авторизации

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

Проанализируем командную строку процессов. В диспетчере задач на вкладке «Подробности» добавим колонку «Командная строка». Там можно увидеть путь к базе данных, которую пытается открыть зависший процесс 1cv8.exe. Это поможет вычислить конкретного «виновника» на терминальном сервере.

Заключение и рекомендации

Мы рассмотрели все основные способы борьбы с ошибкой исключительной блокировки. Подведем итог: всегда начинайте с самого простого — проверки сеансов в консоли и установки блокировки регламентных заданий. Если это не помогает, переходите к анализу процессов СУБД или блокировок файловой системы.

Важный совет: Чтобы в будущем такие ситуации возникали реже, настройте в параметрах кластера 1С автоматическое завершение спящих сеансов — для этого есть утилита принудительного завершения сеансов 1С. Установите Время засыпания и Время завершения спящего сеанса в разумные пределы (например, 1200 и 600 секунд соответственно). Это позволит серверу самостоятельно «вычищать» брошенные подключения, освобождая базу для монопольных операций.

← На главную