Как исправить ошибку разрыва соединения 10054 при обновлении 1С:Бухгалтерии с редакции 2.0 на 3.0?

Переход с конфигурации «Бухгалтерия предприятия 2.0» на редакцию 3.0 в клиент-серверном варианте на базе MS SQL Server нередко сопровождается аварийным завершением работы конфигуратора. Особенно часто сбой происходит на этапе реструктуризации многомиллионных таблиц, таких как РегистрБухгалтерии.Хозрасчетный, с возникновением сетевой ошибки 10054 (Удаленный хост принудительно разорвал существующее подключение).

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

Причины возникновения ошибки 10054 при реструктуризации

Рассмотрим ключевые факторы, приводящие к принудительному разрыву соединения со стороны сервера 1С или СУБД:

1. Аварийный перезапуск рабочего процесса rphost по лимитам памяти. Если в свойствах кластера серверов 1С заданы ограничения на допустимый объем памяти рабочих процессов, кластер принудительно «убивает» процесс, вышедший за пределы лимита при обработке гигантских объемов движений. Клиент 1С в этот момент мгновенно теряет связь и возвращает ошибку 10054.
2. Переполнение или фрагментация журнала транзакций MS SQL (файл .ldf). Операция реструктуризации регистра с миллионами записей генерирует колоссальный объем транзакционных данных. Если база находится в полной модели восстановления (Full), лог стремительно разрастается, что может приводить к исчерпанию дискового пространства или таймаутам на авторасширение.
3. Перегрузка системной базы tempdb. Создание временных индексов и перенос промежуточных данных создают критическую нагрузку на tempdb. При нехватке места операция прерывается.
4. Сетевые таймауты между клиентом и сервером. При длительном выполнении блокирующей операции на стороне СУБД клиент не передает пакетов, из-за чего промежуточное сетевое оборудование или настройки операционной системы закрывают TCP-сессию как неактивную.

Способ 1. Корректировка параметров кластера 1С и MS SQL Server

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

1. Отключим лимиты памяти в кластере 1С. В консоли администрирования серверов 1С:Предприятия откроем свойства кластера (и рабочего сервера) и временно установим параметры «Допустимый объем памяти» и «Интервал превышения допустимого объема памяти» равными 0. Это предотвратит перезапуск rphost во время долгой реструктуризации.
2. Переведем модель восстановления базы в Simple. В среде MS SQL Server Management Studio откроем свойства базы данных, перейдем в раздел Options и переключим Recovery model в режим Simple. Это снизит нагрузку на журнал транзакций.
3. Выполним предварительное расширение файлов. Заранее выделим свободное место для файлов базы данных (.mdf) и журнала (.ldf), а также для системной базы tempdb, чтобы исключить задержки на динамическое расширение (Autogrowth).
4. Обновим статистики и индексы. Выполним регламентные процедуры дефрагментации и обновления статистик перед накатыванием обновления.

Способ 2. Запуск реструктуризации локально или в фоновом режиме

Для исключения влияния сетевых задержек и разрывов связи конфигуратора выполним обновление локально на самом сервере приложений:

1. Подключимся через RDP непосредственно к серверу, где развернута служба 1С.
2. Запустим обновление конфигурации базы данных через командную строку в пакетном режиме, используя параметр фонового обновления:

"C:\Program Files\1cv8\8.3.9.2170\bin\1cv8.exe" DESIGNER /S "localhost\buh_base" /UpdateDBCfg -Server /UC КодРазрешения

Запуск реструктуризации на стороне сервера предотвращает падение сессии из-за зависания графического интерфейса тонкого или толстого клиента.

Способ 3. Переход через промежуточную файловую базу (для баз малого и среднего объема)

Проанализируем вариант, применимый для баз объемом до 10–15 Гб:

1. Выгрузим информационную базу в файл .dt.
2. Создадим пустую файловую базу. Чтобы избежать ошибки превышения максимально допустимого размера внутреннего файла таблицы (1Cv8.1CD), изменим размер страницы базы данных с помощью технологической утилиты cnvdbfl.exe (расположена в каталоге bin платформы). Установим размер страницы 64k:

cnvdbfl.exe -c -s 64k "D:\bases\new_buh\1Cv8.1CD"

3. Загрузим выгрузку .dt в подготовленную файловую базу и выполним обновление конфигурации до релиза 3.0 в файловом режиме.
4. После успешного обновления выгрузим базу обратно в .dt и восстановим ее на MS SQL Server.

Способ 4. Перенос данных в чистую базу (рекомендуемый для тяжелых баз)

Если объем регистра РегистрБухгалтерии.Хозрасчетный превышает десятки миллионов записей, штатная реструктуризация таблицы может потребовать чрезмерных ресурсов. В таких случаях оптимально применить типовой перенос данных:

1. Развернем чистую типовую конфигурацию «Бухгалтерия предприятия 3.0» актуального релиза.
2. Воспользуемся встроенным «Помощником перехода с 1С:Бухгалтерии 8 ред. 2.0 на ред. 3.0».
3. Перенесем остатки на начало текущего или прошлого года, нормативно-справочную информацию и документы за открытый период.

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