Необычное поведение CHECKPOINT в SQL Server

Question

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

У меня есть база данных, которая находится в простой модели восстановления и начинается с размера 10 ГБ.База данных находится на экземпляре SQL Server 2017 и настроена для косвенных контрольных точек с параметром target_recovery_time_in_seconds, установленным на 60.

У нас есть оповещения, которые инициируют процент использования журнала транзакций (70%), что обычно происходит, когда происходит внутренний CHECKPOINT,Затем мы продолжали получать оповещения, поскольку журнал транзакций продолжал расти и в итоге зарегистрировал заполнение на 99%, но дальнейшего роста не произошло.

Столбец log_reuse_wait_desc в sys.database показал ACTIVE TRANSACTION как причину, по которой последняя попытка обрезания журнала была последнейне удалось.Я подтвердил, что не было активных транзакций, запущенных с использованием близких ко всем соответствующим DMV.

Выдача CHECKPOINT вручную очистила wait_desc и усекла журнал.

Моя теория состоит в том, что в базе данных была активная транзакцияво время последней попытки усечения журнала, когда было нарушено использование журнала на 70%, или после того момента, когда были достигнуты целевые грязные буферы, которые должны быть сброшены на диск.В любом случае в тот момент была активная транзакция, которая препятствовала усечению журнала.Поскольку в этой последней контрольной точке была минимальная активность, в результате чего дальнейшая попытка контрольной точки не выполнялась из-за того, что не было достигнуто пороговое значение для грязных буферов, поэтому даже при отсутствии активного усечения журнала транзакций произойти невозможно, пока не будет выполнен CHECKPOINT.

Я намереваюсь установить Trace Flag 3502, чтобы увидеть активность контрольной точки, когда эта транзакция предположительно выполняется.

Кто-нибудь когда-либо сталкивался с таким поведением или знает, настроен ли для SQL Server откат для выполнения контрольных точек, когда значение выше 70% использования журнала транзакций, даже если журнал продолжает заполняться?

Большое спасибо!

Answer 1

Как отмечает @sepupic, выданная контрольная точка 70% использования пространства журнала является характеристикой автоматических контрольных точек, а не внутренних контрольных точек (см. Комментарии к вопросу).

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

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

Следовательно, почему последнее log_reuse_wait_desc оставалось ACTIVE TRANSACTION, даже если при расследовании не было обнаружено активной транзакции и что использование файла журнала было немедленно очищено с помощью введенной вручную команды CHECKPOINT.