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

Ускоренное восстановление базы данных (ADR) — это новая функция ядра СУБД SQL, которая значительно повышает доступность базы данных, особенно при наличии длительных транзакций, путем изменения процесса восстановления ядра СУБД SQL.Accelerated Database Recovery (ADR) is a new SQL database engine feature that greatly improves database availability, especially in the presence of long running transactions, by redesigning the SQL database engine recovery process. В настоящее время ADR доступен для отдельных баз данных и баз данных в составе пула в базе данных SQL Azure и баз данных в хранилище данных SQL Azure (в настоящее время это общедоступная Предварительная версия).ADR is currently available for single databases and pooled databases in Azure SQL Database, and databases in Azure SQL Data Warehouse (currently in public preview). Ниже приведены основные преимущества ADR:The primary benefits of ADR are:

  • Быстрое и последовательное восстановление базы данныхFast and consistent database recovery

    Благодаря ADR длительные транзакции не влияют на общее время восстановления, что позволяет быстро и последовательно восстанавливать базу данных, независимо от количества активных транзакций в системе или их размеров.With ADR, long running transactions do not impact the overall recovery time, enabling fast and consistent database recovery irrespective of the number of active transactions in the system or their sizes.

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

    Благодаря ADR откат транзакций выполняется мгновенно, независимо от времени активации транзакции или количества выполненных обновлений.With ADR, transaction rollback is instantaneous, irrespective of the time that the transaction has been active or the number of updates that has performed.

  • Интенсивное усечение журналаAggressive log truncation

    Благодаря ADR журнал транзакций интенсивно усекается даже при наличии активных длительных транзакций, что не позволяет ему выйти из-под управления.With ADR, the transaction log is aggressively truncated, even in the presence of active long running transactions, which prevents it from growing out of control.

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

Восстановление базы данных в SQL Server соответствует модели восстановления ARIES и состоит из трех этапов, которые проиллюстрированы на следующей схеме. Их подробное описание представлено ниже.Database recovery in SQL Server follows the ARIES recovery model and consists of three phases, which are illustrated in the following diagram and explained in more detail following the diagram.

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

  • Этап анализаAnalysis phase

    Пересылка журнала транзакций с начала последней успешной контрольной точки (или самой старой "грязной" страницы номер LSN) до конца, чтобы определить состояние каждой транзакции во время SQL Server остановлена.Forward scan of the transaction log from the beginning of the last successful checkpoint (or the oldest dirty page LSN) until the end, to determine the state of each transaction at the time SQL Server stopped.

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

    Пересылка журнала транзакций от самой старой незафиксированной транзакции до конца, чтобы перевести базу данных в состояние сбоя, повторно выполнив все зафиксированные операции.Forward scan of the transaction log from the oldest uncommitted transaction until the end, to bring the database to the state it was at the time of the crash by redoing all committed operations.

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

    В каждой транзакции, которая была активна на момент сбоя, происходит перемещение по журналу назад и отменяются операции, выполненные в ходе этой транзакции.For each transaction that was active as of the time of the crash, traverses the log backwards, undoing the operations that this transaction performed.

Исходя из этой схемы, время, необходимое ядру СУБД SQL для восстановления после неожиданного перезапуска, (примерно) пропорционально размеру самой продолжительной активной транзакции в системе во время сбоя.Based on this design, the time it takes the SQL database engine to recover from an unexpected restart is (roughly) proportional to the size of the longest active transaction in the system at the time of the crash. Для восстановления требуется откат всех незавершенных транзакций.Recovery requires a rollback of all incomplete transactions. Требуемый отрезок времени пропорционален работе, выполненной транзакцией, и времени, в течение которого она была активной.The length of time required is proportional to the work that the transaction has performed and the time it has been active. Таким образом, процесс восстановления SQL Server может занять много времени при наличии длительных транзакций (таких как операции массовой вставки или операции создания индексов в большой таблице).Therefore, the SQL Server recovery process can take a long time in the presence of long running transactions (such as large bulk insert operations or index build operations against a large table).

Кроме того, отмена или откат большой транзакции по этой схеме также может занять много времени, так как используется та же самая стадия восстановления (стадия отката), как описано выше.Also, cancelling/rolling back a large transaction based on this design can also take a long time as it is using the same Undo recovery phase as described above.

Кроме того, ядро СУБД SQL не может усечь журнал транзакций при длительных транзакциях, потому что соответствующие записи журнала необходимы для процессов восстановления и отката.In addition, the SQL database engine cannot truncate the transaction log when there are long running transactions because their corresponding log records are needed for the recovery and rollback processes. В результате такого конструктивного механизма СУБД SQL некоторые клиенты сталкиваются с проблемой того, что размер журнала транзакций растет очень много и потребляет огромные объемы дискового пространства.As a result of this design of the SQL database engine, some customers face the problem that the size of the transaction log grows very large and consumes huge amounts of drive space.

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

С помощью функции ADR можно решить вышеуказанные проблемы, полностью изменив процесс восстановления ядра СУБД SQL следующим образом:ADR addresses the above issues by completely redesigning the SQL database engine recovery process to:

  • Сделайте восстановление непрерывным или мгновенным, устранив необходимость сканировать журнал с или до начала самой старой активной транзакции.Make it constant time/instant by avoiding having to scan the log from/to the beginning of the oldest active transaction. В случае с ADR журнал транзакций обрабатывается только из последней успешной контрольной точки (или самого старого номера LSN, который был изменен в журнале страниц).With ADR, the transaction log is only processed from the last successful checkpoint (or oldest dirty page Log Sequence Number (LSN)). В результате на время восстановления не влияют длительные транзакции.As a result, recovery time is not impacted by long running transactions.
  • Уменьшите требуемое пространство журнала транзакций, так как больше не нужно обрабатывать журнал для всей транзакции.Minimize the required transaction log space since there is no longer a need to process the log for the whole transaction. В результате журнал транзакций можно значительно усечь, так как создаются контрольные точки и резервные копии.As a result, the transaction log can be truncated aggressively as checkpoints and backups occur.

На высоком уровне, ADR обеспечивает быстрое восстановление базы данных путем управления версиями всех физических изменений базы данных и только отмену логических операций, которые ограничены и могут быть отменены почти мгновенно.At a High Level, ADR achieves fast database recovery by versioning all physical database modifications and only undoing logical operations, which are limited and can be undone almost instantly. Любая транзакция, которая была активна на момент сбоя, помечается как прерванная, и поэтому любые версии, созданные такими транзакциями, могут быть проигнорированы в параллельных запросах пользователей.Any transaction that was active as of the time of a crash are marked as aborted and, therefore, any versions generated by these transactions can be ignored by concurrent user queries.

Процесс восстановления ADR состоит из тех же трех этапов, что и текущий процесс восстановления.The ADR recovery process has the same three phases as the current recovery process. Этапы восстановления ADR проиллюстрированы на следующей схеме, а их подробное описание представлено ниже.How these phases operate with ADR is illustrated in the following diagram and explained in more detail following the diagram.

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

  • Этап анализаAnalysis phase

    Процесс остается таким же, как и на сегодняшний день, с добавлением реконструирования sLog и копированием записей журнала для операций без управления версиями.The process remains the same as today with the addition of reconstructing sLog and copying log records for non-versioned operations.

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

    Эта стадия разделена на два этапа.Broken into two phases (P)

    • Этап 1Phase 1

      Повтор в sLog (самая старая незафиксированная транзакция до последней контрольной точки).Redo from sLog (oldest uncommitted transaction up to last checkpoint). Повтор — это быстрая операция, так как необходимо обработать всего несколько записей из sLog.Redo is a fast operation as it only needs to process a few records from the sLog.

    • Этап 2Phase 2

      Повтор в журнале транзакций начинается с последней контрольной точки (вместо самой старой незафиксированной транзакции).Redo from Transaction Log starts from last checkpoint (instead of oldest uncommitted transaction)

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

    Стадия отката, выполняемая с помощью ADR, завершается почти мгновенно с использованием sLog для отката неверсионных операций и постоянного хранилища версий (PVS) с логической отменой для выполнения отката версий на уровне строк.The Undo phase with ADR completes almost instantaneously by using sLog to undo non-versioned operations and Persisted Version Store (PVS) with Logical Revert to perform row level version-based Undo.

Компоненты восстановления ADRADR recovery components

Ниже приведены четыре основных компонента ADR:The four key components of ADR are:

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

    Постоянное хранилище версий — это новое ядро СУБД SQL, предназначенное для хранения версий строк, созданных в базе данных, вместо традиционного хранилища версий tempdb.The persisted version store is a new SQL database engine mechanism for persisting the row versions generated in the database itself instead of the traditional tempdb version store. PVS позволяет изолировать ресурсы, а также повышает доступность получателей, доступных для чтения.PVS enables resource isolation as well as improves availability of readable secondaries.

  • Логическая отменаLogical Revert

    Логический откат — это асинхронный процесс, ответственный за отмену изменений на уровне строк, предоставляя мгновенный откат и отмену операций с управлением версиями.Logical revert is the asynchronous process responsible for performing row-level version-based Undo - providing instant transaction rollback and undo for all versioned operations. Логический откат выполняется следующим образом.Logical revert is accomplished by:

    • Отслеживание всех прерванных транзакций и пометка их невидимыми для других транзакций.Keeping track of all aborted transactions and marking them invisible to other transactions.
    • Выполнение отката с помощью постоянного хранилища версий для всех пользовательских транзакций вместо физического сканирования журнала транзакций и отмены изменений по одному за раз.Performing rollback by using PVS for all user transactions, rather than physically scanning the transaction log and undoing changes one at a time.
    • Освобождение всех блокировок сразу после прерывания транзакции.Releasing all locks immediately after transaction abort. Так как прерывание подразумевает простое пометку изменений в памяти, процесс очень эффективен, поэтому блокировки не должны храниться в течение длительного времени.Since abort involves simply marking changes in memory, the process is very efficient and therefore locks do not have to be held for a long time.
  • sLogsLog

    sLog — это дополнительный поток журналов в памяти, в котором хранятся записи журналов для неверсионных операций (например, недействительность кэша метаданных, блокировка и т. д.).sLog is a secondary in-memory log stream that stores log records for non-versioned operations (such as metadata cache invalidation, lock acquisitions, and so on). Характеристики sLog:The sLog is:

    • Имеет небольшой объем и выполняется в памяти.Low volume and in-memory
    • Сохраняется на диске путем сериализации во время выполнения процесса контрольной точки.Persisted on disk by being serialized during the checkpoint process
    • Периодически усекается по мере фиксации транзакций.Periodically truncated as transactions commit
    • Ускоряет повтор и отмену, обрабатывая только неверсионные операции.Accelerates redo and undo by processing only the non-versioned operations
    • Включает интенсивное усечение журнала транзакций, сохраняя только необходимые записи журнала.Enables aggressive transaction log truncation by preserving only the required log records
  • ОчисткаCleaner

    Очистка — это асинхронный процесс, который периодически активируется и очищает ненужные версии страниц.The cleaner is the asynchronous process that wakes up periodically and cleans page versions that are not needed.

Кому рекомендуется использовать ускоренное восстановление базы данныхWho should consider Accelerated Database Recovery

Рекомендуем рассмотреть возможность включения ADR следующим клиентам:The following types of customers should consider enabling ADR:

  • Клиентам, имеющим рабочие нагрузки с длительными транзакциями.Customers that have workloads with long running transactions.
  • Клиентам, у которых возникают случаи, когда активные транзакции значительно увеличивают журнал транзакций.Customers that have seen cases where active transactions are causing the transaction log to grow significantly.
  • Клиентам, у которых в течение продолжительного периода недоступна база данных из-за долгого восстановления SQL Server (например, неожиданный перезапуск SQL Server или ручной откат транзакций).Customers that have experienced long periods of database unavailability due to SQL Server long running recovery (such as unexpected SQL Server restart or manual transaction rollback).