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 planeado sem perda de dados num grupo de disponibilidade, poderá constatar que o tempo de failover excede o seu objetivo de tempo de recuperação (RTO). Ou, quando estima o tempo de ativação pós-falha de uma réplica secundária de confirmação síncrona (como um parceiro de ativação pós-falha automática) utilizando o método descrito em Monitorizar o desempenho de Grupos de Disponibilidade Always On, verifica que esse tempo ultrapassa o seu RTO.

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

As secções seguintes descrevem as causas comuns de um tempo de failover que excede o RTO.

  1. A carga de trabalho de criação de relatórios impede a thread de repetição de ser executada

  2. A thread de redo atrasa-se devido à contenção de recursos

A carga de trabalho de criação de relatórios impede a thread de refazer de ser executada

A thread de redo na réplica secundária está impedida de efetuar alterações à linguagem de definição de dados (DDL) por uma consulta só de leitura de execução prolongada.

Explanation

Na réplica secundária, as consultas de apenas leitura adquirem bloqueios de estabilidade de esquema (Sch-S). Estes Sch-S bloqueios podem impedir o thread de redo de adquirir bloqueios de modificação de esquema (Sch-M) para efetuar quaisquer alterações DDL. Um encadeamento de redo bloqueado não pode aplicar registos de log enquanto não for desbloqueado. Uma vez desbloqueado, pode continuar a avançar até ao fim do registo e permitir que o processo subsequente de anulação e failover possa prosseguir.

Diagnóstico e resolução

Quando a thread de refazer é bloqueada, é gerado um evento estendido chamado sqlserver.lock_redo_blocked . Além disso, pode consultar a DMV sys.dm_exec_request na réplica secundária para descobrir qual é a sessão que está a bloquear a thread REDO e, em seguida, tomar medidas corretivas. A consulta seguinte devolve o ID da sessão da consulta em modo só de leitura que está a bloquear a thread de redo.

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

Pode deixar a carga de trabalho de elaboração de relatórios terminar, altura em que a thread de redo é desbloqueada, ou pode desbloquear imediatamente a thread de redo executando o comando KILL (Transact-SQL) no ID da sessão que está a bloquear.

O encadeamento de repetição atrasa-se devido à contenção de recursos

Uma grande carga de trabalho de reporte na réplica secundária atrasou o desempenho da réplica secundária, e a thread de refazer ficou atrasada.

Explanation

Ao aplicar registos de registo na réplica secundária, o thread redo lê os registos de registo do disco de registo e, para cada registo de registo, acede às páginas de dados para aplicar o registo de registo. O acesso à página pode ser vinculado por I/O (aceder ao disco físico) se a página ainda não estiver no buffer pool. Se existir uma carga de trabalho de geração de relatórios limitada pela E/S, essa carga de trabalho compete com a thread de redo pelos recursos de E/S e pode abrandar a thread de redo.

Diagnóstico e resolução

Pode utilizar a seguinte consulta DMV para ver até que ponto a thread de redo ficou atrasada, medindo a diferença do intervalo 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 a thread de refazer estiver realmente atrasada, precisa de investigar a causa raiz da degradação de desempenho na réplica secundária. Se houver contenção de E/S com a carga de trabalho de relatórios, pode utilizar o Resource Governor para controlar os ciclos de CPU utilizados pela carga de trabalho de relatórios, de modo a controlar indiretamente, até certo ponto, os ciclos de E/S utilizados. Por exemplo, se a sua carga de trabalho de relatórios estiver a consumir 10 por cento do CPU, mas a carga de trabalho estiver limitada por E/S, pode utilizar o Resource Governor para limitar a utilização de recursos do CPU a 5 por cento, de modo a abrandar a carga de trabalho de leitura, o que minimiza o impacto na E/S.

Conteúdo relacionado

  • Last updated on