Сбой с кодом HRESULT=80004005 — одна из самых распространенных и при этом запутанных проблем в системном администрировании связки 1С:Предприятие и MS SQL Server. Как правило, она сопровождается аварийным закрытием сессии и сообщением: «Соединение с сервером баз данных разорвано администратором» или «Неопознанная ошибка». Примечательно, что база данных в режиме «1С:Предприятие» может продолжать работать в штатном режиме, но любые попытки выполнить обслуживание — выгрузить информационную базу в файл .dt, обновить конфигурацию или сделать резервную копию — приводят к краху процесса.
В этой статье мы подробно разберем природу возникновения данной ошибки, проанализируем технические причины сбоя и рассмотрим несколько эффективных и безопасных способов его устранения.
Рассмотрим детально внутренний механизм хранения метаданных. При обновлении конфигурации или ее изменении платформа 1С записывает двоичные файлы поставщика (архивы конфигураций .cf) непосредственно в системную таблицу базы данных под названием Config. Со временем или из-за ошибок обновления размер отдельных записей (блоков данных) в этой таблице может превысить критический порог в 120 МБ.
Когда конфигуратор или служба сервера 1С пытается прочитать и обработать единичный двоичный блок такого размера, СУБД MS SQL пытается выделить под него непрерывный сегмент виртуальной памяти. Если на сервере запущен 32-разрядный сервер приложений 1С, его рабочий процесс rphost.exe имеет жесткое архитектурное ограничение адресного пространства — не более 2 ГБ (а на практике сбой может произойти и при достижении 1.5–1.8 ГБ из-за сильной фрагментации памяти). Процесс не может выделить непрерывный кусок памяти, аварийно завершает свою работу, и администратор получает ошибку HRESULT=80004005.
Важное предупреждение по «грязному» решению проблемы через СУБД:
В некоторых источниках и на форумах предлагают радикальный и крайне небезопасный метод — прямое удаление «тяжелых» строк из таблицы конфигурации через SQL Server Management Studio с помощью запроса:
DELETE FROM dbo.Config WHERE DataSize > 125829120
Мы настоятельно не рекомендуем использовать данный метод на рабочей базе данных! Прямое вмешательство в таблицы СУБД в обход платформы 1С разрушает логическую целостность метаданных, лишает базу конфигурации поставщика и может привести к непредсказуемым ошибкам при последующих обновлениях или динамических изменениях конфигурации.
Разберем по шагам правильный алгоритм действий, позволяющий вернуть базу к штатной работе штатными средствами платформы:
Config..dt..dt..cf, вернитесь в вашу рабочую базу на SQL-сервере, загрузите чистый .cf и заново поставьте конфигурацию на поддержку через сравнение и объединение с оригинальным дистрибутивом поставщика.Проанализируем аппаратный аспект проблемы. Если ваш сервер приложений 1С:Предприятие функционирует в 32-разрядном режиме, операционная система физически не может выделить одному процессу rphost.exe объем оперативной памяти, достаточный для выполнения тяжелых транзакций (таких как свертка базы, расчет итогов или масштабное обновление метаданных). Даже если на самом сервере установлено 12 ГБ, 32 ГБ или более оперативной памяти, 32-битный процесс будет падать при достижении лимита в 2 ГБ.
Решение: Единственным надежным стратегическим решением в данном случае является переход на 64-разрядную версию сервера 1С:Предприятие. В 64-битной архитектуре лимиты адресного пространства процессов практически отсутствуют, что позволяет серверу задействовать весь объем доступной физической памяти для выполнения сложных вычислений.
Выясним причину, связанную со спецификой сетевого взаимодействия между сервером приложений 1С и СУБД MS SQL. Если обе службы развернуты на одном физическом сервере, по умолчанию для обмена данными между ними используется локальный протокол Shared Memory (Общая память).
Этот протокол обеспечивает максимальную скорость передачи данных, однако он крайне чувствителен к микросбоям, утечкам памяти и перегрузкам сокетов. При обработке тяжелых выборок Shared Memory может внезапно прервать сессию с ошибкой HRESULT=80004005.
Для стабилизации соединения переведем взаимодействие на стек протоколов TCP/IP. Выполним настройку по шагам:
127.0.0.1 вместо сетевого имени хоста (или localhost), чтобы принудительно заставить систему маршрутизировать трафик через сетевой стек TCP/IP.Если в вашей ИТ-инфраструктуре используется бесплатная редакция MS SQL Server Express, важно помнить о ее жестких лицензионных ограничениях:
При выполнении регламентных операций в 1С база данных SQL Express мгновенно исчерпывает выделенный ей лимит оперативной памяти, начинает активно сбрасывать кэш на жесткий диск (в файл подкачки), что вызывает колоссальные задержки. В результате сервер 1С обрывает транзакцию по таймауту с ошибкой обрыва соединения.
Решение: Перенесите базу данных на полноценную коммерческую версию MS SQL Server (Standard или Enterprise) либо рассмотрите переход на альтернативную бесплатную СУБД PostgreSQL, которая не имеет искусственных ограничений на использование оперативной памяти процессом СУБД.
Рассмотрим ситуацию, когда оперативный переход на 64-разрядную лицензию сервера 1С невозможен по бюджетным или организационным причинам. В этом случае мы можем снизить вероятность появления ошибки HRESULT=80004005 за счет тонкой настройки параметров кластера 1С через консоль администрирования:
rphost.exe. Добавьте в кластер еще 2–3 рабочих процесса, чтобы нагрузка от пользователей распределялась более равномерно и память отдельного процесса не перегружалась.1500000 КБ (около 1.5 ГБ).30 или 60 секунд.rphost.exe и при достижении критического порога безопасно и незаметно для пользователей перезапустит перегруженный процесс, освободив оперативную память.
Применяя данные подходы комплексно, вы сможете гарантированно избавиться от ошибки прерывания соединения и обеспечить стабильную и бесперебойную работу вашей системы автоматизации бизнеса.