← На главную

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

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

Причина 1: Ужесточение контроля целостности данных в новых версиях платформы

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

Что необходимо сделать:

1. Вернемся к исходной базе, из которой делалась выгрузка.
2. Выполним полное «Тестирование и исправление» (ТиИ) в режиме Конфигуратора. Обязательно выберем пункты: «Проверка логической целостности», «Проверка ссылочной целостности» и «Реиндексация таблиц».
3. Если база была в клиент-серверном варианте, попробуем обновить статистику и пересчитать итоги в режиме «1С:Предприятие».

Причина 2: Проблемы разрядности платформы (32-бит против 64-бит)

Проанализируем техническую сторону процесса: загрузка тяжелого .dt (более 1 Гб) требует значительных объемов адресного пространства памяти. При использовании 32-битного рабочего процесса rphost существует жесткое ограничение на объем выделяемой памяти (около 2-3 Гб на процесс). Если при распаковке данных из файла этот лимит достигается, операционная система или сам кластер 1С аварийно завершают поток, что и приводит к ошибке «прервано принимающей стороной».

Практика показывает, что переход на 64-битную версию сервера 1С:Предприятия решает проблему в большинстве случаев, так как снимает ограничения на объем оперативной памяти, используемой одним процессом при декомпрессии данных.

Причина 3: Сетевая инфраструктура и тайм-ауты

Часто ошибка возникает из-за того, что клиентская часть (Конфигуратор) и сервер 1С находятся на разных физических машинах. При передаче больших пакетов данных по сети любое микро-зависание или некорректная настройка сетевого оборудования может привести к разрыву соединения.

Рассмотрим шаги по оптимизации сети:

1. Локальная загрузка: Всегда запускайте Конфигуратор для загрузки .dt непосредственно на том сервере, где установлена служба ragent. Это исключит сетевой трафик между клиентом и сервером.
2. Настройка сетевой карты (NIC): На серверной ОС Windows зайдем в свойства сетевого адаптера и отключим функции аппаратного ускорения: IPv4 Checksum Offload, TCP Chimney Offload и Receive Side Scaling (RSS). Эти функции могут некорректно фрагментировать тяжелые пакеты данных 1С.
3. Тайм-ауты в реестре: Увеличим время ожидания отклика. В ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters установим параметр KeepAliveTime (тип DWORD) в значение 60000 (60 секунд).

Причина 4: Журнал регистрации и временные файлы

Иногда загрузка обрывается из-за поврежденного или избыточно большого журнала регистрации. Рассмотрим два способа решения:

1. Очистим журнал регистрации в исходной базе перед выгрузкой.
2. Если используется новый формат журнала (.lgf), попробуем перевести его в старый формат или временно отключить ведение журнала на период загрузки.

Также проверим объем свободного места на диске C: сервера (или там, где расположены папки TEMP). Помним, что при загрузке .dt размером 1 Гб, системе может потребоваться до 5-10 Гб временного пространства для распаковки объектов. Очистим папку snccntxt в каталоге кластера 1С, чтобы исключить конфликты старых сеансовых данных.

Причина 5: Ограничения кластера 1С

Выясним причину в настройках самого кластера. В консоли администрирования 1С (ras/rac или стандартная оснастка) проверим параметры рабочего сервера:

• Безопасный расход памяти за один вызов: Если это значение установлено в ненулевое и маленькое число, загрузка может прерваться. Установим временно в 0 (без ограничений).
• Максимальный объем памяти рабочих процессов: Убедимся, что лимит позволяет процессу rphost «раздуться» до нужного размера.
• Количество соединений на процесс: На время загрузки рекомендуется установить это значение равным 1, чтобы все ресурсы процесса были направлены на одну задачу.

Альтернативный метод: Загрузка через XML-выгрузку

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

1. Создадим пустую файловую информационную базу.
2. Загрузим наш .dt файл в эту файловую базу (как правило, в файловом варианте проверки менее жесткие).
3. В файловой базе через Конфигуратор выгрузим файл конфигурации (.cf).
4. Загрузим этот .cf в пустую серверную базу.
5. Для переноса самих данных используем универсальную обработку «Выгрузка и загрузка данных XML» (доступна на ИТС). Она переносит данные напрямую между базами с идентичными конфигурациями, обходя механизмы упаковки .dt.

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

Работа с SQL-сервером

Проанализируем настройки СУБД (например, MS SQL Server). Перед загрузкой .dt в пустую базу убедимся, что:

• Модель восстановления (Recovery Model): Установлена в значение Simple. Это предотвратит бесконтрольный рост лога транзакций (.ldf) и сэкономит место на диске.
• Права доступа: Пользователь, под которым работает служба сервера 1С, имеет права db_owner в базе SQL.

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