Устранение неполадок: превышение RTO в группе доступности

Область применения:SQL Server

После автоматического перехода на другой ресурс или планового перехода на другой ресурс вручную без потери данных в группе доступности можно обнаружить, что время перехода на другой ресурс превышает цель времени восстановления (RTO). Или, если при оценке времени переключения при отказе для вторичной реплики с синхронной фиксацией (например, партнёра по автоматическому переключению при отказе) с помощью метода, описанного в разделе Мониторинг производительности для групп доступности Always On, вы обнаруживаете, что оно превышает ваш RTO.

Если автоматический переход на другой ресурс все еще не завершен, см. раздел Устранение неполадок автоматического перехода на другой ресурс в средах AlwaysOn SQL Server 2012.

В следующих разделах описаны распространенные причины превышения времени аварийного переключения значения RTO.

  1. Нагрузка, связанная с отчетами, блокирует выполнение потока повторного выполнения

  2. Поток redo отстаёт из-за конкуренции за ресурсы

Нагрузка, связанная с формированием отчетов, блокирует выполнение потока redo

Поток повтора на вторичной реплике заблокирован и не может вносить изменения DDL из-за длительно выполняющегося запроса только для чтения.

Пояснение

На вторичной реплике запросы только на чтение приобретают блокировки стабильности схемы (Sch-S). Эти блокировки Sch-S могут мешать потоку повтора получать блокировки изменения схемы (Sch-M) для внесения изменений DDL. Заблокированный поток повтора не может применять записи журнала до разблокировки. После разблокировки он может продолжить обработку журнала до его конца, что позволит продолжить последующий процесс отмены и переключения при отказе.

Диагностика и способ устранения

Когда поток Redo блокируется, создается расширенное событие sqlserver.lock_redo_blocked. Кроме того, на вторичной реплике можно выполнить запрос к динамическому административному представлению sys.dm_exec_requests, чтобы определить, какой сеанс блокирует поток REDO, а затем принять корректирующие меры. Следующий запрос возвращает идентификатор сессии запроса только для чтения, который блокирует поток redo.

select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource   
from sys.dm_exec_requests where command = 'DB STARTUP'

Вы можете дождаться завершения нагрузки, связанной с отчетами, после чего поток повтора будет разблокирован, либо немедленно разблокировать поток повтора, выполнив команду KILL (Transact-SQL) для идентификатора блокирующего сеанса.

Поток Redo отстаёт из-за конкуренции за ресурсы

Высокая нагрузка из-за формирования отчетов на вторичной реплике замедлила ее производительность, и поток повторного выполнения отстал.

Пояснение

При применении записей журнала на вторичной реплике поток Redo считывает записи с диска журнала транзакций, а затем для каждой записи журнала обращается к страницам данных, чтобы применить её. Обращение к странице может быть привязано к вводу-выводу (доступ к физическому диску), если данная страница еще не находится в буферном пуле. Если имеется нагрузка, связанная с формированием отчетов и ограниченная производительностью ввода-вывода, она конкурирует с потоком redo за ресурсы ввода-вывода и может замедлить его работу.

Диагностика и способ устранения

Вы можете использовать приведенный ниже запрос к динамическому административному представлению, чтобы определить, насколько сильно отстал поток повторного выполнения, измерив величину разрыва между last_redone_lsn и last_received_lsn.

select recovery_lsn, truncation_lsn, last_hardened_lsn, last_received_lsn,   
   last_redone_lsn, last_redone_time  
from sys.dm_hadr_database_replica_states

Если поток повтора на самом деле запаздывает, нужно исследовать первопричину снижения производительности на вторичной реплике. Если возникает конкуренция за ресурсы ввода-вывода, связанная с нагрузкой отчетности, можно использовать Resource Governor для управления тактами ЦП, используемыми этой нагрузкой, чтобы тем самым косвенно, в некоторой степени, контролировать и потребление ресурсов ввода-вывода. Например, если нагрузка, связанная с формированием отчетов, потребляет 10 % ресурсов ЦП, но ограничена пропускной способностью ввода-вывода, можно с помощью Resource Governor ограничить использование ресурсов ЦП до 5 %, чтобы снизить нагрузку чтения, тем самым минимизировав влияние на операции ввода-вывода.

Связанные материалы

  • Last updated on