1С: как определить, кто заблокировал объект

Блокировка объекта в 1С — штатный механизм, который защищает данные от одновременного изменения несколькими пользователями. Однако на практике она нередко превращается в проблему: документ нельзя провести, справочник не сохраняется, а система выдаёт сообщение «Конфликт блокировок при выполнении транзакции» или «Объект заблокирован другим пользователем».

Первое, что нужно понять администратору, — кто именно держит блокировку и является ли она «живой» (пользователь реально работает) или «зависшей» (сеанс оборвался, но блокировка не снялась). От этого зависит дальнейшее действие: дождаться освобождения объекта, попросить коллегу завершить работу или принудительно завершить сеанс.

Способ диагностики зависит от режима работы информационной базы. В файловом варианте инструменты ограничены, а в клиент-серверном доступны консоль кластера, технологический журнал и функция ПолучитьСеансыИнформационнойБазы(). Ниже разобраны все рабочие методы — от простого к сложному.

Какие бывают блокировки в 1С и почему это важно

Прежде чем искать виновника, полезно понять, с каким типом блокировки вы столкнулись, потому что методика поиска отличается. В 1С существует два принципиально разных механизма.

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

Объектные (прикладные) блокировки — например, когда пользователь открыл документ на редактирование, а другой пытается открыть его же. Система честно сообщает, что объект редактируется, и часто указывает имя пользователя прямо в тексте ошибки. Также сюда относятся программные блокировки через метод Заблокировать() объекта данных.

Отдельный случай — исключительная блокировка информационной базы целиком (например, при обновлении конфигурации или загрузке данных). Тогда страдают все пользователи, а источник обычно очевиден — регламентное задание или администратор.

Определяем виновника через журнал регистрации

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

Установите отбор по интересующему периоду времени и по событию. Для диагностики конфликтов полезны события, связанные с транзакционными блокировками, а также событие _$Data$_.Post (запись данных) и ошибки _$InfoBase$_.Administration. Если известно, какой объект заблокирован, добавьте отбор по представлению данных — так вы увидите, кто последним обращался к объекту.

В типовых конфигурациях на базе БСП (Библиотека стандартных подсистем) сообщение об ошибке блокировки часто содержит расширенный текст с указанием сеанса и компьютера. Скопируйте полный текст ошибки из окна сообщения — в нём может быть фраза вида «сеанс № 1234, пользователь ИвановИА, компьютер WS-015».

1. 1
   Откройте журнал регистрации из конфигуратора или режима предприятия
2. 2
   Установите отбор по периоду, когда возникла ошибка блокировки
3. 3
   Добавьте отбор по пользователю, если есть подозрения, или по представлению данных заблокированного объекта
4. 4
   Найдите события ошибок записи или блокировки и раскройте их детали
5. 5
   Сопоставьте время ошибки с активными сеансами, чтобы определить конкретного пользователя

Консоль кластера серверов: сеансы и соединения

В клиент-серверном варианте работы самый наглядный способ — консоль администрирования серверов 1С. Откройте её, разверните нужный кластер, затем информационную базу и перейдите в раздел «Сеансы». Здесь видно всех пользователей, которые сейчас подключены: имя, компьютер, время начала сеанса, время последнего обращения и объём прочитанных/записанных данных.

Признак «зависшего» сеанса — давнее время последнего обращения при формально активном сеансе. Например, пользователь ушёл домой вчера вечером, а сеанс числится активным, и время последнего обращения — 18:05 вчерашнего дня. Такой сеанс является кандидатом на принудительное завершение.

Раздел «Соединения» показывает связи между рабочими процессами сервера и СУБД. Если конфликт происходит на уровне MS SQL Server или PostgreSQL, именно здесь видно, какое соединение удерживает ресурс. Сопоставив номер соединения с сеансом, вы выходите на конкретного пользователя.

Для снятия блокировки выделите проблемный сеанс и выберите команду «Удалить» (завершение сеанса). Пользователь при этом получит сообщение о разрыве соединения, поэтому корректнее сначала связаться с коллегой и предупредить его.

Программные способы: ПолучитьСеансыИнформационнойБазы

Если нужно автоматизировать диагностику или вывести список активных пользователей прямо в режиме предприятия, используется метод глобального контекста ПолучитьСеансыИнформационнойБазы(). Он возвращает массив объектов с описанием каждого сеанса: пользователь, имя компьютера, номер сеанса, время начала, режим работы.

Типовой фрагмент кода для внешней обработки выглядит так:

Сеансы = ПолучитьСеансыИнформационнойБазы();
Для Каждого Сеанс Из Сеансы Цикл
    Сообщить("Пользователь: " + Сеанс.ИмяПользователя
        + "; Компьютер: " + Сеанс.ИмяКомпьютера
        + "; Сеанс: " + Сеанс.НомерСеанса
        + "; Начало: " + Сеанс.НачалоСеанса);
КонецЦикла;

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

Для выполнения кода требуются права администратора. В файловом режиме метод доступен только тому, кто работает с базой монопольно или через веб-сервер, что ограничивает его применение.

Технологический журнал и средства СУБД

Технологический журнал (ТЖ) — самый глубокий уровень диагностики. Он настраивается через файл logcfg.xml, который размещается в каталоге конфигурации сервера 1С. Для анализа блокировок включают события TLOCK, TDEADLOCK, TTIMEOUT и DBMSSQL (или аналог для вашей СУБД).

В событии TTIMEOUT фиксируется конфликт блокировок: видно, какой сеанс ожидал ресурс, какой сеанс его удерживал, и какая таблица была затронута. По номеру сеанса через консоль кластера определяется конкретный пользователь. Это самый достоверный способ ответить на вопрос «кто заблокировал объект» в сложных случаях.

На стороне MS SQL Server конфликты видны через динамические представления sys.dm_tran_locks и sys.dm_exec_sessions, а также через Activity Monitor (раздел Processes, колонка «Blocked By»). Запрос к этим представлениям покажет цепочку: кто кого блокирует. Однако помните, что в 1С с управляемыми блокировками часть конфликтов обрабатывается менеджером блокировок сервера 1С и в СУБД не видна.

Как снять блокировку и предотвратить повторение

Если блокировку держит живой пользователь, корректный путь — попросить его завершить редактирование объекта или закрыть форму документа. Часто конфликт возникает из-за того, что коллега открыл документ и отошёл от рабочего места, оставив форму в режиме редактирования.

Если сеанс завис, завершите его через консоль кластера (раздел «Сеансы» — «Удалить») либо дождитесь автоматического завершения по тайм-ауту. По умолчанию кластер завершает неактивные сеансы через настраиваемые интервалы, поэтому многие «зависшие» блокировки снимаются сами в течение 20–40 минут.

Для профилактики стоит настроить в свойствах информационной базы параметры завершения неактивных сеансов и «засыпания» пассивных сеансов. В типовых конфигурациях также полезно включить напоминания пользователям о необходимости закрывать формы редактирования, а длительные регламентные операции выполнять в нерабочее время.

Особенности файлового режима и типовых конфигураций

В файловом режиме консоль кластера недоступна, поэтому основные инструменты — журнал регистрации и список активных пользователей («Администрирование — Пользователи и права — Активные пользователи» в типовых конфигурациях). Этот список показывает, кто сейчас работает с базой, и позволяет завершить сеанс пользователя при наличии прав администратора.

Если файловая база сообщает, что объект заблокирован, но в списке активных пользователей никого нет, вероятна ситуация «осиротевшей» блокировки после аварийного завершения. В таком случае помогает завершение всех процессов 1С на компьютерах пользователей и проверка отсутствия файла 1Cv8.1CL в каталоге базы (он удаляется автоматически при корректном завершении всех сеансов).

В типовых конфигурациях (УТ, ERP, Бухгалтерия) часть конфликтов связана с регламентными заданиями: отложенное проведение, расчёт итогов, обмены данными. Если блокировки возникают регулярно в одно и то же время, проверьте расписание фоновых заданий — вероятно, они пересекаются с работой пользователей.

Часто задаваемые вопросы