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

  • Статья

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

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

ADR появился в SQL Server 2019 (15.x) и улучшен в SQL Server 2022 (16.x). ADR также может использоваться для баз данных в Базе данных SQL Azure, Управляемом экземпляре SQL Azure и Azure Synapse SQL. ADR включен по умолчанию в База данных SQL и Управляемый экземпляр SQL и не может быть отключен. Дополнительные сведения об ADR в Azure SQL см. в статье об Ускоренном восстановлении баз данных в Azure SQL.

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

Обзор

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

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

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

  • Мгновенный откат транзакции

    При использовании ADR откат транзакций совершается мгновенно независимо от времени активности транзакции или количества выполненных обновлений.

  • Агрессивное усечение журнала

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

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

Если ADR не применяется, восстановление базы данных в SQL Server производится согласно модели восстановления ARIES в три этапа, которые показаны на приведенной ниже схеме и более подробно описаны далее.

Схема текущего процесса восстановления.

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

    SQL Server выполняет прямой просмотр журнала транзакций от начала последней успешной контрольной точки (или номера LSN самой старой "грязной" страницы) до конца, чтобы определить состояние каждой транзакции на момент остановки SQL Server.

  • Стадия повтора

    SQL Server выполняет прямой просмотр журнала транзакций от самой старой незафиксированной транзакции до конца, чтобы перевести базу данных в состояние, которое она имела в момент сбоя, путем повторного выполнения всех зафиксированных операций.

  • Стадия отката

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

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

Кроме того, отмена или откат большой транзакции на основе этой структуры также может занять много времени, так как он использует тот же этап восстановления отмены, как описано ранее.

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

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

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

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

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

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

Схема процесса восстановления ADR.

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

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

  • Стадия повтора

    Разбитые на две подфаксы

    • Подфазы 1

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

    • Промежуточный этап 2

      Повтор из журнала транзакций начинается с последней контрольной точки (а не с самой старой незафиксированной транзакции).

  • Стадия отката

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

Вы также можете просмотреть следующее восьмиминутное видео, в котором объясняется работа Ускоренного восстановления баз данных:

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

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

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

    Постоянное хранилище версий — это механизм ядра СУБД для сохранения создаваемых версий строк в самой базе данных, а не в традиционном хранилище версий tempdb. PVS обеспечивает изоляцию ресурсов и повышает доступность вторичных реплик для чтения. В SQL Server 2019 (15.x) существует один поток PVS на экземпляр. Начиная с SQL Server 2022 (16.x), SQL Server имеет один чистый поток PVS для каждой базы данных.

  • Логическая отмена изменений

    Логическая отмена изменений — это асинхронный процесс, цель которого — откат на основе версий на уровне строк. Он обеспечивает мгновенный откат транзакций и отмену операций с управлением версиями.

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

  • SLOG

    SLOG — это вторичный поток журнала в памяти, в котором хранятся записи журнала для неверсионных операций (например, недопустимое кэширование метаданных, приобретение блокировки и т. д.). SLOG имеет следующие особенности:

    • малый объем и размещение в памяти;
    • сохраняется на диске путем сериализации во время обработки контрольных точек;
    • периодическое усекается при фиксации транзакций;
    • Ускоряет повторное выполнение и отмену, обрабатывая только неверсионные операции
    • обеспечивает агрессивное усечение журнала транзакций за счет сохранения только необходимых записей журнала.

  • Очистка

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

Улучшения ADR в SQL Server 2022 (16.x)

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

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

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

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

  • Уменьшение объема памяти для средства отслеживания страниц PVS

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

  • Улучшения средства очистки ускоренного восстановления данных (ADR)

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

  • Постоянное хранилище версий (PVS) на уровне транзакций

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

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

  • Очистка многопоточных версий

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

    Начиная с SQL Server 2022 (16.x), этот процесс использует очистку многопоточных версий. Это позволяет параллельно очищать несколько баз данных в одном экземпляре SQL Server. Это улучшение полезно при наличии нескольких больших баз данных.

    Чтобы настроить количество потоков для масштабируемости очистки версии, задайте ADR Cleaner Thread Count для sp_configureпараметра . Число потоков ограничено числом ядер для экземпляра.

    Рекомендуется использовать то же количество более чистых потоков ADR, что и количество баз данных. Например, если вы настроите ADR Cleaner Thread Count экземпляр 4 SQL Server с двумя базами данных, средство ADR по-прежнему будет выделять только один поток на базу данных, оставляя оставшиеся два потока бездействия.

    В приведенном ниже примере количество потоков изменяется на 4:

    EXEC sp_configure 'ADR Cleaner Thread Count', '4';
RECONFIGURE WITH OVERRIDE;

  • Новое расширенное событие

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

рекомендации и руководства;

Рекомендации по рабочим нагрузкам, которые не рекомендуется для ADR, см. в статье "Управление ускорением восстановления базы данных".

Внимание

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

Связанный контент