Администрирование · 12 мин
Как избавиться от блокировок 1С: пошаговое руководство
Почему возникают блокировки в 1С, как найти зависший сеанс, снять блокировку без потери данных и настроить систему, чтобы проблема не повторялась.
Блокировка в 1С — это защитный механизм, который не даёт двум пользователям одновременно изменять одни и те же данные. Проблемы начинаются, когда блокировка «зависает»: программа сообщает «Конфликт блокировок», «Объект заблокирован» или «Ошибка разделения доступа к базе», хотя никто объект на самом деле не редактирует. Чаще всего причина — аварийно завершённый сеанс, который сервер ещё считает активным.
Способ снятия блокировки зависит от режима работы: файловая база или клиент-серверная (SQL). В файловом варианте достаточно найти и закрыть лишний сеанс либо удалить устаревший файл блокировки. В клиент-серверном варианте сеансы управляются через консоль кластера серверов 1С, а избыточные блокировки часто снимаются настройкой управляемого режима.
Прежде чем что-либо принудительно завершать, убедитесь, что блокирующий сеанс действительно «мёртвый», а не принадлежит коллеге, который сейчас проводит документы. Принудительное завершение живого сеанса приводит к потере несохранённых данных и, в худшем случае, к незавершённым транзакциям.
Как определить тип блокировки и её источник
Текст ошибки подсказывает, с чем вы имеете дело. Сообщение «Конфликт блокировок при выполнении транзакции» означает, что два сеанса спорят за одни данные прямо сейчас — это рабочая ситуация, и часто достаточно повторить действие через минуту. Сообщение «Ошибка разделения доступа» или «База данных заблокирована» указывает на монопольный режим или зависший сеанс, который держит базу целиком.
Откройте в конфигураторе или в пользовательском режиме раздел «Администрирование → Активные пользователи». Там видно, кто подключён, когда начался сеанс и как долго он бездействует. Сеанс с давним временем начала и отсутствием активности — первый кандидат на завершение. Если сотрудник, указанный в списке, уже ушёл домой, а его компьютер выключен, сеанс почти наверняка «зависший».
Повторить операцию позже или найти второго пользователя, работающего с тем же объектом
Проверить список активных пользователей и сеансы в консоли кластера
Уточнить у указанного пользователя, закончил ли он редактирование
Проверить файл 1Cv8.1CL в каталоге базы или состояние сервера SQL
Снятие блокировки в файловой базе
В файловом варианте самый частый виновник — сеанс, который остался в списке активных после аварийного закрытия программы (выключили компьютер, оборвалась сеть, произошёл сбой). Зайдите в базу под пользователем с правами администратора, откройте «Активные пользователи» и завершите лишний сеанс кнопкой «Завершить». После этого попросите пострадавшего пользователя повторить операцию.
Если войти в базу не удаётся вообще, а вы точно знаете, что все пользователи вышли, проверьте каталог базы. Рядом с файлом 1Cv8.1CD может остаться служебный файл 1Cv8.1CL — журнал блокировок. При штатной работе он удаляется автоматически при выходе последнего пользователя. Если все сеансы закрыты, а файл остался, удалите его вручную и запустите базу снова.
Дополнительный источник проблем в файловом режиме — работа по сети через общую папку. Медленная сеть и антивирус, сканирующий каталог базы «на лету», провоцируют ложные блокировки и повреждение файлов. Добавьте каталог базы в исключения антивируса на сервере и на всех клиентских машинах.
Снятие блокировки в клиент-серверном варианте
В клиент-серверной архитектуре сеансами управляет сервер 1С:Предприятия. Откройте консоль администрирования серверов, найдите нужный кластер, раскройте ветку «Сеансы» и отсортируйте по времени последней активности. Зависший сеанс — тот, у которого нет активности длительное время, а пользователь физически не работает. Выделите его и выберите «Удалить».
Если блокировка держится на уровне СУБД (MS SQL, PostgreSQL), а сеанса в консоли 1С уже нет, проблему ищите на стороне сервера баз данных. Для MS SQL зависшие процессы видны в Activity Monitor или запросом к системным представлениям; «висячий» процесс с открытой транзакцией завершают командой KILL с номером процесса. Эту операцию должен выполнять администратор СУБД — ошибка в выборе процесса оборвёт работу живого пользователя.
Когда базу нужно срочно освободить для регламентных работ (обновление, загрузка данных), используйте штатный механизм: в консоли кластера в свойствах базы установите блокировку начала сеансов и сообщение для пользователей, дождитесь завершения текущих сеансов, затем принудительно завершите оставшиеся. Это аккуратнее, чем перезагрузка сервера.
- 1Прочитайте текст ошибки и определите: конфликт транзакций, монопольный режим или заблокированный объект
- 2Откройте список активных пользователей или сеансов в консоли кластера
- 3Найдите сеанс без активности и убедитесь, что его владелец не работает
- 4Завершите зависший сеанс штатной командой
- 5Попросите пользователя повторить операцию и проверьте, что объект записался
- 6Если блокировка осталась — проверьте процессы на стороне СУБД с участием администратора
Профилактика: как сделать, чтобы блокировки не повторялись
Разовое снятие блокировки решает симптом, но не причину. Если конфликты возникают регулярно, настройте автоматическое завершение неактивных сеансов. В свойствах базы в консоли кластера задаются параметры: «завершать спящие сеансы через» и «разрывать соединения». Разумные значения — завершение спящего сеанса через 8 часов, разрыв соединения через несколько часов после засыпания. Это убережёт от накопления «мёртвых» сеансов за выходные.
Второе направление — режим управляемых блокировок. В свойствах конфигурации проверьте параметр «Режим управления блокировкой данных»: значение «Управляемый» заметно снижает число конфликтов в многопользовательской работе по сравнению с автоматическим режимом. Перевод на управляемый режим требует анализа кода конфигурации, поэтому для типовых решений ориентируйтесь на настройки поставщика, а для доработанных — привлекайте разработчика.
Третья мера — разнести тяжёлые операции по времени. Проведение больших документов, закрытие месяца, обмены данными и резервное копирование, запущенные одновременно в рабочие часы, гарантированно создают взаимные блокировки. Перенесите регламентные задания и обмены на ночь или на периоды минимальной активности пользователей.
Как выбрать действие
Частые ошибки при борьбе с блокировками
Самая распространённая ошибка — перезагрузка сервера или клиентского компьютера «чтобы сбросить всё». Это не лечит причину, а при активных транзакциях создаёт риск повреждения данных. Вторая ошибка — удаление файла 1Cv8.1CL, когда кто-то из пользователей ещё работает: файл блокировки защищает базу от одновременной записи, и его удаление при живом сеансе опасно.
Третья типичная ситуация — администратор завершает сеанс, ориентируясь только на имени пользователя, не проверив активность. Сеанс может принадлежать фоновому заданию или обмену данными, и его обрыв приведёт к незавершённой загрузке. Всегда смотрите на колонки «Начало сеанса», «Последняя активность» и тип клиента.
Как проверить, что проблема решена
После снятия блокировки попросите пользователя повторить операцию, при которой возникала ошибка: открыть документ, провести его, записать элемент справочника. Успешное выполнение без сообщений о конфликте — первый признак нормы. Затем откройте список активных пользователей и убедитесь, что в нём нет сеансов без активности старше текущего рабочего дня.
Для клиент-серверной базы дополнительно проверьте журнал регистрации: там видно, какой сеанс был завершён принудительно и не было ли ошибок транзакций в момент обрыва. Если в журнале появляются повторяющиеся ошибки взаимоблокировок (deadlock), проблема глубже — в коде конфигурации или в плане запросов, и требуется анализ разработчиком.
Как проверить результат
Документ проводится, объект записывается без ошибок
Ошибка блокировки возвращается сразу или через короткое время
Все сеансы принадлежат реально работающим сотрудникам
Есть сеансы без активности от вчерашнего дня и старше
Нет повторяющихся ошибок транзакций
Регулярные записи о взаимоблокировках
Жалобы на блокировки прекратились
Конфликты возникают в одно и то же время — значит, мешает регламентное задание
Границы самостоятельной работы
Завершение зависшего сеанса, удаление устаревшего файла блокировки при пустой базе и настройка тайм-аутов — задачи, которые может выполнить администратор без глубокой подготовки, соблюдая описанные предосторожности. Эти действия обратимы и не меняют структуру данных.
К специалисту стоит обращаться, если: блокировки сопровождаются ошибками СУБД, база не открывается после сбоя, в журнале регистрации регулярные взаимоблокировки, либо требуется перевод конфигурации на управляемый режим блокировок. В этих случаях нужен анализ кода, запросов и индексов — самостоятельные эксперименты на рабочей базе могут усугубить ситуацию. Перед любыми серьёзными вмешательствами сделайте актуальную резервную копию.
Что важно запомнить
Блокировка 1С почти всегда снимается завершением зависшего сеанса — через список активных пользователей в файловой базе или консоль кластера в клиент-серверной. Не удаляйте файлы и не перезагружайте сервер, пока не убедились, что пользователи вышли. Для профилактики настройте тайм-ауты сеансов, управляемый режим блокировок и разнесите тяжёлые регламентные операции по времени.
Частые вопросы
Что делать, если ошибка конфликта блокировок появляется у одного и того же пользователя?
Проверьте, не запущено ли у него два сеанса одновременно — например, тонкий клиент и веб-клиент. Затем посмотрите, какие фоновые задания выполняются от его имени. Если сеанс один и заданий нет, вероятна проблема с конкретным документом или настройками прав — попробуйте выполнить операцию под другим пользователем для сравнения.
Можно ли снять блокировку без прав администратора?
Завершить чужой сеанс без административных прав нельзя. Обычному пользователю доступно только одно действие: подождать и повторить операцию. Если блокировка держится дольше нескольких минут, обратитесь к администратору базы и назовите текст ошибки и объект, с которым работали.
Опасно ли принудительное завершение сеанса?
Завершение «мёртвого» сеанса безопасно — данные в нём уже не записываются. Опасно завершать активный сеанс: несохранённые данные пользователя будут потеряны, а незавершённая транзакция может оставить объект в промежуточном состоянии. Поэтому перед удалением сеанса всегда проверяйте время последней активности.
Почему блокировки возникают каждую ночь в одно и то же время?
Почти наверняка в это время выполняется регламентное задание: обмен данными, резервное копирование, пересчёт итогов или загрузка курсов. Откройте список регламентных и фоновых заданий, найдите задание с совпадающим расписанием и перенесите его на время, когда пользователи не работают, либо сократите объём обрабатываемых данных.
Поможет ли переход с файловой базы на клиент-серверную?
Да, при большом числе одновременно работающих пользователей клиент-серверный вариант обрабатывает конкурентный доступ заметно надёжнее: блокировками управляет СУБД, а зависшие сеансы видны и управляются централизованно. Однако переход требует отдельного сервера, установки СУБД и настройки — это проект, а не быстрое исправление.
Что такое взаимоблокировка (deadlock) и как с ней бороться?
Взаимоблокировка — ситуация, когда два сеанса держат ресурсы, нужные друг другу, и ждут освобождения. СУБД автоматически завершает один из сеансов с ошибкой. Разовый случай не страшен, но регулярные взаимоблокировки указывают на порядок обращения к данным в коде конфигурации — их устранением должен заниматься разработчик с анализом запросов.