Sintomas
Considere o seguinte cenário:
-
Está a utilizar o Microsoft SQL Server 2016, 2014 ou 2012.
-
Tem uma base de dados que faz parte do Grupo AlwaysOn Availability.
-
Na réplica primária, encolhe-se os ficheiros da base de dados para reduzir o seu tamanho.
-
A réplica primária envia todas as alterações registadas no registo de transações para a réplica secundária.
-
Na réplica secundária, os fios de redo aplicam as alterações do registo de transações para a base de dados que faz parte do grupo de disponibilidade.
Neste cenário, a réplica está suspensa. Além disso, poderá receber uma mensagem de erro que se assemelhe ao seguinte:
carimbo de tempo <> spid41s Erro: 3456, Severidade: 21, Estado: 1,<carimbo de tempo> spid41s Não podia refazer registo de registo (#), para iD de transação (#), na página (#), base de dados '<dbname>' (base de dados ID #). Página: LSN = (#), unidade de atribuição = #, tipo = #. Log: OpCode = #, context #, PrevPageLSN: (#). A partir de uma cópia de segurança da base de dados, ou reparação do carimbo de tempo <> spid41s AlwaysOn Availability Groups o movimento de dados para a base de dados '<dbname>' foi suspenso pelo seguinte motivo: "sistema" (ID fonte 2; Cadeia de origem: 'SUSPEND_FROM_REDO'). Para retomar o movimento de dados na base de dados, terá de retomar a base de dados manualmente. Para obter informações sobre como retomar uma base de dados de disponibilidade, consulte SQL Server Books Online.<carimbo de tempo> spid41s Error: 3313, Severity: 21, State: 2.<time stamp> spid41s Durante a refasamento de uma operação registada na base de dados '<dbname>', ocorreu um erro no registo de registo ID (#). Normalmente, a falha específica é previamente registada como um erro no serviço De Registo de Eventos do Windows. Restaurar a base de dados a partir de uma cópia de segurança completa, ou reparar a base de dados.
Causa
Este problema ocorre quando as alterações são aplicadas durante o processo de redo se o motor de base de dados encontrar LSNs fora de ordem nas páginas do sistema (GAM, PFS).
Resolução
O problema foi corrigido pela primeira vez na seguinte atualização cumulativa do SQL Server:
Cada nova atualização cumulativa do SQL Server contém todos os hotfixes e todas as correções de segurança que foram incluídas com a atualização cumulativa anterior. Recomendamos que descarregue e instale as últimas atualizações cumulativas para o SQL Server:
A atualização impede que este problema ocorra. Se o problema já tiver ocorrido, siga estes passos para voltar a integrar o Grupo AlwaysOn Availability:
-
Remova a réplica secundária AlwaysOn existente.
-
Executar o seguinte comando nos ficheiros de dados afetados para remover o espaço não atribuído da base de dados:
DBCC SHRINKFILE(<file_id>, TRUNCATEONLY)
-
Faça o registo da base de dados e faça login nos ficheiros.
-
Restaurar a base de dados e os registos na réplica secundária AlwaysOn.
-
Junte-se ao Grupo Disponibilidade AlwaysOn.
Estado
A Microsoft confirmou que este problema ocorre nos produtos da Microsoft listados na secção "Aplica-se a".
Referências
Conheça a terminologia que a Microsoft utiliza para descrever atualizações de software.
