Ускоренное восстановление баз данных

Статья
2025-05-01

Область применения:SQL Server 2019 (15.x) и более поздние версии База данных SQL Azure Управляемый экземпляр SQL Azure базе данных SQL в Microsoft Fabric

Ускорение восстановления базы данных (ADR) повышает доступность базы данных, особенно в присутствии длительных транзакций, перепроектируя процесс восстановления ядра СУБД.

ADR появился в SQL Server 2019 (15.x) и улучшен в SQL Server 2022 (16.x) и ПРЕДВАРИТЕЛЬНОй версии SQL Server 2025 (17.x). ADR также доступен в Базе данных SQL Azure, Управляемом экземпляре SQL Azure, Azure Synapse Analytics (только для выделенного пула SQL) и базе данных SQL в Microsoft Fabric.

Заметка

ADR всегда включается в Базе данных SQL Azure, Управляемом экземпляре SQL Azure и базе данных SQL в Fabric.

В этой статье представлен обзор ADR. Чтобы работать с ADR, ознакомьтесь со статьей "Управление ускорением восстановления базы данных".

Дополнительные сведения о журнале транзакций и восстановлении базы данных см. в руководстве по архитектуре и управлению журналом транзакций SQL Server и обзоре восстановления и восстановления данных (SQL Server).

Обзор

Основные преимущества ADR

Быстрое и согласованное восстановление баз данных

Длительные транзакции не влияют на общее время восстановления, обеспечивая быстрое и согласованное восстановление базы данных независимо от количества активных транзакций в системе или их размера.
Мгновенный откат транзакции

Откат транзакции является мгновенным, независимо от времени, когда транзакция была активна или количество обновлений, которые были сделаны.
Агрессивное усечение журнала

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

Традиционный процесс восстановления базы данных

Без ADR восстановление базы данных следует модели восстановления ARIES и состоит из трех этапов, которые иллюстрируются и подробно описаны на следующей схеме:

Стадия анализа

Ядро СУБД выполняет сканирование журнала транзакций вперед с начала последней успешной контрольной точки (или старейшего номера последовательности журнала грязной страницы (LSN)), до конца, чтобы определить состояние каждой транзакции в момент остановки ядра.
Стадия повтора

Ядро СУБД выполняет линейное сканирование журнала транзакций от самой старой незафиксированной транзакции до конца. Этот процесс восстанавливает все зафиксированные операции, чтобы вернуть базу данных в её состояние на момент сбоя.
Стадия отката

Для каждой транзакции, активной во время сбоя, ядро СУБД проходит по журналу назад, отменяя операции, выполняемые этой транзакцией.
При использовании традиционного процесса восстановления базы данных восстановление после сбоя может занять много времени, если долговременная транзакция была активной.

Время восстановления ядра СУБД после неожиданного перезапуска (примерно) пропорционально размеру самой длинной активной транзакции в системе во время сбоя. Для восстановления требуется откат всех незавершенных транзакций. Необходимое время пропорционально объему работы, выполненному транзакцией, и времени ее активности.
Отмена или откат большой транзакции может занять много времени, так как она использует тот же этап восстановления отмены, как описано ранее.
Ядро СУБД не может усечь журнал транзакций, если существуют длительные транзакции, так как соответствующие записи журнала необходимы для процессов восстановления и отката. В результате журнал транзакций может увеличиваться очень большой и потреблять много места в хранилище.

Процесс ускоренного восстановления базы данных

ADR устраняет предыдущие проблемы с традиционной моделью восстановления путем полностью перепроектирования процесса восстановления ядра СУБД следующим:

Сделайте время восстановления постоянным, поскольку больше нет необходимости сканировать журнал транзакций с начала самой старой активной транзакции. При использовании ADR журнал транзакций обрабатывается только из последней успешной контрольной точки (или самой старой грязной страницы LSN). В результате длительные транзакции не влияют на время восстановления, и оно обычно происходит мгновенно.
Свести к минимуму требуемое пространство журнала транзакций, так как для всей транзакции больше не требуется хранить журнал. В результате журнал транзакций может агрессивно усекаться при наличии контрольных точек и резервных копий.

На концептуальном уровне ADR обеспечивает быстрое восстановление базы данных путем версионирования всех физических изменений базы данных и только отмены тех операций, которые не являются версионными, поскольку этих операций немного и они могут быть отменены почти мгновенно. Все транзакции, которые были активны во время сбоя, помечаются как прерванные. Поэтому все версии, созданные этими транзакциями, могут игнорироваться параллельными пользовательскими запросами.

Процесс восстановления ADR имеет те же три этапа, что и традиционный процесс восстановления. Как эти этапы работают с ADR, показано на следующей схеме:

Стадия анализа

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

Разбитые на две подфаксы
- Подфазы 1
  
  Повтор из SLOG (самая старая незафиксированная транзакция до последней контрольной точки). Повтор — это быстрая операция, так как может потребоваться обрабатывать только несколько записей из SLOG.
- Подфаза 2
  
  Восстановление из журнала транзакций начинается с последней успешной контрольной точки (вместо самой старой незавершённой транзакции).
Стадия отката

Этап отмены с ADR завершается почти мгновенно, используя SLOG для отмены неверсионных операций и сохраняемое хранилище версий (PVS) с помощью логического возврата, чтобы выполнить отмену на основе версий на уровне строк.

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

Компоненты восстановления ADR

Ниже приведены четыре основных компонента ADR.

хранилище постоянных версий (PVS)

Постоянное хранилище версий (PVS) — это механизм ядра СУБД для сохранения версий строк в самой базе данных вместо традиционного хранилища версий в базе данных tempdb. PVS обеспечивает изоляцию ресурсов и повышает доступность вторичных реплик для чтения.

PVS хранит версии строк непосредственно на измененных страницах данных или в отдельной системной таблице. Дополнительные сведения см. в разделе Пробел, используемыйхранилища постоянных версий (PVS).
логический возврат

Логическая отмена изменений — это асинхронный процесс, цель которого — откат на основе версий на уровне строк. Он обеспечивает мгновенный откат транзакций и отмену операций с управлением версиями.
- Отслеживание всех аварийно завершенных транзакций
- Выполнение отката с помощью PVS для всех пользовательских транзакций
- Снятие всех блокировок сразу после аварийного завершения транзакции
Сильный удар

SLOG — это вторичный поток журнала в памяти, в котором хранятся записи журнала для неверсионных операций (например, недопустимое кэширование метаданных, приобретение блокировки и т. д.). SLOG имеет следующие особенности:
- малый объем и размещение в памяти;
- Сохраняется на диске во время процесса контрольной точки
- периодическое усекается при фиксации транзакций;
- Ускорение повторного выполнения и отмены путем обработки только неверсионных операций
- обеспечивает агрессивное усечение журнала транзакций за счет сохранения только необходимых записей журнала.
Очистка

Более чистый — это асинхронный процесс, который периодически просыпается и очищает устаревшие версии строк из PVS.

Рабочие нагрузки, которые получают преимущества от ADR

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

Длительные транзакции.
Активные транзакции, которые приводят к значительному росту журнала транзакций.
Длительные периоды недоступности базы данных из-за длительного восстановления (например, из непредвиденного перезапуска службы или отката транзакций вручную).

ADR не поддерживается в базах данных, использующих зеркальное отображение базы данных, старую и снятую с эксплуатации функцию высокой доступности.

Улучшения ADR в SQL Server 2025

ADR в tempdb

Начиная с предварительной версии SQL Server 2025 (17.x), В базе данных tempdb можно включить ADR.

Без ADR и даже при минимальном ведении журнала, транзакции, включающие такие объекты, как временные таблицы, табличные переменные или невременные таблицы, созданные в tempdb, могут быть затронуты длительным откатом и высоким использованием журнала транзакций. Недостаток пространства tempdb журнала транзакций может привести к значительным сбоям и остановке приложения.

Предварительная версия SQL Server 2025 (17.x) делает откат мгновенных транзакций и преимущества агрессивной обрезки журнала доступными для рабочих нагрузок с использованием транзакций в tempdb.

Чтобы включить ADR в tempdb, см. Включение ADR.

Улучшения ADR в SQL Server 2022

Существует несколько улучшений для решения постоянного хранилища версий (PVS) и общей масштабируемости. Дополнительные сведения о новых возможностях SQL Server 2022 (16.x) см. в разделе "Что нового в SQL Server 2022".

Те же улучшения также доступны в Базе данных SQL Azure, Управляемом экземпляре SQL Azure, Azure Synapse Analytics (только для выделенного пула SQL) и базе данных SQL в Microsoft Fabric.

Очистка транзакций пользователя

Очистите страницы, которые не могут быть очищены обычным процессом в случае неудачной попытки получения блокировки.

Эта функция позволяет транзакциям пользователей выполнять очистку на страницах, которые не могут быть устранены обычным процессом очистки из-за конфликтов блокировки на уровне таблицы. Это улучшение помогает гарантировать, что процесс очистки ADR не завершается неограниченное время, так как рабочие нагрузки пользователей не могут получать блокировки на уровне таблицы.
сократить объем памяти для отслеживания страниц PVS

Это улучшение отслеживает страницы PVS на уровне экстентов, чтобы сократить объем памяти, необходимый для поддержки версий страниц.
более чистые улучшения PVS

Средство очистки версий PVS улучшило эффективность очистки версий, чтобы повысить эффективность отслеживания и записи версий строк ядра СУБД для прерванных транзакций. Это приводит к улучшению использования памяти и хранилища.
Сервис постоянных версий на уровне транзакций (PVS)

Это улучшение позволяет ADR очищать версии, принадлежащие к зафиксированным транзакциям независимо от того, существуют ли прерванные транзакции в системе. Благодаря этому улучшению страницы PVS могут быть освобождены, даже если процесс очистки не может завершить успешный проход для сокращения карты прерванных транзакций.

Результатом этого улучшения является снижение роста PVS, даже если очистка PVS замедляется или завершается сбоем.
Очистка многопоточных версий

В SQL Server 2019 (15.x) процесс очистки состоит из одного потока в экземпляре ядра СУБД.

Начиная с SQL Server 2022 (16.x), поддерживается очистка многопоточных версий. Это позволяет параллельно очищать несколько баз данных в одном экземпляре ядра СУБД или очищать одну базу данных быстрее. Дополнительные сведения см. в разделе Конфигурация сервера: количество потоков очистки ADR.

Добавлено новое расширенное событие tx_mtvc2_sweep_statsдля мониторинга многопоточного чистильщика версий в ADR PVS.

Поделиться через