Блокировка базы 1С: как снять блокировку без потери данных

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

Главный риск при самостоятельном снятии блокировки — прервать реально идущий процесс: обновление конфигурации, реструктуризацию таблиц или резервное копирование. Принудительное завершение таких операций может привести к повреждению базы и потере данных. Поэтому первый шаг всегда диагностический: убедиться, что никакой важный процесс не выполняется, и только потом действовать.

Ниже разобраны рабочие способы для файлового и клиент-серверного вариантов работы 1С, а также типичные ошибки и признаки того, когда лучше остановиться и привлечь специалиста.

Как определить причину блокировки базы 1С

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

Административная блокировка сеансов. Устанавливается администратором вручную (или автоматически при обновлении конфигурации через поддержку). Пользователи видят сообщение с текстом блокировки и временем окончания. В файловой базе признак — наличие файла 1Cv8.cdn в каталоге базы.

Монопольный режим. Кто-то запустил конфигуратор или процедуру, требующую исключительного доступа. Остальные пользователи не могут войти. Часто монопольный режим «зависает», если сеанс завершился аварийно.

Зависшие сеансы и соединения. Пользователь закрыл программу некорректно (обрыв сети, сбой ПК), но сеанс на сервере или в файловой базе остался активным. База считает, что работа продолжается.

Блокировки на уровне СУБД. В клиент-серверном варианте (MS SQL, PostgreSQL) транзакция одного пользователя может удерживать блокировку записей и мешать другим. Это не «блокировка базы» в целом, но по симптомам похоже — пользователи жалуются, что «всё зависло».

Снятие блокировки в файловой базе 1С

Файловый вариант — самый частый случай в небольших организациях. Здесь блокировка соединений хранится в служебном файле 1Cv8.cdn, который лежит в каталоге базы рядом с файлом 1Cv8.1CD.

Порядок действий такой. Сначала убедитесь, что все пользователи вышли из программы, а на компьютере администратора не запущен конфигуратор с обновлением. Затем откройте каталог базы и проверьте наличие файла 1Cv8.cdn. Если файл есть, а никаких регламентных операций не выполняется — удалите его. После удаления база снова станет доступна для входа.

Если файл 1Cv8.cdn отсутствует, но войти не получается из-за монопольного режима, причина почти всегда в зависшем сеансе. Найдите компьютер, на котором могла остаться запущенной 1С (в том числе в свёрнутом виде или на терминальном сервере), и завершите процесс 1cv8.exe через диспетчер задач. При общем доступе по сети проверьте все рабочие станции.

После снятия блокировки обязательно проверьте журнал регистрации: если блокировку устанавливало автоматическое обновление, возможно, оно не завершилось. В этом случае конфигурацию нужно дообновить, иначе база останется в несогласованном состоянии.

1. 1
   Попросите всех пользователей выйти из 1С и убедитесь, что никто не запускал обновление или копирование
2. 2
   Откройте каталог информационной базы и найдите файл 1Cv8.cdn
3. 3
   Если файл есть и регламентные операции завершены — удалите его
4. 4
   Проверьте диспетчер задач на всех компьютерах и завершите зависшие процессы 1cv8.exe
5. 5
   Попробуйте войти в базу в режиме предприятия
6. 6
   Откройте журнал регистрации и убедитесь, что обновление конфигурации не было прервано

Снятие блокировки в клиент-серверном варианте

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

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

Для автоматизации и случаев, когда консоль недоступна, используется утилита командной строки rac из состава сервера 1С. С её помощью можно программно снять блокировку сеансов и регламентных заданий.

rac infobase --cluster=<ID_кластера> update --infobase=<ID_базы> --infobase-user=Админ --infobase-pwd=*** --sessions-deny=off --denied-message="" --scheduled-jobs-deny=off

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

Завершение зависших сеансов и процессов

Зависший сеанс — самая частая причина «вечной» блокировки. В файловом варианте сеанс умирает вместе с процессом на компьютере пользователя, поэтому достаточно завершить 1cv8.exe через диспетчер задач на нужной машине. Если база лежит на сетевом ресурсе, дополнительно проверьте открытые файлы на файловом сервере (оснастка «Управление компьютером — Открытые файлы») и закройте зависшие дескрипторы файла 1Cv8.1CD.

В клиент-серверном варианте сеанс живёт на сервере 1С, поэтому завершать его нужно именно через консоль кластера или rac, а не на компьютере пользователя. Крайний случай — перезапуск службы агента сервера 1С: это сбрасывает все сеансы разом, но прерывает работу всех пользователей всех баз кластера, поэтому применяйте его только когда точечное удаление сеансов не помогло.

На стороне СУБД (MS SQL, PostgreSQL) могут оставаться зависшие соединения и транзакционные блокировки. Их видно в активности сервера (Activity Monitor в MS SQL, представление pg_stat_activity в PostgreSQL). Завершение таких процессов — задача администратора СУБД: ошибочное завершение активной транзакции приведёт к её откату, что обычно безопасно, но при массовых операциях может занять много времени.

Блокировка регламентных заданий и её снятие

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

В клиент-серверном варианте флаг снимается в свойствах информационной базы в консоли кластера («Блокировка регламентных заданий включена») или командой rac с параметром --scheduled-jobs-deny=off. В файловом варианте управление доступно из режима предприятия: «Администрирование — Обслуживание — Регламентные операции — Регламентные и фоновые задания», а также через консоль заданий, если она встроена в конфигурацию.

Учтите, что блокировка регламентных заданий часто устанавливается автоматически при восстановлении базы из копии на тестовом сервере — это защита от случайной отправки данных из копии. Если вы развернули рабочую копию и задания не запускаются, проверьте этот флаг в первую очередь.

Типичные ошибки при снятии блокировки

Самая опасная ошибка — снятие блокировки «вслепую», без проверки, кто и зачем её установил. Если администратор заблокировал базу для регламентных работ, а пользователь снял блокировку через удаление 1Cv8.cdn, одновременная работа во время реструктуризации может привести к ошибкам и рассогласованию данных.

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

Третья ошибка — игнорирование журнала регистрации после снятия блокировки. Именно там видно, какое событие установило блокировку и завершилось ли оно. Без этой проверки легко пропустить незавершённое обновление конфигурации.

Как проверить результат и предотвратить повторение

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

Чтобы блокировки не становились проблемой в будущем, настройте регламент: выполняйте обновления и копирование в нерабочее время, заранее устанавливая блокировку с понятным текстом для пользователей и кодом разрешения для администратора. Код разрешения (параметр /UC при запуске) позволяет администратору входить в заблокированную базу без снятия блокировки для всех.

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

Частые вопросы о блокировке базы 1С