Что делать, если заблокирована база 1С

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

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

Почему база 1С оказывается заблокированной

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

Проблемы начинаются, когда процесс прерывается: отключилось электричество, администратор закрыл конфигуратор принудительно, оборвалась сеть между сервером 1С и СУБД. Флаг блокировки остаётся, а процесса, который мог бы его снять, уже нет. В файловом режиме похожий эффект даёт оставшийся блокировочный файл после аварийного завершения сеанса.

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

Первые шаги: проверка перед снятием блокировки

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

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

Третий шаг — сделать резервную копию. Даже если база заблокирована, копию можно снять средствами СУБД (для клиент-серверного варианта) или простым копированием каталога базы при отсутствии активных соединений (для файлового). Любые манипуляции с блокировками без свежей копии — неоправданный риск.

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

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

Чтобы снять блокировку, очистите дату начала блокировки сеансов или установите её в прошлое, уберите сообщение и сохраните изменения. После этого пользователи смогут войти. Если блокировка была установлена с кодом разрешения, вход возможен и без снятия — достаточно запустить тонкий клиент с параметром /UC и указать этот код.

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

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

Снятие блокировки в файловом режиме

В файловой базе нет консоли кластера, поэтому действуют иначе. Самый простой случай — оставшийся блокировочный файл. В каталоге базы после аварийного завершения может остаться файл 1Cv8.cdn: именно он сигнализирует платформе о блокировке соединений. Убедитесь, что ни один пользователь не работает с базой, и удалите этот файл. После этого вход станет возможен.

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

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

Блокировки на уровне СУБД и зависшие сеансы

Иногда база доступна, но конкретные операции зависают: документ не проводится, обмен «висит», обновление не стартует. Это признак блокировок на уровне СУБД — один сеанс удерживает записи, а другие ждут. В MS SQL Server такие блокировки видны через Activity Monitor или запросы к системным представлениям, в PostgreSQL — через pg_stat_activity и pg_locks.

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

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

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

Частые ошибки при снятии блокировки

Самая распространённая ошибка — снятие блокировки до выяснения её причины. Администратор видит жалобы пользователей, очищает параметры блокировки, а через десять минут выясняется, что шло обновление, которое теперь прервано. Всегда сначала выясняйте источник блокировки.

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

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

Профилактика: как снизить число зависших блокировок

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

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

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

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

Как войти в базу, не снимая блокировку?

Если при установке блокировки был задан код разрешения, запустите клиент с параметром /UC и этим кодом — вход будет выполнен в обход ограничения. Это удобно администратору для проверки состояния базы, пока остальные пользователи ждут снятия блокировки.

База заблокирована, а код разрешения никто не помнит. Что делать?

Код можно посмотреть или изменить в свойствах информационной базы в консоли кластера (клиент-серверный режим). Если код задан программно в файловой базе и утерян, блокировку снимают через конфигуратор или внешнюю обработку под учётной записью администратора.

Можно ли снять блокировку без прав администратора?

Нет, и это осознанное ограничение: блокировка защищает данные, поэтому управлять ей может только администратор кластера или пользователь с соответствующими правами в базе. Обычному пользователю при сообщении о блокировке нужно обратиться к администратору, а не искать обходные пути.

После снятия блокировки база снова блокируется. В чём причина?

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

Опасно ли удалять файл 1Cv8.cdn?

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

Чем отличается блокировка соединений от блокировки регламентных заданий?

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