Зависшие сеансы и блокировки в серверной базе 1С: порядок действий администратора
Содержание
Блокировку в серверной базе 1С снимают через консоль администрирования кластера: откройте Кластеры → ваш кластер → Информационные базы → база → Сеансы, найдите сеанс, который держит данные, и завершите его через контекстное меню (Удалить). Если нужно выгнать всех пользователей и не пускать новых, в свойствах базы включите «Блокировка начала сеансов включена» и задайте код разрешения. Когда 1С сама блокировку не показывает, ищут виновника уже в СУБД — в MS SQL Server или PostgreSQL.
Типичная картина: в 10:40 бухгалтер проводит закрытие месяца, а у кладовщиков всё встало с ошибкой Превышено максимальное время ожидания предоставления блокировки. Или вечером нужно обновить конфигурацию
, а в базе висят три сеанса людей, которые давно ушли домой. Оба случая решаются за 5–10 минут, если идти по порядку: сначала найти, кто держит, и только потом снимать.
Диагностика: кто держит базу, смотрим в консоли кластера
Консоль администрирования серверов 1С устанавливается вместе с сервером. Подключение к кластеру идёт через агент сервера (порт 1540 по умолчанию). Если консоль не открывается — проверьте, что служба агента запущена и вы входите под администратором кластера, если он задан.
Порядок осмотра:
- Разверните
Центральные серверы 1С:Предприятия → имя сервера → Кластеры → кластер → Информационные базы → нужная база. - Откройте ветку
Сеансы. Здесь видно пользователя, компьютер, приложение (тонкий клиент, конфигуратор, фоновое задание), время начала и время последней активности. - Отсортируйте по колонке с временем вызова СУБД или по времени последней активности. Сеанс, который давно начал вызов и не закончил, — первый подозреваемый.
- Откройте ветку
Блокировкиу той же базы. Там перечислены управляемые блокировки, которые сейчас удерживаются, и сеансы-владельцы. - Ветка
Соединенияпоказывает, через какой рабочий процесс (rphost) идёт работа каждого сеанса.
Если сеанс найден и вы уверены, что его можно оборвать, — контекстное меню → Удалить. Пользователь увидит сообщение о разрыве, незаконченная транзакция откатится.
Завершая сеанс, вы теряете всё, что пользователь не записал. Перед этим позвоните ему: часто достаточно попросить закрыть документ.
Без графической консоли то же самое делают через утилиту rac. Ей нужен запущенный сервер администрирования ras (по умолчанию порт 1545):
rem список кластеров — берём UUID кластера
rac cluster list
rem базы кластера — берём UUID базы
rac infobase summary list --cluster=<uuid_кластера>
rem сеансы конкретной базы
rac session list --cluster=<uuid_кластера> --infobase=<uuid_базы>
rem текущие управляемые блокировки
rac lock list --cluster=<uuid_кластера>
rem завершить выбранный сеанс
rac session terminate --cluster=<uuid_кластера> --session=<uuid_сеанса>
Если на кластере задан администратор, добавьте к каждой команде --cluster-user и --cluster-pwd. Полный список параметров для вашей версии платформы покажет rac help session.
Как работают блокировки 1С и чем от них отличается монопольный режим
Под словом «блокировка» в 1С скрываются три разные вещи. Путают их постоянно, а снимаются они по-разному.
| Что заблокировано | Кто ставит | Как снять |
|---|---|---|
| Данные в транзакции (управляемая блокировка) | Платформа при записи документа, проведении, расчёте | Дождаться конца транзакции или завершить сеанс-владелец |
| Данные на уровне СУБД | MS SQL Server или PostgreSQL | Завершить сеанс 1С; в крайнем случае — процесс в СУБД |
| Вход в базу (блокировка начала сеансов) | Администратор вручную или обработка обновления | Снять флажок в свойствах базы или в самой программе |
Управляемые блокировки. Типовые конфигурации на 8.3 работают в управляемом режиме. Платформа сама блокирует записи регистров, пока идёт транзакция. Второй пользователь, которому нужны те же записи, ждёт около 20 секунд. Не дождался — получает ошибку Превышено максимальное время ожидания предоставления блокировки. Если две транзакции ждут друг друга, одна из них падает с текстом Конфликт блокировок при выполнении транзакции.
Эти блокировки живут в памяти кластера, а не в файле. Поэтому «почистить таблицу блокировок» руками нельзя и не нужно: как только сеанс-владелец завершён, его блокировки исчезают.
Монопольный режим. Это не блокировка данных, а требование: в базе не должно быть других сеансов. Он нужен для обновления структуры базы данных, загрузки файла .dt, тестирования и исправления. Пока кто-то работает, конфигуратор при обновлении выдаст Ошибка блокировки информационной базы для конфигурирования. Значит, сначала выгоняем пользователей — об этом следующий раздел.
Как запретить новые сеансы и завершить работу пользователей
Перед обновлением или сложной операцией базу закрывают на вход. Есть три способа, выбирайте по ситуации.
Через свойства базы в консоли кластера
- В консоли откройте свойства информационной базы.
- Введите имя и пароль администратора информационной базы (не кластера).
- Отметьте «Блокировка начала сеансов включена».
- Заполните время начала и окончания, сообщение для пользователей и «Код разрешения» — например,
obnov77. - Там же отметьте «Блокировка регламентных заданий включена».
- Нажмите «ОК», затем удалите оставшиеся сеансы в ветке
Сеансы.
Сами вы входите с кодом: в строке запуска добавьте параметр /UC obnov77.
То же самое через rac:
rac infobase update --cluster=<uuid_кластера> --infobase=<uuid_базы> ^
--infobase-user="Администратор" --infobase-pwd="пароль" ^
--sessions-deny=on --scheduled-jobs-deny=on ^
--denied-message="Обновление до 21:00" --permission-code=obnov77
Снятие — те же команды с --sessions-deny=off и --scheduled-jobs-deny=off.
Из самой программы
В типовых конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11, ERP) есть встроенная обработка. Путь: Администрирование → Обслуживание → Блокировка работы пользователей (в старых релизах раздел назывался «Поддержка и обслуживание»). Рядом — список «Активные пользователи».
Обработка ставит ту же блокировку, но мягче: пользователи получают предупреждение, у них есть несколько минут, чтобы записать документы, а потом программа закрывается сама.
Для пакетных скриптов есть параметры запуска БСП:
"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /S"srv1c\buh" ^
/N"Администратор" /P"пароль" /C"ЗавершитьРаботуПользователей" /UC obnov77
После работ разблокируют тем же способом с параметром /C"РазрешитьРаботуПользователей".
Сравнение способов
| Способ | Когда удобен | Риск |
|---|---|---|
| Консоль кластера | Срочно, пользователи не отвечают | Сеансы рвутся без предупреждения |
| Обработка в программе | Плановые работы днём | Нужны права администратора в базе |
rac или параметры запуска | Ночные скрипты обновления | Ошибка в UUID — заблокируете не ту базу |
Конфигуратор тоже показывает подключённых: Администрирование → Активные пользователи в его главном меню. Удобно проверить список прямо перед «Обновить конфигурацию базы данных».
Блокировки на уровне СУБД: поиск в MS SQL Server и PostgreSQL
Бывает, что консоль кластера пуста, а запросы всё равно ждут. Или сеанс 1С давно удалён, а в СУБД остался «повисший» процесс с открытой транзакцией. Тогда смотрим прямо в базу данных.
Сначала свяжите процессы. В списке сеансов консоли кластера есть колонка «Соединение с СУБД» — это номер процесса (SPID в MS SQL, pid в PostgreSQL). По нему находите сеанс 1С и пользователя.
MS SQL Server
Запрос показывает, кто кого блокирует:
SELECT r.session_id,
r.blocking_session_id,
r.wait_type,
r.wait_time / 1000 AS wait_sec,
DB_NAME(r.database_id) AS db_name,
t.text AS sql_text
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t
WHERE r.blocking_session_id <> 0;
В колонке blocking_session_id — виновник. Если он сам ни от кого не зависит, это голова цепочки. Детали по блокирующему процессу даст sp_who2 или sys.dm_exec_sessions.
PostgreSQL
SELECT pid,
pg_blocking_pids(pid) AS blocked_by,
usename,
state,
now() - xact_start AS xact_age,
left(query, 200) AS query
FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0;
Для поиска «долгих» открытых транзакций без ожидания уберите условие WHERE и отсортируйте по xact_age. Подозрительны сеансы в состоянии idle in transaction.
Если всё же завершать процесс в СУБД
Порядок — от мягкого к жёсткому:
- Завершить сеанс 1С в консоли кластера — СУБД откатит его транзакцию сама.
- PostgreSQL:
SELECT pg_cancel_backend(<pid>);— отменяет текущий запрос, соединение остаётся. - PostgreSQL:
SELECT pg_terminate_backend(<pid>);; MS SQL:KILL <spid>;— обрывают соединение.
Не убивайте процессы СУБД, если не знаете, какому сеансу 1С они принадлежат. Рабочий процесс 1С получит ошибку соединения, и пострадать могут сразу несколько пользователей этого rphost. Откат большой транзакции в MS SQL тоже идёт не мгновенно: базу может «держать» ещё несколько минут.
Фоновые и регламентные задания, которые держат базу
Частый сюрприз: пользователей нет, а монопольный режим не ставится. В списке сеансов видно приложение «Фоновое задание». Это регламентные операции: загрузка курсов валют, обмен с сайтом, обмен ЭДО, полнотекстовый индекс, обновление агрегатов.
Что делать:
- 🛑 Включите «Блокировка регламентных заданий включена» в свойствах базы, чтобы новые задания не стартовали.
- ⏳ Дождитесь окончания текущих — обычно это минуты.
- ✂️ Завис надолго — удалите сеанс фонового задания в консоли, как обычный.
- 📋 Найдите виновника в программе:
Администрирование → Обслуживание → Регламентные и фоновые задания. Здесь видно расписание и время последнего запуска.
Если одно задание раз за разом блокирует работу днём (например, тяжёлый обмен), перенесите его расписание на ночь. Отключать регламентные задания навсегда не стоит: часть из них отвечает за обновление итогов и очистку устаревших данных.
Очистка кэша сервера 1С и временных файлов
Когда сеансы не удаляются из консоли, после удаления возвращаются, а база ведёт себя странно после обновления, помогает очистка сеансовых данных кластера.
Очистка требует остановки службы агента сервера. Оборвутся все сеансы всех баз этого сервера. Делайте это после работы и предупредите пользователей.
Порядок:
- Завершите сеансы и включите блокировку начала сеансов.
- Остановите службу «Агент сервера 1С:Предприятия 8.3».
- Откройте каталог данных кластера. В Windows по умолчанию это
C:\Program Files\1cv8\srvinfo\reg_1541, в Linux —/home/usr1cv8/.1cv8/1C/1cv8/reg_1541. - Внутри — папки с идентификаторами баз. В папке нужной базы удалите каталоги
snccntx*— это сеансовые данные. - Очистите временную папку пользователя, под которым работает служба.
- Запустите службу и проверьте вход.
Не удаляйте файлы 1CV8Clst.lst и 1CV8Reg.lst — это реестр кластера. Без них сервер «забудет» базы и настройки, и восстанавливать их придётся из резервной копии каталога.
Если зависает отдельный рабочий процесс rphost и съедает память, его можно перезапустить через консоль кластера, не останавливая службу целиком. Но сеансы, которые шли через этот процесс, тоже оборвутся.
Как сделать, чтобы блокировки возникали реже
Снимать блокировки по звонку — тушение пожара. Причины обычно повторяются, и их видно заранее.
- 📆 Разведите тяжёлые операции по времени. Закрытие месяца, перепроведение, перерасчёт себестоимости и массовые обмены — вечером или в обед, когда в базе мало людей.
- 🧾 Не держите транзакцию открытой. Собственные обработки, которые пишут данные в цикле, не должны внутри транзакции ждать ответа пользователя или внешнего сервиса.
- 🔍 Включите технологический журнал. Файл
logcfg.xmlв каталогеconfплатформы. СобытияTLOCK,TTIMEOUTиTDEADLOCKпоказывают, какие объекты и какие операции конфликтуют. - 🧹 Регламентное обслуживание СУБД. Обновление статистики и перестроение индексов по ночам ускоряет запросы. Чем короче запрос, тем короче он держит данные.
- 📊 Проверьте режим блокировки в доработанных конфигурациях. Старые самописные базы иногда остаются в автоматическом режиме, где блокировки ставит сама СУБД и их заметно больше.
- 🔢 Следите за объёмом партий. Обмен, который пишет 50 000 документов одной транзакцией, гарантированно остановит склад. Разбейте его на порции.
Простой ориентир: если ошибки ожидания блокировки появляются чаще раза в день, пора включать технологический журнал и искать конкретную пару операций, а не удалять сеансы вручную.