← На главную

При работе с клиент-серверными базами 1С (на базе MS SQL или PostgreSQL) администраторы часто сталкиваются с ситуацией, когда невозможно выполнить выгрузку информационной базы в файл .dt. Система выдает сообщение о том, что база занята фоновым заданием, хотя в списке активных пользователей в режиме «1С:Предприятие» никого нет. Рассмотрим подробно, почему это происходит и как решить проблему, используя стандартные и системные инструменты. Для автоматизации выгрузки можно использовать скрипт создания dt-файлов MS SQL и PostgreSQL без закрытия сессий.

Разберем причину возникновения блокировки

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

Шаг 1: Блокировка регламентных заданий в консоли кластера

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

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

После этого действия планировщик перестанет инициировать новые фоновые процессы. Теперь можно повторно зайти в ветку «Сеансы» и завершить оставшиеся там записи. Для быстрого контроля и остановки таких процессов подойдёт обработка для управления регламентными и фоновыми заданиями.

Шаг 2: Разграничение понятий «Сеансы» и «Соединения»

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

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

Шаг 3: Работа на стороне SQL-сервера

Если средства 1С не помогают, проанализируем состояние базы непосредственно на SQL-сервере. Для этого воспользуемся SQL Server Management Studio (SSMS). Посмотрим на активные процессы, используя стандартную процедуру:

EXEC sp_who2;

В колонке DBName найдем нашу базу. Если мы видим процессы (SPID), которые до сих пор активны, их необходимо принудительно завершить. Выполним команду:

KILL [номер_вашего_spid];

Важный момент: если вы используете PostgreSQL, аналогичное действие выполняется через запрос к таблице pg_stat_activity и функцию pg_terminate_backend(pid).

Шаг 4: Принудительное завершение процессов rphost

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

1. Запустим Диспетчер задач на сервере приложений 1С.
2. Найдем все процессы с именем rphost.exe.
3. Посмотрим на потребление памяти. Если база всего одна, можно смело завершать процесс. Если баз много, определите нужный rphost через консоль 1С (в свойствах рабочего процесса указан его PID).
4. Завершим процесс. Кластер автоматически перезапустит новый rphost, но «зависшие» в памяти блокировки исчезнут.

Шаг 5: Использование кода разрешения

Чтобы зайти в базу для выгрузки, когда установлена блокировка сеансов, удобно использовать параметр Код разрешения. Разберем по шагам:

1. В свойствах базы в консоли (там же, где мы блокировали задания) установим «Блокировка начала сеансов включена».
2. В поле «Код разрешения» впишем любое слово, например, AdminBackup.
3. Запустим конфигуратор, добавив в строку запуска параметр: /UC AdminBackup.

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

Шаг 6: Проверка внешних источников и ODBC

Выясним еще одну редкую причину. Если ваша конфигурация обращается к внешним базам данных через ВнешниеИсточникиДанных, фоновое задание может ожидать ответа от стороннего сервера. В этом состоянии процесс 1С находится в режиме ожидания ядра ОС и может не реагировать на команды завершения из консоли 1С. В этом случае поможет только разрыв сетевого соединения или перезапуск службы 1C:Enterprise 8.3 Server Agent.

Резюме и рекомендации

Для успешной выгрузки .dt в условиях «зависших» заданий мы рекомендуем придерживаться следующего чек-листа:

• Блокируйте регламентные задания в свойствах ИБ.
• Проверяйте наличие спящих соединений через sp_who2 на SQL.
• Используйте утилиту rac, если графическая консоль зависает.
• При наличии возможности — очищайте серверный кэш (папки sncfg) при остановленной службе, если фантомные сеансы появляются регулярно.

Помните, что использование .dt для резервного копирования больших баз на SQL является не самым оптимальным способом. Для регулярных бэкапов лучше использовать средства самой СУБД (создание .bak файлов), которые не требуют выгона пользователей и монопольного доступа.