При выполнении тяжелых регламентных операций в 1С, таких как групповое перепроведение документов, пользователи часто сталкиваются с внезапным прерыванием процесса и сообщением об ошибке: SQL: HRESULT=80004005, SQLSTATE=08S01, native=64. Эта ситуация особенно характерна для связки платформы 8.3.13 (и выше) с MS SQL Server. Давайте подробно разберем причины возникновения этой проблемы и пошагово проанализируем методы ее решения.
Для начала выясним причину с технической точки зрения. Комбинация HRESULT=80004005 и SQLSTATE=08S01 указывает на общую ошибку сетевого взаимодействия, но решающее значение здесь имеет параметр native=64. В системе Windows этот код расшифровывается как "Указанное сетевое имя более недоступно" (The specified network name is no longer available). Это означает, что операционная система по какой-то причине разорвала TCP-соединение между рабочим процессом 1С (rphost.exe) и сервером баз данных (sqlservr.exe).
Разберем основные уровни, на которых может происходить этот сбой: настройки сетевых карт, конфигурация SQL-сервера, дисковая подсистема и параметры виртуализации.
Одной из наиболее скрытых причин разрыва соединений является использование технологий разгрузки процессора сетевой картой. При групповом перепроведении генерируется огромный поток мелких сетевых пакетов. Функции TCP Chimney Offload и RSS могут некорректно обрабатывать такие очереди, что приводит к кратковременному "замиранию" адаптера и сбросу сессии.
Проанализируем состояние сетевого стека. Для этого запустим командную строку от имени администратора и выполним проверку параметров:
netsh int tcp show global
Если вы видите, что параметры Chimney Offload State или Receive-Side Scaling State включены, их рекомендуется деактивировать. Рассмотрим команды для отключения этих функций, которые помогут стабилизировать соединение:
netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
netsh int tcp set global netdma=disabled
После выполнения этих команд сетевой стек будет обрабатываться центральным процессором более предсказуемо для 1С, что исключит микроразрывы из-за "умных" функций железа.
Часто проблема кроется в том, как SQL Server распределяет нагрузку при выполнении сложных запросов, инициированных перепроведением. Проанализируем два критически важных параметра: MAXDOP и протокол взаимодействия.
Максимальная степень параллелизма (MAXDOP). Если этот параметр установлен в значение 0 (по умолчанию), SQL Server может попытаться задействовать все доступные ядра процессора для выполнения одного тяжелого запроса. В контексте 1С это часто приводит к взаимным блокировкам и таймаутам. Рекомендуем установить значение Max Degree of Parallelism равным 1 (для исключения параллелизма в запросах) или, как минимум, ограничить его до 4-8 ядер.
Протокол Shared Memory. Если сервер приложений 1С и SQL Server установлены на одной физической или виртуальной машине, мы можем полностью исключить сетевой уровень из цепочки взаимодействия. Для этого в SQL Server Configuration Manager проверим, включен ли протокол Shared Memory. Использование общей памяти вместо TCP/IP не только повышает скорость обмена данными, но и делает соединение нечувствительным к ошибкам сетевого стека операционной системы.
Групповое перепроведение документов активно создает и удаляет временные таблицы в базе TempDB. Если диск, на котором расположена эта база, не справляется с нагрузкой или файл TempDB настроен на слишком маленькие шаги автоматического роста (например, по 1 МБ), возникают задержки записи.
Рассмотрим рекомендации по настройке TempDB:
TempDB, чтобы серверу не приходилось расширять их во время работы.native=64.TempDB на самый быстрый доступный диск (SSD/NVMe).Выясним, не мешает ли антивирус процессам обработки данных. Во время перепроведения файлы баз данных (.mdf, .ldf) и временные файлы сервера 1С подвергаются интенсивной модификации. Антивирус может блокировать доступ к файлу на время сканирования.
Необходимо добавить в исключения антивируса следующие объекты:
sqlservr.exe, rphost.exe, ragent.exe, rmngr.exe.*.mdf, *.ldf, *.ndf.C:\Program Files\1cv8\srvinfo).Если ваши серверы работают на базе Hyper-V или VMware, проанализируем настройки памяти. Использование функции Dynamic Memory (динамическая память) крайне не рекомендуется для серверов баз данных и серверов 1С. Когда гипервизор пытается "откусить" память у виртуальной машины или добавить ее, происходит кратковременная приостановка работы гостевой ОС (stun). Для SQL Server задержка даже в 500 миллисекунд может стать критичной и привести к разрыву TCP-сессии.
Решение: Установим статический объем оперативной памяти для виртуальных машин с 1С и SQL Server.
Если вышеперечисленные меры не помогли, нам потребуется более детальная информация. Настроим сбор Технологического журнала 1С, чтобы поймать момент разрыва соединения. Создадим файл logcfg.xml в папке conf сервера 1С со следующим содержанием:
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<log location="C:\LOGS\DBMSSQL" history="24">
<event>
<eq property="Name" value="DBMSSQL"/>
</event>
<event>
<eq property="Name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>
Проанализируем полученные логи после возникновения ошибки. События EXCP (исключения) и DBMSSQL покажут нам текст запроса, на котором произошел сбой, и время ожидания ответа от сервера. Это поможет понять, является ли проблема следствием блокировок или это чистый разрыв связи на уровне ОС.
Подводя итог, отметим, что ошибка 80004005 native=64 редко связана с кодом самой конфигурации 1С. Чаще всего это симптом нестабильности инфраструктуры под высокой нагрузкой. Последовательная настройка сетевого стека, параметров SQL и исключение влияния антивирусов позволяют полностью избавиться от этой проблемы при групповом перепроведении документов.