Как исправить ошибку «Удаленный хост принудительно разорвал существующее подключение» при выгрузке информационной базы 1С?

← На главную

При выгрузке информационной базы через Конфигуратор в файл выгрузки (.dt) администраторы и разработчики нередко сталкиваются с ошибкой: «Удаленный хост принудительно разорвал существующее подключение. line=1584...». Особенно часто данный сбой проявляется после массовой загрузки в базу двоичных данных (изображений, файлов номенклатуры, сканов документов), из-за чего размер базы существенно увеличивается. Разберем детально, почему возникает эта ошибка и какими способами можно восстановить нормальную выгрузку данных.

Причины возникновения ошибки

Проанализируем техническую сторону процесса. Сообщение о разрыве соединения со стороны удаленного хоста означает, что рабочий процесс сервера 1С (rphost.exe), выполнявший операцию сериализации и упаковки данных, аварийно завершился или был принудительно перезапущен кластером. Выделим основные факторы, приводящие к такому поведению:

Повреждение бинарных данных в таблицах: если в базе присутствуют поврежденные записи в полях с типом ХранилищеЗначения (например, в справочнике ХранилищеДополнительнойИнформации), попытка платформы распаковать или сериализовать такой блок данных приводит к критическому исключению и падению рабочего процесса.
Превышение лимитов оперативной памяти (Out of Memory): при выгрузке базы в .dt сервер выполняет архивацию таблиц в оперативной памяти и во временных файлах. Если используется 32-разрядный сервер 1С:Предприятия или на 64-разрядном сервере исчерпан объем свободной памяти, процесс падает.
Срабатывание настроек кластера 1С: если в параметрах кластера заданы жесткие ограничения на допустимый объем памяти рабочих процессов или интервал их перезапуска, сервер 1С принудительно «убивает» процесс, начавший активно потреблять память.
Нехватка свободного места на диске: переполнение каталогов временных файлов %TEMP% как на стороне сервера, так и на клиенте.

Способ 1. Поиск и исправление поврежденных двоичных данных

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

Выполним тестирование базы в Конфигураторе через меню Администрирование > Тестирование и исправление..., выбрав проверки логической и ссылочной целостности, а также реиндексацию таблиц. Если тестирование также аварийно завершается, перейдем к программному поиску битых элементов.

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


Выборка = Справочники.ХранилищеДополнительнойИнформации.Выбрать();
Пока Выборка.Следующий() Цикл
    Попытка
        Объект = Выборка.ПолучитьОбъект();
        ДвоичныеДанные = Объект.Хранилище.Получить();
    Исключение
        Сообщить("Обнаружен поврежденный элемент: " + Строка(Выборка.Ссылка) + " | Ошибка: " + ОписаниеОшибки());
    КонецПопытки;
КонецЦикла;

Если проблемный элемент обнаружен, но его невозможно удалить штатными средствами из-за внутренней ошибки структуры данных, очистку соответствующей записи выполняют на уровне таблиц СУБД (MS SQL Server) или путем полной перезаписи значения поля в пустую структуру.

Способ 2. Корректировка параметров кластера серверов 1С

Разберем параметры кластера, которые могут прерывать процесс длительной выгрузки. Откроем консоль администрирования серверов 1С:Предприятия и проверим свойства кластера:

Установим параметр «Допустимый объем памяти» в значение 0 (снятие ограничений на время выгрузки).
Установим параметр «Интервал перезапуска рабочих процессов» в значение 0, чтобы рабочий процесс не завершался регламентно прямо посреди формирования файла.
Увеличим параметр «Таймаут контекста» для предотвращения разрыва соединения по неактивности сокетов.

После корректировки настроек перезапустим службу 1C:Enterprise Server Agent и повторим процедуру выгрузки базы.

Способ 3. Запуск выгрузки локально на сервере

Проанализируем влияние сетевых задержек и межсетевых экранов. При передаче больших объемов данных между клиентским компьютером и сервером 1С сетевое оборудование или антивирусное ПО может принудительно закрыть длительную TCP-сессию. Чтобы исключить этот фактор:

Зайдем по RDP непосредственно на сервер, где физически установлена служба 1С.
Запустим Конфигуратор локально, указав в качестве адреса сервера localhost или сетевое имя текущей машины.
Убедимся, что на системном диске сервера в каталоге профиля службы (AppData\Local\Temp) доступно достаточно свободного места — не менее двукратного размера базы данных.
Запустим операцию выгрузки в .dt в локальную папку на сервере.

Способ 4. Переход на резервное копирование средствами СУБД

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

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

Архитектурная рекомендация по оптимизации хранения файлов

Для предотвращения подобных ошибок в будущем рекомендуется перевести хранение присоединенных файлов, сканов и изображений из базы данных на тома на диске (внешние файловые хранилища). Это разгрузит таблицы СУБД от тяжелых LOB-полей, стабилизирует потребление оперативной памяти процессом rphost и ускорит работу всех сервисных процедур 1С.