Ускоренное восстановление базы данных (Accelerated Database Recovery, ADR) появилось в SQL Server 2019. Его основная цель — обеспечить более быстрое восстановление базы данных в случае сбоя или неожиданного выключения. Традиционно процесс восстановления включал несколько фаз — анализ, повторное выполнение (redo) и откат (undo). Этот подход мог быть неэффективным и долгим, особенно при наличии длительных транзакций.
Если коротко, ADR упрощает процесс восстановления благодаря новому подходу к откату. Вместо того чтобы полностью полагаться на сканирование журнала транзакций — что может быть крайне медленно при откате незавершённых или долгих транзакций — ADR ведёт специальное хранилище версий внутри пользовательской базы данных, где фиксируются изменения на уровне строк. Это позволяет SQL Server быстро откатывать незавершённые транзакции без сканирования всего журнала. Результат — значительно более быстрое восстановление после сбоя, мгновенный откат и общая улучшенная доступность базы данных, особенно в высоконагруженных средах.
Развитие Accelerated Database Recovery
Как уже упоминалось, ADR был впервые представлен в SQL Server 2019. В SQL Server 2022 были внесены важные улучшения, в первую очередь в работу с конфигурацией на уровне базы данных, в том числе в механизм Persistent Version Store (PVS).
Что нового в SQL Server 2025?
Начиная с SQL Server 2025, появилась возможность использовать Accelerated Database Recovery (ADR) и в tempdb. Ранее это было доступно только для пользовательских баз данных. Применение ADR в tempdb позволяет выполнять мгновенный откат транзакций и более агрессивно очищать журнал транзакций. Это особенно полезно в ситуациях, когда длительные или некорректно работающие транзакции с временными таблицами или переменными таблицами создают серьёзную нагрузку на tempdb и его журнал.
Предупреждение для администраторов (DBA)
Хотя возникает соблазн включить эту функцию сразу, разумнее будет подождать, пока она «созреет», прежде чем использовать её в продакшене. Microsoft упоминает о проблеме, связанной с ADR в tempdb, но делает это в отдельной статье, а не в основной документации (по мнению автора, это должно быть вынесено на первый план).
Суть проблемы: включение ADR в tempdb, особенно в средах с частым созданием, удалением или очисткой временных таблиц, может привести к падению производительности SQL Server. Возможна серьёзная деградация пропускной способности из-за блокировок (latch contention) на внутренней системной таблице sys.sysobjvalues. Microsoft уже изучает эту проблему и планирует её исправить в будущих версиях.
Ещё один нюанс: занимаемое место на диске
Как и в пользовательских базах, Persistent Version Store (PVS) для ADR создаётся в файлах данных tempdb.
Если сервер активно использует временные таблицы, потребуется учитывать это, добавляя больше пространства для tempdb
и, возможно, более быстрые диски для хранения версий строк.
В таких случаях стоит рассмотреть настройку параметра ADR Cleaner Thread Count через sp_configure.
Этот параметр позволяет перевести процесс очистки PVS с однопоточного на многопоточный режим,
что ускоряет удаление ненужных версий страниц.
Что делать, пока ждём SQL Server 2025
Так как не стоит спешить с внедрением этой функции в продакшене, будет полезно убедиться, что tempdb уже настроен по лучшим практикам. Для этого существует бесплатный инструмент sp_CheckTempdb, написанный Джеффом Яннуччи из Straight Path. Это простая в установке и запуске хранимая процедура, которая анализирует конфигурацию tempdb и выдаёт полезные рекомендации, а также выявляет проблемы.
Заключение
Новая возможность ADR в SQL Server 2025 открывает путь к повышенной стабильности в приложениях, где часто возникают проблемы с журналом транзакций tempdb. Однако, как уже говорилось, стоит подождать появления обновлений от Microsoft, которые улучшат взаимодействие ADR и tempdb, прежде чем рассматривать это как стандартную практику.
Комментариев нет:
Отправить комментарий