Как исправить ошибку «Ошибка снятия блокировки объекта. объект не заблокирован» и устранить зависания транзакций в 1С?

Системный администратор 1С v8.3 (Обычные формы) IT и автоматизация бизнеса
← На главную

В процессе работы пользователей в клиент-серверном режиме нередко возникают массовые сообщения о превышении времени ожидания блокировки («Время ожидания истекло»), а при попытке выполнить регламентное тестирование и исправление (ТиИ) платформа выдает исключение: «Ошибка снятия блокировки объекта. объект не заблокирован». Разберем детально причины такого поведения платформы и СУБД, а также пошаговый алгоритм устранения неполадки.

Анализ причин возникновения ошибки

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

  1. Нарушение целостности кэша сеансов: некорректно сохраненные данные контекста в служебных каталогах кластера серверов 1С приводят к тому, что менеджер блокировок пытается освободить несуществующий или уже закрытый дескриптор.
  2. Смешанный режим блокировок в метаданных: наличие в конфигурации объектов со свойством Режим управления блокировкой данных в значении «Автоматический» параллельно с объектами в режиме «Управляемый» порождает неконтролируемые эскалации блокировок СУБД и взаимоблокировки (Deadlocks).
  3. Зависшие сеансы и фоновые задания: аварийно завершенные или потерявшие связь клиентские подключения продолжают удерживать транзакционные блокировки на уровне СУБД, препятствуя выполнению регламентных процедур.
  4. Неактуальная статистика СУБД: устаревшие статистики оптимизатора приводят к сканированию всей таблицы (Table Scan) вместо точечного поиска по индексу (Index Seek), что многократно увеличивает время удержания эксклюзивных блокировок.

Шаг 1. Очистка серверного и клиентского кэша

Первым действием необходимо полностью сбросить кэш сеансовых данных и настроек сервера приложений. Выполним следующие шаги:

  1. Остановим службу сервера 1C:Enterprise 8 Server Adapter через оснастку управления службами (services.msc).
  2. Перейдем в каталог данных кластера серверов (по умолчанию для 64-разрядного сервера: C:\Program Files\1cv8\srvinfo\reg_1541 или C:\Program Files (x86)\1cv82\srvinfo\reg_1541).
  3. Удалим содержимое каталогов контекста сеансов: папки с префиксом snccntx. Файлы конфигурации кластера (1CV8Reg.lst) при этом удалять не требуется.
  4. Очистим кэш на клиентских рабочих станциях (или в терминальных сессиях пользователей), удалив каталоги 1C\1Cv8 и 1C\1Cv82 из папок %LocalAppData% и %AppData%, либо добавим ключ запуска /ClearCache в параметры запуска базы.
  5. Запустим службу сервера 1С.

Шаг 2. Завершение зависших сеансов и проверка подключений

Проверим наличие неактивных сеансов, которые могли заблокировать таблицы в СУБД:

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

Шаг 3. Анализ и выравнивание режимов блокировок в конфигураторе

Если конфигурация дорабатывалась, особое внимание уделим режимам управления блокировкой транзакций. Проанализируем настройки метаданных:

  1. Откроем конфигурацию в Конфигураторе и выделим корневой узел дерева метаданных.
  2. В палитре свойств проверим параметр Режим управления блокировкой данных по умолчанию.
  3. Если в корне установлено значение Управляемый, а у части документов или регистров выставлено Автоматический (или наоборот), система работает в смешанном режиме. Это провоцирует ситуации, когда автоматические транзакции блокируют целые диапазоны страниц в СУБД, а управляемые транзакции ждут освобождения ресурсов и падают по таймауту.
  4. Рекомендуется привести объекты конфигурации к единому стандарту — перевести объекты в режим Управляемый с обязательной установкой блокировок через объект БлокировкаДанных в модулях на встроенном языке.

Шаг 4. Обслуживание СУБД и оптимизация транзакций

Причиной внезапного появления массовых блокировок часто становится деградация планов выполнения запросов в MS SQL Server или PostgreSQL. Выполним комплекс регламентных процедур:

  1. Обновление статистик: выполним принудительный пересчет статистик с полным сканированием таблиц базы данных. В MS SQL Server выполним команду: EXEC sp_updatestats;
  2. Включение версионного режима (RCSI): для баз на MS SQL Server, использующих автоматический или смешанный режим блокировок, полезно включить версионирование строк, чтобы операции чтения (SELECT) не блокировали операции записи (INSERT/UPDATE):
    
    ALTER DATABASE [ИмяБазы] SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE;
    ALTER DATABASE [ИмяБазы] SET ALLOW_SNAPSHOT_ISOLATION ON;
    
  3. Реиндексация: настроим регулярный план обслуживания для реорганизации и перестроения сильно фрагментированных индексов.

Шаг 5. Поэтапное выполнение тестирования и исправления (ТиИ)

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

  1. Запустим Конфигуратор в монопольном режиме и откроем меню Администрирование -> Тестирование и исправление...
  2. Выберем только пункт Реиндексация таблиц информационной базы и выполним процесс.
  3. Следующим отдельным запуском выполним Пересчет итогов.
  4. Далее запустим Проверку логической целостности и Проверку ссылочной целостности. Поэтапный запуск позволяет избежать переполнения журнала транзакций СУБД и точно локализовать объект, вызывающий исключение.

Шаг 6. Корректная обработка снятия блокировок в коде

Если ошибка возникает в пользовательском режиме при записи или закрытии форм конкретных объектов, проверим модули объектов и форм на корректность снятия пессимистической блокировки. Вызов метода РазблокироватьДанныеДляРедактирования() должен быть защищен от попытки повторного освобождения:


Попытка
    РазблокироватьДанныеДляРедактирования(Ссылка, УникальныйИдентификатор);
Исключение
    // Подавляем ошибку, если объект уже был разблокирован платформой ранее
    ЗаписьЖурналаРегистрации("СнятиеБлокировки", 
        УровеньЖурналаРегистрации.Примечание, 
        , 
        Ссылка, 
        ОписаниеОшибки());
КонецПопытки;

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

← На главную