1С: как прервать выполнение запроса в консоли запросов

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

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

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

Как понять, что запрос действительно завис, а не просто долгий

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

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

Прерывание сочетанием Ctrl+Break в толстом клиенте

Основной штатный способ остановить длительную операцию в 1С — сочетание клавиш Ctrl+Break (на многих клавиатурах клавиша помечена Pause/Break). Платформа обрабатывает это прерывание на контрольных точках выполнения и останавливает выполняемый код или запрос, возвращая управление пользователю.

Важное ограничение: Ctrl+Break работает в толстом клиенте, где выполнение идёт в клиентском процессе или клиент может передать сигнал прерывания. В тонком и веб-клиенте это сочетание, как правило, не срабатывает, поскольку вся логика выполняется на сервере, а клиент лишь отображает интерфейс.

Если консоль запросов запущена в управляемом приложении (тонкий клиент), а запрос выполняется в серверном вызове, единственный способ остановить его — воздействовать на серверный сеанс или сам запрос на СУБД.

1. 1
   Убедитесь, что запрос действительно завис, а не выполняется штатно
2. 2
   Нажмите Ctrl+Break в толстом клиенте и подождите реакции платформы
3. 3
   Если прерывание не сработало — откройте консоль кластера и найдите свой сеанс
4. 4
   Завершите сеанс через консоль кластера или снимите запрос на СУБД
5. 5
   Проверьте, что нагрузка на сервере спала и блокировки сняты

Завершение сеанса через консоль кластера серверов

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

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

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

Снятие запроса на стороне СУБД

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

В PostgreSQL активные запросы видны в представлении pg_stat_activity, а прерываются функцией pg_terminate_backend с идентификатором процесса. В Microsoft SQL Server активные запросы смотрят через Activity Monitor или запросы к sys.dm_exec_requests, а снимают командой KILL с номером сессии.

-- PostgreSQL: найти и прервать запрос
SELECT pid, state, query FROM pg_stat_activity WHERE state = 'active';
SELECT pg_terminate_backend(<pid>);

-- MS SQL Server
KILL <session_id>;

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

Ограничение времени выполнения и профилактика

Лучший способ не сталкиваться с зависшими консолями — не давать запросам выполняться бесконечно. Многие консоли запросов (в том числе популярные внешние разработки) имеют настройку ограничения количества выбираемых строк или времени выполнения. Перед отладкой на большой базе включайте выборку первых записей.

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

В отладчике конфигуратора долгий серверный вызов тоже можно остановить командой «Остановить», но только если отладка подключена к нужному сеансу и сервер запущен в отладочном режиме.

Типичные ошибки при прерывании запросов

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

Вторая ошибка — завершение сеанса «наугад» в консоли кластера без проверки пользователя и времени начала. В базе с десятками активных сеансов легко оборвать работу коллеги.

Как проверить, что запрос действительно остановлен

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

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

Частые вопросы