Администрирование · 12 мин
Что такое блокировка в 1С и как с ней работать
Что такое блокировка в 1С, почему возникают ошибки «Конфликт блокировок», как найти зависший сеанс, снять блокировку и предотвратить повторение проблемы.
Блокировка в 1С — это механизм, который не даёт двум пользователям или фоновым процессам одновременно изменить одни и те же данные. Когда один сеанс записывает документ или проводит его, система «запирает» затронутые записи: остальные сеансы либо ждут освобождения, либо получают ошибку «Конфликт блокировок при выполнении транзакции». Это нормальное и необходимое поведение — без блокировок база быстро наполнилась бы противоречивыми данными.
Проблемы начинаются там, где блокировки удерживаются слишком долго или захватывают слишком много данных. Тогда пользователи видят зависания, сообщения об ошибках блокировки, а регламентные задания конфликтуют с работой людей. Понимание того, какие блокировки бывают и кто их ставит, — основа диагностики: в половине случаев причина оказывается не в «глючной 1С», а в зависшем сеансе или неудачно запущенной обработке.
Материал ориентирован на администраторов и продвинутых пользователей: разберём виды блокировок, типовые сценарии конфликтов, способы найти виновника и безопасно снять блокировку, а также меры профилактики.
Какие виды блокировок существуют в 1С
В платформе 1С:Предприятие работают два больших класса блокировок: объектные (на уровне данных в оперативной памяти сервера 1С) и транзакционные (на уровне СУБД — MS SQL, PostgreSQL и др.). Первые возникают, когда два пользователя открывают на редактирование один и тот же объект — например, один и тот же документ или элемент справочника. Второй пользователь увидит сообщение, что объект редактируется, и сможет открыть его только на просмотр.
Транзакционные блокировки ставятся автоматически при записи данных в базу. Проведение документа может заблокировать регистры остатков, партий, взаиморасчётов — всё, что документ изменяет. Пока транзакция не завершена, другие сеансы, пытающиеся изменить те же записи, встают в очередь ожидания или получают ошибку по таймауту.
Отдельно стоит упомянуть блокировку информационной базы целиком — её администратор устанавливает вручную перед обновлением конфигурации или регламентными работами. Пользователи при этом получают сообщение о начале сервисных работ и не могут войти. Это штатный инструмент, а не признак неисправности.
Почему возникает ошибка «Конфликт блокировок»
Самая частая причина — конкуренция за одни и те же данные. Классический пример: два менеджера одновременно проводят реализации, списывающие один и тот же товар, а система блокирует записи регистра остатков. Второй сеанс ждёт, истекает таймаут ожидания — и пользователь видит ошибку. Единичные случаи в час пик — норма для активно работающей базы, систематические ошибки — повод разбираться.
Вторая группа причин — длительные транзакции. Массовая обработка документов, перепроведение за месяц, обмен данными или загрузка прайсов могут удерживать блокировки минутами. Всё это время пользователи, затрагивающие те же данные, получают ошибки или зависания. Третья группа — зависшие сеансы: клиентское приложение «упало», но соединение на сервере осталось и продолжает держать блокировку.
Проверьте сеансы на сервере и активные регламентные задания
Выясните, какой документ или данные он изменяет, и кто ещё с ними работает
Сверьте расписание обменов и обработок с периодами ошибок
Проверьте консоль кластера: возможно, идёт обновление конфигурации
Наконец, ошибки блокировок провоцирует сам код: обработчики, которые читают большие выборки внутри транзакции, блокировки «в неправильном порядке» у разных процессов (взаимоблокировки, deadlock), избыточные блокировки целых таблиц вместо конкретных записей. Такие проблемы диагностируются по технологическому журналу и устраняются доработкой кода.
Как найти источник блокировки
В клиент-серверном варианте первый инструмент — консоль кластера серверов 1С. Откройте список сеансов информационной базы и ищите аномалии: сеансы с огромным временем работы, сеансы от пользователей, которые уже вышли, фоновые задания, висящие часами. Колонки «Время вызова СУБД» и «Прочитано/записано» помогают вычислить тяжёлые процессы.
Для точной диагностики транзакционных конфликтов включайте технологический журнал с событием TLOCK (и при необходимости TDEADLOCK для взаимоблокировок). По журналу видно, какой сеанс удерживал блокировку, какой ждал, какие таблицы и ключи записей участвовали в конфликте. Это самый достоверный способ понять, что именно происходило в момент ошибки.
- 1Откройте консоль кластера и отсортируйте сеансы по длительности и активности СУБД
- 2Найдите сеанс, удерживающий блокировку: пользователь, компьютер, время начала
- 3Уточните у пользователя, что он делает — возможно, процесс штатный и его нужно просто дождаться
- 4Если сеанс зависший (пользователь уже вышел, клиент закрыт) — завершите его из консоли
- 5Если конфликты повторяются — включите технологический журнал с событиями TLOCK и проанализируйте записи
В файловом варианте базы инструментарий беднее: посмотреть активные сеансы можно через «Администрирование → Активные пользователи» в самой программе. Здесь же видно, какие фоновые задания выполняются. Зависший сеанс в файловой базе часто лечится только перезапуском — это одна из причин, почему при росте числа пользователей рекомендуют переход на клиент-серверный вариант.
Как безопасно снять блокировку
Главное правило: сначала понять, что делает блокирующий сеанс, и только потом его завершать. Если сеанс проводит большой документ или выполняет обмен — принудительное завершение оборвёт транзакцию. Данные при этом не испортятся (СУБД откатит незавершённую транзакцию), но работу придётся начинать заново, а в файловой базе при неудачном стечении обстоятельств возможны повреждения.
Зависший сеанс в клиент-серверном варианте завершается из консоли кластера: правый клик по сеансу → «Удалить». Сеанс завершится принудительно, блокировки освободятся. Если блокировку держит фоновое задание, его можно отменить через консоль заданий или ту же консоль кластера. После завершения попросите пострадавшего пользователя повторить операцию — в большинстве случаев она пройдёт сразу.
Если установлена штатная блокировка информационной базы (например, забыли снять после обновления), она снимается в консоли кластера: свойства информационной базы → снять флаг «Блокировка регламентных заданий включена» и очистить сообщение о блокировке сеансов. Либо через параметр /UC при запуске конфигуратора с кодом разрешения, если он был задан.
Как предотвратить конфликты блокировок
Организационные меры дают эффект быстрее технических. Разнесите по времени тяжёлые операции: обмены, перепроведение, загрузки прайсов и массовые обработки должны выполняться в нерабочие часы или в периоды минимальной активности. Настройте расписание регламентных заданий так, чтобы они не пересекались друг с другом и с пиковой нагрузкой пользователей.
Проверьте, что конфигурация работает в режиме управляемых блокировок (свойство конфигурации «Режим управления блокировкой данных» — «Управляемый» или «Автоматический и управляемый»). Автоматический режим на больших объёмах даёт избыточные блокировки на уровне СУБД и резко повышает число конфликтов. Для самописных обработок правило простое: блокировать данные как можно позже, как можно уже (по конкретным измерениям) и в едином порядке во всех процедурах.
Как выбрать действие
Полезно включить разделение итогов для регистров накопления, если оно ещё не включено: это снижает конкуренцию за записи итогов при проведении документов. Дополнительно следите за длительностью транзакций — обработки, которые работают десятки минут в одной транзакции, стоит переписать на порционную обработку с фиксацией по частям.
Типичные ошибки при работе с блокировками
Самая распространённая ошибка администратора — перезагрузка сервера как универсальное лекарство. Да, блокировки снимутся, но причина останется, а незавершённые процессы оборвутся. Через час ситуация повторится. Диагностика занимает 10–15 минут и решает проблему надолго.
Вторая ошибка — требовать от пользователей «не работать одновременно с одними документами» вместо настройки системы. Блокировки на уровне объекта при редактировании — штатное поведение, и пользователю достаточно объяснить, что значит сообщение «объект редактируется», и как найти, кто его держит. А вот систематические ошибки транзакционных блокировок — это сигнал к технической работе, а не к инструктажу персонала.
Как проверить, что проблема решена
После завершения блокирующего сеанса или переноса регламентных заданий нужно убедиться, что конфликты действительно прекратились. Попросите пользователя повторить операцию, которая завершалась ошибкой. Понаблюдайте за базой в течение рабочего дня: не появляются ли новые длительные сеансы, нет ли жалоб в прежнее «проблемное» время.
Как проверить результат
Документ проводится без ошибок с первого раза
Ошибка блокировки повторяется — источник не найден или их несколько
Нет сеансов с аномальной длительностью и зависших соединений
Снова появляются долгоживущие сеансы или фоновые задания
События TLOCK с таймаутами отсутствуют или единичны
Регулярные конфликты по тем же таблицам — нужна доработка кода или расписания
Если ошибки ушли, но периодически возвращаются в одно и то же время — возвращайтесь к расписанию регламентных заданий и анализу журнала. Устойчивое решение почти всегда лежит в плоскости расписания, режима блокировок и качества кода, а не в «лечении симптомов».
Что важно запомнить
Блокировка в 1С — защитный механизм целостности данных, а не неисправность. Ошибки конфликтов решаются диагностикой: найдите сеанс-источник через консоль кластера или технологический журнал, завершите его осознанно и устраните причину — расписание заданий, режим блокировок или проблемный код. Перезагрузка сервера без анализа не решает проблему.
Частые вопросы о блокировках в 1С
Что делать пользователю при ошибке «Конфликт блокировок»?
Не паникуйте и не жмите кнопку многократно. Подождите 30–60 секунд и повторите операцию: чаще всего блокировка уже освобождена. Если ошибка повторяется несколько раз подряд — сообщите администратору, указав, какой документ и в какое время вы проводили.
Кто держит объект, если пишет «объект редактируется»?
В сообщении обычно указан пользователь, открывший объект. Если имя не показано или пользователь уже вышел, администратор может посмотреть активные сеансы: в клиент-серверной базе — через консоль кластера, в файловой — через «Администрирование → Активные пользователи».
Можно ли вообще отключить блокировки, чтобы не было ошибок?
Нет, и это было бы катастрофой для данных: без блокировок два сеанса могли бы одновременно списать один и тот же товар, и остатки превратились бы в мусор. Правильный путь — сокращать длительность и ширину блокировок, а не отключать механизм.
Чем опасен зависший сеанс?
Он может удерживать блокировки бессрочно, блокируя работу других пользователей, и занимать лицензию. Такие сеансы безопасно завершаются из консоли кластера: незавершённая транзакция откатится, данные не пострадают.
Почему ошибки блокировок появляются каждый день в одно время?
Почти наверняка в это время выполняется регламентное задание: обмен данными, загрузка, пересчёт итогов. Откройте консоль заданий, сверьте расписание с временем ошибок и перенесите тяжёлые задачи на нерабочие часы.
Поможет ли переход с файловой базы на серверную?
Да, при числе одновременно работающих пользователей больше нескольких человек клиент-серверный вариант заметно снижает число конфликтов: СУБД управляет блокировками на уровне записей, появляются инструменты диагностики и корректного завершения сеансов.