Почему восстановление базы 1С из бэкапа SQL Server идет слишком долго и зависает на 100%?

При обслуживании и переносе крупных информационных баз 1С:Предприятия системные администраторы часто сталкиваются с ситуацией, когда процесс восстановления (RESTORE DATABASE) выполняется значительно дольше ожидаемого времени или надолго замирает на отметке 100% с типами ожиданий IO_COMPLETION или SLEEP_BPOOL_FLUSH. Разберем по шагам, какие процессы происходят в СУБД в этот момент, почему процесс кажется зависшим и как существенно ускорить развертывание резервных копий.

Выясняем причины зависания на 100% и долгого восстановления

Когда счетчик прогресса восстановления доходит до 100%, фактическая работа СУБД еще не завершена. Проанализируем ключевые факторы, влияющие на общую продолжительность процедуры:

1. Фаза отката транзакций (Recovery Phase — REDO/UNDO). Индикатор выполнения STATS отображает только вычитку и запись страниц данных из файла архива на диск. После достижения 100% СУБД приступает к приведению базы к согласованному состоянию: накатывает зафиксированные транзакции (REDO) и откатывает незавершенные (UNDO), зафиксированные в резервной копии. Если в момент снятия бэкапа в 1С выполнялись масштабные регламентные задания, перерасчет итогов или проведение документов, эта фаза может длиться несколько часов.
2. Инициализация файлов нулями (Zero-Initialization). По умолчанию перед записью файлов .mdf и .ndf операционная система полностью перезаписывает выделяемое дисковое пространство нулями. Для баз объемом сотни гигабайт на медленных дисках (например, со скоростью вращения шпинделя 5400 RPM) этот процесс занимает огромное количество времени еще до старта распаковки.
3. Раздутый журнал транзакций и фрагментация VLF. Мгновенная инициализация файлов никогда не применяется к журналу транзакций .ldf — он зануляется принудительно. Если исходный лог-файл имел размер в сотни гигабайт или содержал десятки тысяч виртуальных лог-файлов (VLF), фаза восстановления кратно замедляется.
4. Ограничения дисковой подсистемы. Ожидания IO_COMPLETION сигнализируют о том, что поток СУБД заблокирован в ожидании окончания дискового ввода-вывода, а SLEEP_BPOOL_FLUSH указывает на задержки при сбросе измененных страниц из оперативной памяти на диск из-за высокой дисковой очереди.

Способ 1. Включение мгновенной инициализации файлов (Instant File Initialization)

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

1. Откроем оснастку локальных политик безопасности Windows (сочетание клавиш Win + R, затем команда secpol.msc).
2. Перейдем в раздел: Локальные политики (Local Policies) → Назначение прав пользователя (User Rights Assignment).
3. Найдем политику «Выполнение задач по обслуживанию томов» (Perform volume maintenance tasks).
4. Добавим в список учетную запись, от имени которой запущена служба SQL Server.
5. Перезапустим службу MSSQLSERVER для применения изменений.

Способ 2. Оптимизация параметров команды восстановления в SQL Server

Для ускорения чтения и записи архива разберем использование параметров тонкой настройки буферизации ввода-вывода в запросе T-SQL:

RESTORE DATABASE [MyBase1C]
FROM DISK = N'D:\Backup\MyBase1C_Full.bak'
WITH 
    MOVE N'MyBase1C_Data' TO N'E:\SQLData\MyBase1C.mdf',
    MOVE N'MyBase1C_Log' TO N'L:\SQLLog\MyBase1C_log.ldf',
    STATS = 5,
    BUFFERCOUNT = 200,
    MAXTRANSFERSIZE = 4194304,
    RECOVERY;

Проанализируем используемые параметры:

1. BUFFERCOUNT — задает количество буферов ввода-вывода (рекомендуется устанавливать от 50 до 300 в зависимости от доступного объема RAM).
2. MAXTRANSFERSIZE — размер блока передачи данных в байтах (значение 4194304 соответствует 4 МБ, что значительно снижает дисковую очередь по сравнению со стандартными значениями).

Способ 3. Мониторинг реального состояния восстановления

Чтобы убедиться, что восстановление базы данных не зависло, а выполняет внутренние транзакционные операции, выполним запрос к системным динамическим представлениям:

SELECT 
    r.session_id,
    r.command,
    r.percent_complete,
    r.estimated_completion_time / 1000 / 60 AS Estimated_Minutes_Left,
    r.wait_type,
    r.wait_time,
    r.last_wait_type
FROM sys.dm_exec_requests r
WHERE r.command IN ('RESTORE DATABASE', 'RESTORE LOG', 'DbMgrPartnerRestore');

Если поле percent_complete показывает 100%, но команда еще активна, в журнале ошибок SQL Server Error Log фиксируется ход выполнения фаз REDO и UNDO с отметками о проценте завершения.

Способ 4. Оптимизация объема базы на стороне 1С:Предприятия

Если база данных достигает больших объемов (от сотен гигабайт до нескольких терабайт), длительность резервного копирования и восстановления можно существенно сократить за счет аудита и очистки данных внутри 1С:

1. Вынос присоединенных файлов во внешние тома. Хранение сканов, PDF-документов и картинок непосредственно в таблицах базы данных (в объектах ХранилищеЗначений) сильно раздувает файл .mdf. Настроим хранение файлов на отдельных сетевых или локальных дисковых томах через стандартные механизмы 1С.
2. Очистка истории версионирования. Проверим регламентные задания по устаревшим версиям объектов. Накопленные версии в регистре сведений ВерсииОбъектов часто занимают до трети общего объема базы данных.
3. Сжатие и очистка журнала регистрации. Если журнал регистрации хранится в формате базы данных, настроим его периодическую архивацию и сокращение через стандартные средства администрирования 1С.
4. Контроль таблиц регистрации изменений. Удалим неиспользуемые узлы планов обмена, которые могут удерживать огромные объемы избыточных записей в таблицах регистрации изменений.