Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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.
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.