Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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ê pode constatar que o tempo de failover excede o objetivo de tempo de recuperação (RTO). 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.
A carga de trabalho de geração de relatórios impede que a thread de redo seja executada
Thread de redo fica para trás devido à contenção de recursos
A carga de trabalho de relatórios impede a execução da thread de redo
A thread de redo na réplica secundária é bloqueada de realizar alterações de linguagem de definição de dados (DDL) por uma consulta de somente leitura de longa execução.
Explicação
Na réplica secundária, as consultas somente de leitura adquirem bloqueios de estabilidade de esquema (Sch-S). Esses bloqueios Sch-S podem impedir o thread de refazer de adquirir bloqueios de modificação de esquema (Sch-M) para executar quaisquer alterações de DDL. Uma thread de redo bloqueada não pode aplicar registros do log até ser desbloqueada. Depois de desbloqueado, ele pode continuar a alcançar o fim do log e permitir que o processo subsequente de desfazer e failover continue.
Diagnóstico e resolução
Quando a thread de redo é bloqueada, 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 o ID da sessão da consulta somente leitura que está bloqueando 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'
Você pode deixar que a carga de trabalho de relatórios seja concluída e, nesse momento, a thread de redo será desbloqueada, ou pode desbloquear imediatamente a thread de redo executando o comando KILL (Transact-SQL) no ID da sessão de bloqueio.
Thread de redo atrasa devido à contenção de recursos
Uma grande carga de relatórios na réplica secundária prejudicou o desempenho da réplica secundária, e a thread de redo ficou atrasada.
Explicação
Ao aplicar registros de log na réplica secundária, a thread de redo lê os registros de log do disco de log e, em seguida, para cada registro de log, acessa as páginas de dados para aplicá-lo. O acesso à página pode ser limitado por E/S (ao acessar o disco físico) se a página ainda não estiver no conjunto 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 o quanto o thread de redo ficou atrasado, medindo a diferença da 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 a thread de redo estiver realmente atrasada, será necessário investigar a causa raiz da degradação do desempenho na réplica secundária. Se houver contenção de E/S com a carga de trabalho de geração de relatórios, você poderá usar o Resource Governor para controlar os ciclos de CPU usados por essa carga de trabalho e, assim, controlar indiretamente, até certo ponto, os ciclos de E/S consumidos. Por exemplo, se sua carga de trabalho de relatórios estiver consumindo 10% de CPU, mas for limitada por E/S, você poderá usar o Resource Governor para limitar o uso de recursos de CPU a 5% a fim de reduzir a carga de leitura, minimizando o impacto na E/S.