Загрузка информационной базы из файла выгрузки .dt в среду SQL — это одна из наиболее ресурсоемких операций в администрировании 1С. Часто системные администраторы сталкиваются с ситуацией, когда файл небольшого объема (например, 650 МБ) загружается около часа, что кажется аномальным по сравнению с обычным копированием файлов. В этой статье мы подробно разберем, что происходит «под капотом» во время этой процедуры, выясним причины задержек и определим оптимальные настройки для ускорения процесса.
Для начала проанализируем саму суть формата .dt. Важно понимать, что это не просто архив с данными, а платформенно-независимый формат. Когда мы инициируем загрузку, платформа 1С выполняет колоссальный объем работы: последовательно создает структуру таблиц в SQL-базе, конвертирует данные из внутреннего представления в типы данных СУБД и, что самое долгое, заново выстраивает все индексы. Рассмотрим основные факторы, которые превращают этот процесс в «узкое место».
Одной из главных причин замедления, упомянутых в практике, является использование 32-битного клиента 1С. Проанализируем ситуацию: 32-битный процесс ограничен адресным пространством в 2-3 ГБ оперативной памяти. При распаковке крупных таблиц (особенно регистров расчета в конфигурациях типа ЗБУ или ЗУП) память быстро заполняется.
Когда памяти не хватает, система начинает активно использовать файл подкачки на диске. Это приводит к так называемому «трэшингу» (thrashing), когда процессор тратит больше времени на перемещение данных между памятью и диском, чем на саму обработку. Рекомендуем всегда использовать 64-битный клиент 1С (Конфигуратор) для выполнения операций загрузки, так как он может задействовать весь объем доступной оперативной памяти сервера.
Если мы работаем с SQL-версией базы, то значительная часть задержек связана с настройками самой СУБД. Разберем по шагам, что нужно изменить перед началом загрузки:
Full (Полная). В этом режиме SQL Server записывает каждое изменение данных в лог транзакций (.ldf). При загрузке .dt происходит массовая вставка записей, что заставляет файл лога мгновенно разрастаться, создавая огромную нагрузку на дисковую подсистему. Установим модель восстановления Simple (Простая) перед загрузкой. Это отключит избыточное логирование и существенно ускорит запись..mdf и .ldf. Если шаг расширения установлен в 1 МБ или в процентах, SQL Server будет постоянно прерывать процесс записи, чтобы запросить у операционной системы новое место на диске. Установим фиксированный размер приращения, например, 512 МБ или 1024 МБ, чтобы минимизировать количество операций выделения места.Shared Memory. Использование TCP/IP в рамках одного сервера добавляет лишние накладные расходы на сетевой стек.Проанализируем работу с временными данными. Процесс загрузки активно использует базу TempDB для сортировки данных при создании индексов. Если TempDB расположена на медленном HDD, это станет критическим фактором замедления. Перенесем TempDB на максимально быстрые диски (NVMe SSD). Кроме того, стоит добавить рабочие каталоги сервера 1С и файлы базы данных в исключения антивируса, так как постоянная проверка создаваемых временных файлов может замедлять процесс в разы.
В случае с ЗБУ 3.1 (Зарплата и бюджетное учреждение) мы имеем дело с очень сложной структурой регистров. При загрузке из .dt платформа не просто копирует записи, но и проверяет их ссылочную целостность. Рассмотрим возможность временного отключения итогов перед загрузкой, если это позволяет сценарий работы, хотя для полной загрузки из .dt это применимо редко. Главное здесь — понимать, что объем .dt в 650 МБ может развернуться в SQL-базу объемом 5-10 ГБ из-за индексов и служебных таблиц.
Выясним, действительно ли нам необходим формат .dt. Специалисты 1С и администраторы баз данных единогласны: формат .dt предназначен в первую очередь для миграции между разными типами СУБД (например, из файловой в SQL) или для обновления версии платформы.
Если задача состоит в создании копии базы для тестов или переносе данных между одинаковыми SQL-серверами, рассмотрим использование родных средств резервного копирования SQL (файлы .bak).
Почему это быстрее?
.bak — это побайтовое копирование страниц данных в файлы базы..bak за 7–10 минут, в то время как загрузка аналогичного .dt может занять сутки или закончиться ошибкой.Подводя итог нашему анализу, можно сказать, что время загрузки в 45-60 минут для файла 650 МБ является завышенным, но объяснимым при стандартных настройках. Чтобы сократить это время до 10-15 минут, выполним следующие действия: используем 64-битный клиент, переведем SQL в режим Simple Recovery, обеспечим высокую скорость дисков для TempDB и, по возможности, перейдем на использование .bak файлов вместо .dt.