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

1С пишет «база данных заблокирована» — не пытайтесь сразу снять запрет. Сначала сохраните текущее состояние. Файловую базу скопируйте целиком, для клиент-серверной снимите резервную копию средствами СУБД.

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

За одним сообщением скрываются разные причины. Администратор мог закрыть вход на время обновления или резервного копирования. Доступ также перекрывают активный сеанс, Конфигуратор или зависшее фоновое задание.

Сначала определите тип базы

Способ разблокировки зависит от архитектуры. У файловой базы ограничения связаны с каталогом информационной базы. В клиент-серверном варианте сеансами управляют кластер 1С и СУБД.

Откройте окно запуска 1С, выделите базу и нажмите «Изменить». Каталог на диске или сетевой ресурс в настройках означает, что база файловая. Точный путь указан в поле «Каталог».

Если там записаны сервер и имя информационной базы, перед вами клиент-серверный вариант. Искать и завершать сеансы придётся через консоль администрирования кластера. При блокировке транзакцией потребуется диагностика в SQL Server или PostgreSQL.

До любых проверок сделайте копию:

• для файловой базы скопируйте весь каталог вместе с 1Cv8.1CD;
• для клиент-серверной создайте резервную копию штатными средствами СУБД;
• не разворачивайте копию поверх рабочей базы;
• не продолжайте работу, пока пользователи остаются внутри базы.

Копию делают до попытки исправления. Даже штатная операция способна изменить данные или запустить откат транзакции.

Найдите, кто держит блокировку

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

Материал 1C-expert о регламентных заданиях описывает частый сценарий: исполнитель ждёт ресурс, занятый другим сеансом или транзакцией. Упоминание фонового задания ещё не означает, что сбой произошёл внутри него.

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

Клиент уже закрыт, а сеанс остался в списке — завершите только этот сеанс через консоль. Службу кластера не останавливайте. Иначе оборвутся все подключения, включая те, которые не мешали работе.

Вывод: сначала найдите владельца занятого ресурса. Массовый перезапуск сотрёт часть признаков сбоя и оборвёт посторонние сеансы.

Проверьте ожидания в СУБД

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

В SQL Server хранимая процедура sp_who2 выводит активные процессы и ожидания. Поле BlkBy содержит SPID процесса, который удерживает другой запрос. Текущие запросы подробнее видны в представлении sys.dm_exec_requests.

В PostgreSQL подключения показывает представление pg_stat_activity. Проверяйте состояние сеанса, время начала транзакции и выполняемый запрос. Долгая работа сама по себе не повод завершать процесс.

Принудительное завершение процесса в СУБД запускает откат транзакции. Чем больше данных она успела изменить, тем дольше продлится откат. На это последствие отдельно указывает материал 1C-expert.

До завершения выясните владельца процесса и выполняемую операцию. Обмен, закрытие периода или обновление структуры нельзя обрывать без согласования с ответственным за базу. Иначе попытка сократить простой растянет его.

Если базу заблокировало регламентное задание

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

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

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

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

Не запускайте одно задание повторно несколько раз. Каждый новый исполнитель может попасть в ту же очередь и запутать картину. Перед повторным запуском проверьте, что прежний экземпляр закончил работу.

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

Если запрет остался после обновления

На время обновления 1С закрывает новые сеансы. Пользователи не должны менять данные одновременно с реструктуризацией базы.

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

Для этого случая нужен разбор прерванной реструктуризации на отдельной копии. Не запускайте обновление рабочей базы ещё раз, пока не установите этап сбоя.

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

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

Если блокировка осталась после резервного копирования

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

Сначала проверьте, закончила ли СУБД создавать копию. Файл должен существовать, а процесс — прекратить запись в него. После этого проверьте технический сеанс и запрет новых подключений в кластере.

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

Само наличие файла ещё не подтверждает исправность копии. Бэкап пригоден только тогда, когда вы развернули его отдельно и смогли войти.

Если базу удерживает Конфигуратор

Монопольный вход через Конфигуратор закрывает базу для остальных пользователей. Найдите администратора, который открыл её, и попросите завершить работу штатно.

Стороннее руководство 1C-expert называет lock.dbf служебным файлом файловой базы. По описанию, он появляется при монопольном входе и содержит сведения о владельце блокировки. Читаемой официальной документации 1С о составе этого файла среди предоставленных материалов нет.

Поэтому не начинайте восстановление с удаления lock.dbf, .lck или похожих файлов. Набор и назначение таких файлов зависят от версии платформы и режима работы. Ошибка превратит ограничение входа в повреждение базы.

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

Что делать с файловой базой и чужим сеансом

Узнайте путь к базе через кнопку «Изменить» в окне запуска. Скопируйте весь каталог в другое место. Затем убедитесь, что никто не работает с исходной базой.

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

База открывается с другого компьютера или под другим профилем Windows — вероятна локальная проблема. Содержимое каталога не меняйте. Проверьте пользовательский кэш на проблемном компьютере.

Стороннее руководство 1C-expert приводит такой типовой путь:

C:\Users\%Username%\AppData\Local\1C\1Cv8

Ключ /ClearCache очищает локальный кэш клиента. Он не отключает серверный запрет, не завершает чужой сеанс и не освобождает транзакцию в СУБД. Применяйте его только после проверки входа с другого профиля или компьютера.

Вывод: завершать процесс или удалять файл можно лишь после проверки типа базы и владельца блокировки.

Параметры запуска не заменяют диагностику

Для запуска файловой базы используют режим ENTERPRISE и параметр /F с путём к каталогу. /N передаёт имя пользователя, /P — пароль, /UC — код разрешения доступа.

Эти параметры приводит справочник Infostart по командной строке 1С. Материал сторонний, поэтому сверьте синтаксис со справкой для своей версии платформы.

Встречается и такая команда:

1cv8.exe ENTERPRISE /F"ПутьКБазе" /CРазрешитьРаботуПользователей /UCРезервноеКопирование

Её публикует руководство 4ДК по разблокировке файловых баз. Значение после /UC должно совпадать с кодом, который администратор указал при установке запрета. РезервноеКопирование — пример, а не универсальный пароль.

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

Не применяйте /ResetLock, /D или найденную в интернете команду удаления .lck. Предоставленные сторонние материалы по-разному описывают назначение этих параметров. Читаемой документации 1С, которая устраняет расхождение, среди материалов нет.

Порядок входа в заблокированную базу

Идите по одной цепочке:

1. Сохраните состояние: скопируйте каталог файловой базы или создайте резервную копию средствами СУБД.
2. Завершите работу пользователей, но не останавливайте службу кластера.
3. Определите архитектуру базы: файловая или клиент-серверная.
4. Проверьте технический запрет после обновления или резервного копирования.
5. Найдите владельца блокировки по журналу регистрации и списку сеансов.
6. При необходимости разберите ожидания в SQL Server или PostgreSQL.
7. Снимите только найденное ограничение либо завершите один подтверждённый сеанс.
8. Войдите в базу, проверьте журнал, фоновые задания и прикладную операцию.

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

Смежные сценарии собраны в указателе аварийных ситуаций с базой и сервером. Перейдите к нему, если за сообщением о блокировке обнаружилось повреждение файла или падение СУБД.

Если не помогло

До передачи базы другому специалисту сохраните исходное состояние и журнал регистрации. Для клиент-серверной базы также зафиксируйте список сеансов и ожидания СУБД.

Владелец не определяется, копия не открывается или после снятия запрета появились новые ошибки — нужна проверка аварийного состояния 1С и SQL. Объём доступных для возврата данных станет понятен только после диагностики.

Чтобы не повторилось

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

Настройте резервное копирование с проверкой восстановления. Пока копию ни разу не развернули отдельно, вы не знаете, получится ли вернуть из неё базу.

Оставьте четыре контрольные точки:

• обновление не запускается при активных пользователях;
• технический запрет отключается после окончания работ;
• зависшие сеансы попадают в мониторинг;
• резервная копия разворачивается отдельно от рабочей базы.