Развертывание информационных баз из файла выгрузки .dt объемом более 10 Гб часто превращается в настоящую проблему для администраторов 1С. Процесс может длиться десятки часов, сопровождаться «зависанием» Конфигуратора и аномальным ростом файлов базы данных и лога транзакций на SQL Server. В рамках этой статьи мы подробно разберем, почему это происходит, и проанализируем эффективные методы ускорения этого процесса.
Для начала выясним причину, по которой загрузка .dt занимает значительно больше времени, чем восстановление из обычного SQL-бэкапа (.bak). Файл .dt — это логический архив данных в формате 1С, а не физический слепок таблиц базы данных. При его загрузке платформа выполняет следующие шаги:
INSERT) во все таблицы.Именно этапы построения индексов и пересчета итогов являются наиболее ресурсоемкими. Именно в эти моменты Конфигуратор может выглядеть зависшим, хотя на стороне SQL Server идет активная работа.
Рассмотрим первоочередные настройки системы управления базами данных, которые позволят минимизировать накладные расходы. Одной из главных проблем является бесконтрольный рост файла лога транзакций (.ldf). Рассмотрим, как этого избежать.
Перевод базы в режим Simple. Перед началом загрузки крайне важно убедиться, что модель восстановления базы данных (Recovery Model) установлена в значение Simple. Это позволит SQL Server автоматически очищать лог транзакций после завершения операций, предотвращая его раздувание до сотен гигабайт.
Мгновенная инициализация файлов. Разберем по шагам важную настройку операционной системы, о которой часто забывают. SQL Server по умолчанию при создании или расширении файлов заполняет выделенное пространство нулями, что на больших объемах занимает много времени. Чтобы этого избежать, необходимо предоставить учетной записи, от которой запущена служба SQL Server, право на «Выполнение задач по обслуживанию томов» (Perform volume maintenance tasks) в локальной политике безопасности сервера.
Настройка автоприроста. Проанализируем настройки файлов .mdf и .ldf. Не устанавливайте маленький шаг прироста (например, 1 Мб или 5%). Для базы в 100 Гб оптимальным будет шаг в 512 Мб или даже 1024 Мб. Это уменьшит фрагментацию файлов на диске и снизит нагрузку на дисковую подсистему при выделении места.
Если загрузка все равно идет слишком медленно, рассмотрим дополнительные методы воздействия на структуру данных.
Предварительная загрузка в файловый вариант. Иногда имеет смысл сначала развернуть .dt в файловую базу. Рассмотрим этот сценарий подробнее:
.dt в файловую ИБ.1CD), можно попробовать изменить размер страницы данных, однако для баз объемом 10 Гб (в .dt) этот вариант может не подойти без использования 64-битной версии провайдера файловой базы.Отключение итогов. Если есть возможность программного доступа к конфигурации, перед выгрузкой в .dt можно рассмотреть вариант отключения итогов для всех регистров. После загрузки в новую базу итоги можно включить обратно, что инициирует их пересчет уже в рабочей базе, а не в процессе импорта данных.
Чтобы не гадать, завис ли Конфигуратор или процесс идет, проанализируем ситуацию через инструменты SQL Server. Мы не должны ориентироваться на статус окна 1С. Используйте Activity Monitor или выполните следующий запрос для просмотра активных процессов:
SELECT
session_id,
start_time,
status,
command,
estimated_completion_time,
cpu_time,
reads,
writes,
logical_reads
FROM sys.dm_exec_requests
WHERE session_id > 50
Если вы видите команды типа CREATE INDEX или ALTER TABLE, значит, система работает. Обратите внимание на показатели reads и writes — если они растут, значит, обмен данными с диском идет успешно.
При работе с большими объемами данных на виртуальных машинах важно учитывать производительность дисковой подсистемы. Рассмотрим параметр Delayed Durability (отложенная надежность), который появился в SQL Server 2014. Установка DELAYED_DURABILITY = FORCED позволяет существенно ускорить операции записи за счет того, что транзакции не дожидаются немедленной фиксации на диске. Это безопасно для процесса первоначальной загрузки базы, которую в случае сбоя можно просто начать заново.
Также не забывайте про TempDB. При создании индексов SQL Server активно использует временную базу. Убедитесь, что TempDB расположена на самом быстром доступном диске (NVMe/SSD) и имеет достаточно места для маневра, так как при загрузке 10-гигабайтного .dt временные файлы могут занимать десятки гигабайт.
Подведем итоги. Загрузка базы из .dt — это тяжелая транзакционная нагрузка. Чтобы процесс прошел успешно, придерживайтесь следующего алгоритма:
Помните, что база данных в SQL Server после развертывания из .dt всегда будет весить значительно больше исходного файла. Коэффициент сжатия в .dt очень высок, и 10 Гб выгрузки вполне могут превратиться в 150-200 Гб реальных данных в SQL-хранилище, учитывая индексы и служебные таблицы.