Как исправить ошибку «Поставщик общей памяти: С обоих концов канала отсутствуют процессы» при подключении 1С к SQL Server?

Иногда при попытке зайти в базу 1С (как в режиме Предприятия, так и в Конфигуратор), развернутую локально на MS SQL Server (часто в редакции Express), возникает критическая ошибка. Сеанс работы завершается администратором, а в подробностях фигурирует сообщение: Microsoft SQL Server Native Client 11.0: Поставщик общей памяти: С обоих концов канала отсутствуют процессы. HRESULT=80004005, native=233. При использовании сетевого протокола ошибка может выглядеть так: Поставщик TCP: Удаленный хост принудительно разорвал существующее подключение, native=10054.

Проанализируем причины такого поведения и разберем по шагам доступные способы восстановления работоспособности базы.

Почему возникает ошибка обрыва связи с СУБД?

Разберем основные факторы, которые могут приводить к принудительному завершению сеанса:

1. Нехватка оперативной памяти. Ошибка часто возникает, когда процесс сервера 1С (rphost) или служба SQL Server потребляют всю доступную оперативную память. Операционная система принудительно завершает процесс, что выглядит как разрыв соединения. Это особенно актуально для бесплатной редакции SQL Express, которая имеет жесткий лимит на использование ОЗУ ядром СУБД (около 1–1.4 ГБ).
2. Повреждение структур базы данных. Наличие «битых» страниц в таблицах (особенно в системных таблицах конфигурации). При попытке платформы прочитать эти данные, SQL Server сталкивается с ошибкой ввода-вывода и «роняет» сеанс.
3. Специфика протокола Shared Memory. Протокол «Общая память» используется по умолчанию, если сервер 1С и SQL Server установлены на одной машине. При высоких нагрузках или аппаратных проблемах он может работать менее стабильно, чем сетевые протоколы.

Шаг 1: Изменение протокола подключения

Посмотрим, как исключить проблемы с протоколом Shared Memory. В качестве первой меры рекомендуется принудительно перевести обмен данными на сетевой протокол.

1. Откройте «Диспетчер конфигурации SQL Server» (SQL Server Configuration Manager).
2. В разделе клиентских протоколов и протоколов сети SQL Server полностью отключите протокол «Общая память» (Shared Memory).
3. Оставьте включенным только протокол TCP/IP.
4. Выполните полную перезагрузку служб Агента сервера 1С и MS SQL Server.

Шаг 2: Увеличение размера сетевого пакета

Рассмотрим еще одну настройку СУБД, которая иногда помогает стабилизировать соединение при передаче больших объемов данных (например, тяжелых макетов). Попробуйте увеличить размер сетевого пакета (network packet size) в свойствах SQL Server до максимального значения, которое позволяет редакция (в обычных версиях это значение равно 32767).

Шаг 3: Проверка физической целостности базы данных

Если смена протокола не помогла, и в Конфигуратор по-прежнему не пускает, необходимо проверить базу на наличие логических и физических ошибок. Выполним проверку с помощью Management Studio.

Вы можете запустить следующий скрипт (заменив имя базы на свое):

ALTER DATABASE <Имя БД> SET EMERGENCY 
ALTER DATABASE <Имя БД> SET SINGLE_USER 
DBCC CHECKDB (<Имя БД>, REPAIR_ALLOW_DATA_LOSS) 
ALTER DATABASE <Имя БД> SET MULTI_USER

Если команда DBCC CHECKDB выдает ошибки вида «Ошибка таблицы... Тест (IS_OFF (BUF_IOERR, pBUF->bstat)) не прошел», это свидетельствует о серьезных повреждениях страниц данных.

Важно: При попытке выполнить проверку или реструктуризацию базы на версии SQL Express, СУБД может мгновенно упереться в лимит оперативной памяти и оборвать соединение. Для лечения поврежденных баз рекомендуется развернуть бэкап на полноценной редакции SQL Server (Standard/Enterprise/Developer).

Шаг 4: Локализация и удаление поврежденных данных

Если встроенные средства SQL не могут исправить ошибки, или починка невозможна из-за лимитов, разберем альтернативный вариант восстановления.

1. Настройте Технологический журнал 1С на сбор событий EXCP и DBMSSQL. Это поможет увидеть, на каком запросе к служебным таблицам (например, Config или Params) падает процесс.
2. Если выявить бинарные данные через ТЖ не удалось, можно попробовать выполнить запросы напрямую в SQL (например, SELECT * FROM dbo.Config), чтобы найти строку, на чтении которой возникает ошибка ввода-вывода.
3. В крайнем случае, неисправляемые (битые) таблицы придется удалить (drop) средствами SQL, если они не подлежат восстановлению.
4. После удаления битых структур, когда база позволит зайти в Конфигуратор, немедленно сделайте выгрузку в формат .dt.
5. Разверните полученный файл .dt в пустую файловую базу.

В файловой базе уже с помощью обработок и сравнения/объединения с эталонным cf-файлом (или конфигурацией поставщика) можно будет восстановить удаленные объекты и метаданные. Например, если были повреждены или удалены данные о лицензировании, их можно перенести из новой чистой базы аналогичной версии.