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

Область применения: SQL Server 2019 (15.x)

В этой статье содержатся сведения о рекомендациях по управлению и настройке ускоренного восстановления базы данных (ADR) в SQL Server 2019 (15.x) и более поздних версиях. Дополнительные сведения об ADR в Azure SQL см. в статье Ускоренное восстановление базы данных в Azure SQL.

Примечание.

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

Когда следует использовать ускоренное восстановление баз данных

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

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

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

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

• ADR не поддерживается для баз данных, развертываемых в зеркальном отображении базы данных.

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

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

Оценка оптимальности вашей рабочей нагрузки для ADR

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

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

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

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

• Рабочие нагрузки с длительными запросами в режимах изоляции SNAPSHOT или READ COMMITTED SNAPSHOT могут отложить очистку ADR PVS в других базах данных, что приведет к росту файла PVS. Дополнительные сведения см. в разделе о длинных активных сканированиях моментальных снимков в статье "Устранение неполадок ускоренного восстановления базы данных". Это относится к экземплярам SQL Server и Управляемый экземпляр SQL Azure или в База данных SQL Azure эластичном пуле.

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

В этом разделе содержатся указания и рекомендации по использованию ADR.

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

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

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

• Избегайте больших транзакций с изменениями определений данных или операциями 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).

Включение и управление ADR

Примечание.

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

ADR отключен по умолчанию в SQL Server 2019 (15.x) и может управляться с помощью синтаксиса DDL:

ALTER DATABASE [DB] SET ACCELERATED_DATABASE_RECOVERY = {ON | OFF};

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

Для изменения этого состояния требуется монопольная блокировка базы данных. Это означает, что команда ALTER DATABASE будет остановлена, пока все активные сеансы не будут удалены, а все новые сеансы будут ожидать команды ALTER DATABASE. Если важно завершить операцию и снять блокировку, можно использовать предложение завершения WITH ROLLBACK [IMMEDIATE | AFTER {number} SECONDS | NO_WAIT], чтобы прервать все активные сеансы в базе данных. Дополнительные сведения см. в статье Параметры ALTER DATABASE SET.

Управление файловой группой постоянного хранилища версий

Функция ADR основана на управлении версиями. Различные версии элементов данных хранятся в PVS. Существуют рекомендации по размещению PVS и управлению размером данных в PVS.

Включение ADR без указания файловой группы

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

ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = ON;
GO

Если файловая группа PVS не указана, данные PVS хранятся в файловой группе PRIMARY.

Чтобы включить ADR и указать, что PVS следует хранить в файловой группе.

Вы можете настроить ADR для использования другой файловой группы, помимо файловой группы по умолчанию PRIMARY , для хранения данных PVS.

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

Создайте файловую группу VersionStoreFG и создайте файл данных в файловой группе. Например:

ALTER DATABASE [MyDatabase] ADD FILEGROUP [VersionStoreFG];
GO
ALTER DATABASE [MyDatabase] ADD FILE ( NAME = N'VersionStoreFG'
, FILENAME = N'E:\DATA\VersionStore.ndf'
, SIZE = 8192KB , FILEGROWTH = 65536KB )
TO FILEGROUP [VersionStoreFG];
GO

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

ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = ON
(PERSISTENT_VERSION_STORE_FILEGROUP = [VersionStoreFG]);

Отключение функции ADR

ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = OFF;
GO

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

Перемещение PVS в другую файловую группу

На сервере SQL Server может потребоваться переместить постоянное хранилище версий в другую файловую группу по тем или иным причинам. Например, для PVS может потребоваться больше места или более быстрое хранилище.

Перемещение PVS выполняется в три этапа.

1. Отключите функцию ADR.

   ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = OFF;
   GO
   

2. Дождитесь освобождения всех версий, хранящихся в PVS.

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

   EXEC sys.sp_persistent_version_cleanup [database name];
   

   Хранимая процедура sys.sp_persistent_version_cleanup является синхронной, то есть она не будет завершена до тех пор, пока все сведения о версиях не будут удалены из текущего хранилища PVS. После завершения ее выполнения можно проверить, действительно ли сведения о версиях были удалены, запросив динамическое административное представление sys.dm_tran_persistent_version_store_stats и проверив значение persistent_version_store_size_kb.

   SELECT DB_Name(database_id), persistent_version_store_size_kb 
   FROM sys.dm_tran_persistent_version_store_stats where database_id = [MyDatabaseID];
   

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

3. Включите ADR, указав новое расположения для PVS:

   ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = ON
   (PERSISTENT_VERSION_STORE_FILEGROUP = [VersionStoreFG]);
   

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

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