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
A aplicação cliente conclui com sucesso uma atualização na réplica primária, mas ao consultar a réplica secundária mostra que a alteração não é refletida. Este cenário pressupõe que a disponibilidade se encontra num estado de sincronização saudável. Na maioria dos casos, este comportamento resolve-se ao fim de alguns minutos.
Se as alterações ainda não forem refletidas na réplica secundária após alguns minutos, pode haver um gargalo no fluxo de trabalho de sincronização. A localização do gargalo depende de se a réplica secundária está configurada para commit síncrono ou commit assíncrono.
de confirmação síncrona
Cada atualização bem-sucedida na réplica primária já foi sincronizada com a réplica secundária, ou que os registos de registo já foram lavados para endurecimento na réplica secundária. Portanto, o gargalo deverá estar no processo de repetição que ocorre depois de o log ser gravado em disco na réplica secundária.
No entanto, uma vez que o redo está em dia, todas as cargas de trabalho de leitura na réplica secundária são isoladas por snapshot:
Transações de longa duração na réplica primária
Refazer na réplica secundária
Confirmação assíncrona
Como o commit assíncrono confirma uma transação assim que esta é gravada no disco local, o gargalo pode estar em qualquer ponto a partir daí:
Transações de longa duração na réplica primária
Latência de rede ou débito
Endurecimento de troncos na réplica secundária
Refazer a réplica secundária
As secções seguintes descrevem as causas comuns pelas quais as alterações efetuadas na réplica primária não se refletem na réplica secundária em consultas só de leitura.
Transações ativas de longa duração
Uma transação prolongada na réplica primária impede que as atualizações sejam lidas na réplica secundária.
Explanation
Todas as cargas de trabalho de leitura na réplica secundária são consultas de isolamento de instantâneos. Em isolamento de instantâneos, os clientes apenas de leitura veem a base de dados de disponibilidade na réplica secundária no ponto inicial da transação ativa mais antiga no registo refeito. Se uma transação não tiver sido confirmada há horas, a transação aberta bloqueia todas as consultas só de leitura de ver novas atualizações.
Diagnóstico e resolução
Na réplica principal, use DBCC OPENTRAN (Transact-SQL) para consultar as transações ativas mais antigas e verificar se estas podem ser revertidas. Uma vez que as transações ativas mais antigas são anuladas e sincronizadas com a réplica secundária, as cargas de trabalho de leitura na réplica secundária podem ver atualizações na base de dados de disponibilidade até ao início da que for então a transação ativa mais antiga.
A elevada latência da rede ou a baixa taxa de transferência da rede causam acumulação de registos na réplica primária
A elevada latência de rede ou a baixa taxa de transferência podem impedir que os registos sejam enviados para a réplica secundária com rapidez suficiente.
Explanation
A réplica primária ativa o controlo de fluxo no envio do log quando ultrapassa o número máximo permitido de mensagens não confirmadas enviadas para a réplica secundária. Até que algumas destas mensagens sejam reconhecidas, não podem ser enviados mais blocos de log para a réplica secundária. Esta situação pode ter um impacto mais sério na potencial perda de dados, podendo pôr em risco o objetivo do seu ponto de recuperação (RPO).
Diagnóstico e resolução
Um valor elevado de DMV log_send_queue_size pode indicar registos retidos na réplica principal. Dividir este valor por log_send_rate pode dar-lhe uma estimativa aproximada de quão rapidamente os dados podem ser recuperados na réplica secundária.
Também é útil verificar os dois objetos de desempenho SQL Server:Availability Replica > Flow Control Control Time (ms/sec) e SQL Server:Availability Replica > Flow control/seg. Multiplicar estes dois valores mostra-te, no último segundo, quanto tempo foi gasto à espera que o flow control fosse limpo. Quanto maior for o tempo de espera no controlo de fluxo, menor será a taxa de envio.
Segue-se uma lista de métricas úteis no diagnóstico da latência e do débito da rede. Pode usar outras ferramentas Windows, como oping.exe, para avaliar a utilização da rede.
DMV log_send_rate
Contador de desempenho
SQL Server:Database > Log Bytes Flushed/secContador de desempenho
SQL Server:Database Mirroring > Send/Receive Ack TimeContador de desempenho
SQL Server:Availability Replica > Bytes Sent to Replica/secContador de desempenho
SQL Server:Availability Replica > Bytes Sent to Transport/secContador de desempenho
SQL Server:Availability Replica > Flow Control Time (ms/sec)Contador de desempenho
SQL Server:Availability Replica > Flow Control/secContador de desempenho
SQL Server:Availability Replica > Resent Messages/sec
Para resolver este problema, experimente aumentar a largura de banda da sua rede ou remover ou reduzir o tráfego desnecessário.
Outra carga de trabalho de relatórios impede a execução da thread de redo
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. A thread de repetição tem de ser desbloqueada antes de poder disponibilizar mais atualizações para cargas de trabalho de leitura.
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.
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 carga de trabalho de relatório 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. Esta situação não só impede que outras cargas de trabalho de relatórios acedam a dados atualizados, como também afeta o RTO.
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.