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

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

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

ADR появился в SQL Server 2019 (15.x) и улучшен в SQL Server 2022 (16.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 для всех пользовательских транзакций
  • Снятие всех блокировок сразу после аварийного завершения транзакции

• SLOG

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

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

• Очистка

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

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

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

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

Рекомендации по ADR

• Избегайте ненужных длительных транзакций. Хотя ADR ускоряет восстановление базы данных даже с длительными транзакциями, такие транзакции могут отложить очистку версии и увеличить размер PVS.

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

  • Многие языки определения данных (DDL) выполняются в одной транзакции. Например, в одной транзакции быстро создавались и удалялись временные таблицы.
  • Таблица имеет очень большое количество секций или индексов, которые изменяются. Например, для операции DROP TABLE в такой таблице потребуется большое резервирование памяти SLOG, что приведет к задержке усечения журнала транзакций и задержке операций отмены или повтора. В качестве обходного решения удалите индексы по отдельности и постепенно, а затем удалите таблицу.

  Дополнительные сведения о SLOG см. в компонентах восстановления ADR .

• Предотвращение или уменьшение ненужных прерванных транзакций. Высокая частота отмены транзакций создает давление на очищающее устройство PVS и снижает производительность ADR. Прерывания могут возникать из-за высокой частоты взаимоблокировок, дублированных ключей, нарушений ограничений или тайм-аутов запросов. В sys.dm_tran_aborted_transactions DMV отображаются все прерванные транзакции в экземпляре механизма базы данных. Столбец nested_abort указывает, что транзакция зафиксирована, но есть части, которые прервались (точки сохранения или вложенные транзакции), которые также могут задержать процесс очистки PVS.

• Убедитесь, что в базе данных достаточно места для учета использования PVS. Если в базе данных недостаточно места для увеличения объема PVS, это может привести к тому, что ADR не сможет создавать версии, что в свою очередь приведет к сбою выполнения инструкций DML.

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

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

  В Базе данных SQL Azure может потребоваться увеличить уровень служб или размер вычислительных ресурсов, чтобы обеспечить доступность достаточного пространства журнала транзакций для всех рабочих нагрузок. Аналогичным образом в Управляемом экземпляре SQL Azure может потребоваться увеличить максимальный размер хранилища экземпляра.

• Для SQL Server изолируйте хранилище версий PVS в файловой группе на более высококачественном уровне хранения, например, высококлассное SSD или продвинутое SSD, или постоянная память (PMEM), иногда именуемая памятью уровня хранения (SCM). Дополнительные сведения см. в разделе Изменение расположения PVS на другую файловую группу.

• Для SQL Server отслеживайте журнал ошибок для PreallocatePVS записей. Если присутствуют записи PreallocatePVS, возможно, потребуется увеличить способность ADR для предварительного выделения страниц с помощью фоновой задачи. Предварительное выделение страниц PVS в фоновом режиме повышает производительность ADR за счет снижения более дорогих выделений PVS в активном режиме. Чтобы увеличить этот объем, можно использовать конфигурацию сервера ADR Preallocation Factor. Более подробную информацию см. в разделе Конфигурация сервера: фактор предварительного распределения ADR.

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

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

Улучшения 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.

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

• Управление ускоренным восстановлением баз данных
• Устранение неполадок ускоренного восстановления баз данных