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

  • Статья

Применимо к: База данных SQL Azure Управляемый экземпляр SQL Azure

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

В настоящее время ADR доступна для Базы данных SQL Azure, Управляемого экземпляра SQL Azure, баз данных в Azure Synapse Analytics и SQL Server на виртуальных машинах Azure, начиная с SQL Server 2019. Дополнительные сведения об ADR в SQL Server см. в статье Управление ускоренным восстановлением базы данных.

Примечание.

ADR включается по умолчанию в Базе данных SQL Azure и Управляемом экземпляре SQL Azure. Отключение ADR в Базе данных SQL Azure и Управляемом экземпляре Azure SQL не поддерживается.

Обзор

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

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

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

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

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

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

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

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

Восстановление базы данных соответствует модели восстановления ARIES и состоит из трех этапов, которые проиллюстрированы на следующей схеме. Их подробное описание представлено ниже.

текущий процесс восстановления

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс восстановления ADR

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

    Процесс остается таким же, но при этом воссоздается SLOG и копируются записи журнала для операций без версий.

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

    Эта стадия разделена на два этапа.

    • Фаза 1

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

    • Фаза 2

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

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

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

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

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

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

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

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

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

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

  • SLOG

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

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

  • Очистка

    Очистка — это асинхронный процесс, который периодически активируется и очищает ненужные версии страниц.

Шаблоны ускоренного восстановления базы данных (ADR)

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

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

Рекомендации по использованию Ускоренного восстановления баз данных

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

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

    • Многие DDL выполняются в рамках одной транзакции. Например, в рамках одной транзакции быстро создаются и удаляются временные таблицы.

    • Таблица имеет очень большое количество изменяемых секций или индексов. Например, при выполнении операции DROP TABLE для такой таблицы потребуется большое резервирование памяти SLOG, что приведет к задержке усечения журнала транзакций и задержке операций отмены и повтора. Проблему можно решить, удаляя индексы по отдельности и постепенно с последующим удалением таблицы. Дополнительные сведения о SLOG см. в статье Компоненты восстановления ADR.

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

    • DMV sys.dm_tran_aborted_transactions отображает все прерванные транзакции в экземпляре SQL Server. В столбце nested_abort указано, что транзакция зафиксирована, но есть прерванные части (точки сохранения или вложенные транзакции), которые могут заблокировать процесс очистки PVS. Дополнительные сведения см. в статье sys.dm_tran_aborted_transactions (Transact-SQL).

    • Чтобы активировать процесс очистки PVS вручную между рабочими нагрузками или во время периодов обслуживания, используйте sys.sp_persistent_version_cleanup. Дополнительные сведения см. в статье sys.sp_persistent_version_cleanup.

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

Следующие шаги