Solução de problemas: o grupo de disponibilidade excedeu o RTO

Aplica-se a:SQL Server

Após um failover automático ou um failover manual planejado sem perda de dados em um grupo de disponibilidade, você descobre que o tempo de failover excedeu o RTO (objetivo de tempo de recuperação). Ou, quando você calcula o tempo de failover de uma réplica secundária de confirmação síncrona (como um parceiro de failover automático) usando o método em Monitorar o desempenho de Grupos de Disponibilidade Always On, você descobre que ele excede o RTO.

Se o failover automático ainda não foi concluído, veja Solução de problemas de failover automático em ambientes de Always On do SQL Server 2012.

As seções a seguir descrevem as causas comuns de um tempo de failover que excede o RTO.

1. Carga de trabalho de relatório impede a execução do thread refazer

2. Thread refazer atrasa devido à contenção de recursos

Carga de trabalho de relatório bloqueia a execução do thread refazer

O thread refazer na réplica secundária é impedido de fazer alterações de DDL (linguagem de definição de dados) por uma consulta somente leitura de longa execução.

Explicação

Na réplica secundária, as consultas somente leitura adquirem bloqueios de estabilidade de esquema (Sch-S). Esses bloqueios Sch-S podem impedir o thread refazer de adquirir bloqueios de modificação de esquema (Sch-M) para fazer alterações de DDL. Um thread refazer bloqueado não pode aplicar registros de log até que seja desbloqueado. Quando desbloqueado, ele poderá continuar a compensar até o final do log e permitir que o processo de failover e de desfazer subsequentes prossigam.

Diagnóstico e resolução

Quando o thread refazer é bloqueado, um evento estendido chamado sqlserver.lock_redo_blocked é gerado. Além disso, você pode consultar o sys.dm_exec_request do DMV na réplica secundária para descobrir qual sessão está bloqueando o thread REDO e, em seguida, tomar uma ação corretiva. A consulta a seguir retorna a ID da sessão da consulta somente leitura que está bloqueando o thread refazer.

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

Você pode permitir que a carga de trabalho de relatório seja concluída, momento em que o thread refazer é desbloqueado, ou pode desbloquear imediatamente o thread refazer executando o comando KILL (Transact-SQL) na ID de sessão que está bloqueando.

Thread refazer atrasa devido à contenção de recursos

Uma grande carga de trabalho de relatório na réplica secundária reduziu o desempenho da réplica secundária, e o thread refazer atrasou.

Explicação

Ao aplicar registros de log na réplica secundária, o thread refazer lê os registros de log no disco de log e, em seguida, para cada registro de log, ele acessa as páginas de dados para aplicar o registro de log. O acesso à página poderá ser associado a E/S (acessando o disco físico) se a página ainda não estiver no pool de buffers. Se houver carga de trabalho de relatório associada a E/S, a carga de trabalho de relatório concorrerá, em termos de recursos de E/S, com o thread refazer e poderá causar lentidão nesse thread.

Diagnóstico e resolução

Você pode usar a seguinte consulta DMV para ver quanto o thread refazer atrasou, medindo a diferença entre a lacuna entre last_redone_lsn e 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  
  

Se o thread refazer estiver realmente atrasado, será necessário investigar a causa raiz da degradação do desempenho na réplica secundária. Se houver uma contenção de E/S com a carga de trabalho de relatório, você poderá usar o Resource Governor para controlar os ciclos de CPU que são usados pela carga de trabalho de relatório para controlar indiretamente os ciclos de E/S executados, até certo ponto. Por exemplo, se sua carga de trabalho de relatório estiver consumindo 10% da CPU, mas a carga de trabalho estiver associada a E/S, você poderá usar o Resource Governor para limitar o uso de recursos de CPU a 5% a fim de limitar a carga de trabalho de leitura, minimizando o impacto na E/S.

Próximas etapas

Solução de problemas de desempenho no SQL Server (aplica-se ao SQL Server 2012)