Ускоренное восстановление базы данных (Accelerated Database Recovery, ADR) появилось в SQL Server 2019 и обеспечивает быстрое восстановление, мгновенный откат транзакций и агрессивное усечение журнала. Полный обзор того, как ADR этого добивается, приведён в документации.
Теперь в SQL Server 2025 можно включить ADR для tempdb! Быстрое восстановление к tempdb не применимо, но вот мгновенный откат транзакций и агрессивное усечение журнала — на все 100%. Посмотрим, что происходит после включения ADR для tempdb в SQL Server 2025.
Прежде чем начинать тест, посмотрим, сколько места в журнале tempdb занято сейчас:
USE [tempdb];
GO
SELECT database_id, used_log_space_in_percent FROM sys.dm_db_log_space_usage
GO
ОК, как и ожидалось, журнал используется немного.
В первом тесте посмотрим поведение без включённого ADR. Убедимся, что ADR отключён:
SELECT name, is_accelerated_database_recovery_on
FROM sys.databases
WHERE database_id = 2
GO
Отлично! В новом окне SSMS запустим:
USE [tpcc];
GO
SET STATISTICS TIME ON
BEGIN TRANSACTION
SELECT TOP (1000000) * INTO #TempTable
FROM [dbo].[order_line];
UPDATE #TempTable
SET ol_amount = ol_amount + 1;
Немного кода, который вставляет данные во временную таблицу, а затем обновляет их… в надежде, что что-то в журнал запишется и будет что проанализировать.
Кстати, базу, из которой я здесь вытягиваю данные, я развернул из контейнера HammerDB от Anthony Nocentino (очень удобно, рекомендую).
После выполнения скрипта смотрим объём занятого журнала в tempdb:
USE [tempdb];
GO
SELECT database_id, used_log_space_in_percent FROM sys.dm_db_log_space_usage
GO
97%… почти полный. Да, признаю, на этом экземпляре журнал довольно маленький — в демонстрационных целях. Но всё же… мы должны увидеть разницу, когда повторим тест с включённым ADR.
Сначала откатим транзакцию:
ROLLBACK
Время разбора и компиляции SQL Server: CPU time = 0 ms, elapsed time = 0 ms.
Время выполнения SQL Server: CPU time = 1187 ms, elapsed time = 1342 ms.
Долго не заняло, но откатывать было что.
Теперь посмотрим, что изменится, если включить ADR для tempdb.
Включаем ADR в tempdb:
ALTER DATABASE [tempdb] SET ACCELERATED_DATABASE_RECOVERY = ON
GO
Хорошая новость: для этого не требуется эксклюзивная блокировка tempdb. Плохая: чтобы изменение вступило в силу, нужно перезапустить экземпляр SQL Server.
После перезапуска проверим, что ADR включён:
SELECT name, is_accelerated_database_recovery_on
FROM sys.databases
WHERE database_id = 2
GO
Проверим снова использование журнала:
SELECT database_id, used_log_space_in_percent FROM sys.dm_db_log_space_usage
GO
Около 4.4%… теперь снова запускаем запрос во втором окне:
USE [tpcc];
GO
SET STATISTICS TIME ON
BEGIN TRANSACTION
SELECT TOP (1000000) * INTO #TempTable
FROM [dbo].[order_line];
UPDATE #TempTable
SET ol_amount = ol_amount + 1
После завершения проверим, сколько пространства занято в журнале транзакций tempdb:
SELECT database_id, used_log_space_in_percent FROM sys.dm_db_log_space_usage
GO
56%… существенно меньше, чем 97% при отключённом ADR. Причина в том, что при включённом ADR журнал транзакций «агрессивно усечётся»… даже при активных транзакциях! Теперь восстановление опирается на persistent version store (PVS), SLOG и лишь часть журнала, начиная с последней контрольной точки. Поскольку больше нет необходимости хранить журнал за всю транзакцию, его можно активно усекать по мере выполнения контрольных точек и резервного копирования.
И теперь посмотрим, что произойдёт при откате транзакции:
ROLLBACK
Время разбора и компиляции SQL Server: CPU time = 0 ms, elapsed time = 0 ms.
Время выполнения SQL Server: CPU time = 0 ms, elapsed time = 1 ms.
Практически мгновенный откат!
Это потому, что вместо сканирования журнала транзакций для отката изменений ADR позволяет SQL Server выполнить логический возврат (logical revert), мгновенно отменяя все версионированные операции, используя PVS.
Очень удобно для нагрузок с активным использованием временных объектов! Однако у ADR есть нюансы, о которых стоит помнить — полный список смотрите в документации Microsoft.
Комментариев нет:
Отправить комментарий