Перевод информационной базы из файлового варианта работы в клиент-серверный — стандартная задача при росте объемов данных и количества пользователей. Классический сценарий кажется предельно простым: создаем выгрузку в файл .dt через Конфигуратор файловой базы, создаем пустую базу на сервере 1С:Предприятия с подключением к СУБД MS SQL Server и выполняем загрузку данных. Однако на этапе восстановления данных процесс нередко прерывается критической системной ошибкой: «Microsoft SQL Server Native Client 11.0: Ошибка выделения памяти HRESULT=80004005».
Разберем детально, почему возникает данный сбой, какие архитектурные ограничения платформы и драйверов СУБД к нему приводят, а также рассмотрим проверенные способы переноса данных в SQL без риска повреждения структуры метаданных.
Причины сбоя: фрагментация памяти и порог в 120 МБ
Выясним техническую причину такого поведения системы. Ошибка HRESULT=80004005 в модуле Microsoft SQL Server Native Client сигнализирует о том, что процессу не удалось выделить блок оперативной памяти под передаваемый буфер данных. Это происходит по следующим причинам:
Ограничение адресного пространства 32-битных процессов: При использовании 32-разрядного сервера 1С или толстого клиента Конфигуратора адресному пространству процесса доступно не более 2 ГБ виртуальной памяти (в редких случаях до 3–4 ГБ при специальных флагах заголовка).
Требование непрерывности блока памяти: Драйвер Native Client при загрузке бинарных данных (LOB/BLOB) из потока .dt в таблицы базы данных требует выделения единого непрерывного фрагмента виртуальной памяти под весь передаваемый объект.
Фрагментация виртуальной памяти: По мере работы Конфигуратора память дробится на небольшие сегменты. Когда драйвер встречает крупный неделимый объект (превышающий 120–128 МБ), операционная система не может найти свободный сплошной кусок нужной длины, хотя суммарно свободной RAM на сервере может быть десятки гигабайт.
Перегруженная таблица Config: В подавляющем большинстве случаев «тяжелым» объектом выступает конфигурация поставщика (или несколько таких конфигураций при накоплении истории обновлений в типовых конфигурациях вроде «Управление торговлей», ERP или «Комплексная автоматизация»). Также проблема может встречаться в таблицах документов или справочников, где в реквизитах типа ХранилищеЗначения сохранены тяжелые бинарные файлы или сканы.
Способ 1. Штатное снятие конфигурации с поддержки перед выгрузкой
Проанализируем самый надежный и безопасный вариант, который не требует использования сторонних низкоуровневых редакторов таблиц и не нарушает целостность данных.
Поскольку основную долю таблицы Config занимает именно конфигурация поставщика, временно исключим ее из файловой базы перед формированием архива:
Откроем файловую информационную базу в режиме Конфигуратор.
Перейдем в главное меню: Конфигурация → Поддержка → Настройка поддержки.
В открывшемся окне нажмем кнопку Включить возможность изменения (если она еще не включена), подтвердим действие, а затем нажмем Снять с поддержки.
Сохраним конфигурацию базы данных (клавиша F7). На этом шаге платформа удалит тяжелые бинарные слепки конфигурации поставщика, и размер таблицы метаданных кардинально сократится.
В консоли администрирования кластера 1С создадим пустую информационную базу на сервере MS SQL Server.
Запустим Конфигуратор созданной базы на SQL и выполним загрузку полученного .dt через Администрирование → Загрузить информационную базу. Загрузка пройдет штатно, так как объекты свыше 120 МБ в потоке отсутствуют.
Теперь восстановим конфигурацию поставщика в рабочей базе на SQL, чтобы не потерять возможность автоматического обновления типовых релизов:
В Конфигураторе базы на SQL откроем меню Конфигурация → Сравнить, объединить с конфигурацией из файла.
Выберем файл эталонной конфигурации .cf того же самого релиза, который установлен в базе.
На вопрос о постановке на поддержку ответим утвердительно.
В появившемся окне сравнения и объединения снимем все флажки со всех объектов дерева метаданных (чтобы структура данных осталась неизменной), оставив активным только режим обновления правил поддержки.
Нажмем кнопку Выполнить и обновим конфигурацию базы данных клавишей F7. База снова стоит на поддержке и успешно работает на сервере MS SQL.
Способ 2. Очистка структуры и логическая проверка
Если конфигурация сильно изменена или уже снята с поддержки, но ошибка все равно возникает, это может свидетельствовать о накоплении внутренних потерянных объектов в таблице метаданных. Разберем шаги очистки базы перед созданием файла выгрузки:
В Конфигураторе файловой базы выполним Конфигурация → Проверка конфигурации. Обязательно установим флаг Проверка логической целостности конфигурации. Это удалит битые внутренние ссылки.
Если база типовая, рекомендуется сохранить конфигурацию в файл .cf (меню Конфигурация → Сохранить конфигурацию в файл), после чего выполнить Конфигурация → Загрузить конфигурацию из файла (именно полную загрузку, а не объединение). Это пересоберет таблицы метаданных без фрагментов старых промежуточных сохранений.
Запустим полное тестирование и исправление через Администрирование → Тестирование и исправление со всеми установленными флагами, включая сжатие таблиц и реиндексацию.
Способ 3. Перенос данных в обход файла выгрузки (механизм РИБ)
Формат .dt изначально проектировался разработчиками платформы для переноса небольших баз данных и демонстрационных конфигураций. При объемах базы в десятки гигабайт правильнее использовать механизмы, не зависящие от монолитного буфера выгрузки.
Рассмотрим перенос данных через создание начального образа распределенной информационной базы (РИБ):
В файловой базе создадим новый план обмена или используем любой существующий полный план обмена (например, Полный).
Добавим узел обмена для новой базы.
Выполним создание начального образа узла, указав в качестве приемника параметры клиент-серверной базы на MS SQL Server. В этом случае данные будут записываться сервером напрямую порциями через транзакции СУБД, минуя узкое горлышко драйвера Native Client при распаковке .dt.
После успешного создания базы на SQL запустим ее в режиме «1С:Предприятие» и программно отключим признак подчиненного узла РИБ, чтобы сделать базу полностью автономной. Для этого воспользуемся внешней обработкой со следующим кодом:
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
Сообщить("База успешно отвязана от главного узла и переведена в автономный режим.");
Способ 4. Корректировка параметров сервера и MS SQL Server
Если физический сервер совмещает роли сервера приложений 1С и сервера СУБД MS SQL, причиной ошибки может стать банальный захват всей доступной физической памяти процессом СУБД.
Посмотрим на настройки памяти самого SQL-сервера:
Откроем SQL Server Management Studio (SSMS).
Нажмем правой кнопкой мыши на корневой узел сервера и перейдем в Properties (Свойства) → вкладка Memory (Память).
По умолчанию параметр Maximum server memory выставлен в максимальное теоретическое значение (более 2 ПБ). Зададим жесткий лимит, оставив операционной системе и процессам сервера 1С как минимум 4–8 ГБ свободной памяти.
Если используется устаревшая 32-разрядная операционная система Windows Server, расширим лимит пользовательского адресного пространства, выполнив в командной строке от имени администратора команду bcdedit /set IncreaseUserVa 3072, после чего перезагрузим сервер.
В актуальных версиях платформы 1С:Предприятие 8.3 рекомендуется использовать 64-разрядный сервер приложений (x86-64) и современный драйвер Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL) вместо устаревшего Native Client 11.0, так как в нем устранены проблемы фрагментации буфера LOB-объектов.