При работе с тяжелыми или сильно модифицированными конфигурациями, такими как 1С:УПП 1.3 или 1С:УСО, программисты и системные администраторы часто сталкиваются с неприятной ситуацией. Во время процесса «Принять изменения» или просто при сохранении конфигурации в конфигураторе процесс прерывается ошибкой: «Соединение с сервером баз данных разорвано администратором. Microsoft SQL Native Client: Shared Memory Provider: No process is on the other end of the pipe. HRESULT=80004005». Проанализируем причины этой проблемы и разберем по шагам проверенные способы ее решения.
Ошибка с кодом native=233 и HRESULT=80004005 сигнализирует о том, что клиент (в данном случае сервер 1С) пытался отправить большой объем данных (новую конфигурацию) в SQL-сервер, но соединение было принудительно разорвано на стороне СУБД или сетевого уровня. Это происходит из-за того, что стандартный размер сетевого пакета SQL Server не рассчитан на передачу огромных объектов конфигурации (BLOB), которые в современных базах могут занимать сотни мегабайт. Разберем основные способы устранения этой неисправности.
Как показывает практика и опыт многих специалистов, это самое эффективное решение для MS SQL Server 2005 и 2008. По умолчанию SQL Server использует пакеты размером 4096 байт, чего недостаточно для стабильной записи конфигурации 1С. Рассмотрим, как изменить этот параметр:
Network Packet Size.32767 (максимально допустимое) или хотя бы удвоим его (например, до 8192). Однако для гарантированного результата рекомендуется ставить именно максимум.Важное примечание: Перезапуск служб SQL Server обычно не требуется, изменения вступают в силу для новых соединений. Достаточно будет перезапустить Конфигуратор 1С. Однако стоит учитывать, что при использовании зашифрованных соединений лимит может быть ограничен значением 16383.
Проанализируем ситуацию, когда ошибка вылетает с упоминанием Shared Memory Provider. Это означает, что сервер 1С и SQL Server находятся на одной физической машине и общаются через общую память. Иногда этот механизм работает нестабильно при передаче больших пакетов. Попробуем заставить систему работать через TCP/IP:
Shared Memory и Named Pipes, оставив включенным только TCP/IP.TCP/IP на вкладке IP Addresses убедимся, что в разделе IPAll указан порт 1433.Такая настройка часто помогает избежать проблем с «порванными каналами» (pipes), так как стек TCP/IP более устойчив к передаче больших потоков данных.
Иногда процесс сохранения блокируется «мусором» в системных таблицах 1С внутри базы данных SQL. Если предыдущие шаги не помогли, стоит попробовать очистить таблицы, где хранятся промежуточные изменения конфигурации. Проанализируем последовательность действий в SSMS:
-- ПРЕДУПРЕЖДЕНИЕ: Все несохраненные изменения в конфигураторе будут потеряны!
-- Перед выполнением обязательно сделайте бэкап базы.
TRUNCATE TABLE dbo._ConfigSave;
TRUNCATE TABLE dbo._ConfigSaveInfo;
После выполнения этих команд попробуйте зайти в конфигуратор и снова загрузить или обновить конфигурацию. Это позволит системе начать запись «с чистого листа» в базе данных.
В некоторых случаях (особенно на платформе 8.3) проблема может крыться в зависших сессиях или кэше соединений самого сервера приложений 1С. Рассмотрим простую, но эффективную процедуру:
Этот метод сбрасывает все внутренние идентификаторы соединений кластера и часто устраняет проблему без изменения настроек SQL-сервера.
Для баз данных 1С критически важна правильная настройка параллелизма в SQL Server. Если при сохранении конфигурации SQL пытается распараллелить запрос на множество ядер, это может вызвать взаимные блокировки. Посмотрим, как это проверить:
Max Degree of Parallelism (MAXDOP).1. Это гарантирует, что каждый запрос будет выполняться одним ядром процессора, что исключает ряд специфических ошибок при работе с метаданными.Если вы столкнулись с похожей проблемой на СУБД PostgreSQL, решение будет иным. В файле postgresql.conf следует обратить внимание на параметры, отвечающие за объем передаваемых данных и время ожидания:
max_wal_size и checkpoint_timeout, так как обновление конфигурации — это одна огромная транзакция.max_stack_depth. Для больших конфигураций его рекомендуется увеличить до 4MB.Таким образом, мы рассмотрели комплекс мер по устранению разрыва соединения. Наиболее вероятным и быстрым решением остается изменение Network Packet Size, что позволяет серверу баз данных корректно обрабатывать тяжелые пакеты метаданных 1С.