Sintomas
Considere o seguinte cenário:
-
Você está usando o Microsoft SQL Server 2016, o 2014 ou o 2012.
-
Você tem um banco de dados que faz parte do grupo de disponibilidade AlwaysOn.
-
Na réplica primária, você reduz os arquivos de banco de dados para reduzir seu tamanho.
-
A réplica primária envia todas as alterações que são gravadas no log de transação para a réplica secundária.
-
Na réplica secundária, os threads de refazer aplicam as alterações do log de transação ao banco de dados que faz parte do grupo de disponibilidade.
Nesse cenário, a réplica está suspensa. Além disso, você pode receber uma mensagem de erro semelhante à seguinte:
<carimbo de data/hora> erro spid41s: 3456, severidade: 21, estado: 1. <carimbo de data/hora> spid41s não pôde refazer o registro de log (#), para a ID da transação (#), na página (#), o banco de dados ' <dbname> ' (ID do banco de dados #). Página: LSN = (#), unidade de alocação = #, digite = #. Log: OpCode = #, Context #, PrevPageLSN: (#). Restaurar a partir de um backup do banco de dados ou reparar o banco de dados. <carimbo de data/hora> spid41s o movimento dos dados de grupos de disponibilidade AlwaysOn para o banco de dados ' <dbname> ' foi suspenso pela seguinte razão: "sistema" (ID de fonte 2; Cadeia de caracteres de origem: ' SUSPEND_FROM_REDO '). Para retomar a movimentação de dados no banco de dados, será necessário retomar o banco de dados manualmente. Para obter informações sobre como retomar um banco de dados de disponibilidade, consulte Manuais Online do SQL Server. <carimbo de data/hora> erro spid41s: 3313, severidade: 21, estado: 2. <carimbo de data/hora> spid41s durante a reoperação de uma operação registrada no banco de dados ' <dbname> ', ocorreu um erro na ID do registro de log Geralmente, a falha específica é registrada anteriormente como um erro no serviço de log de eventos do Windows. Restaure o banco de dados a partir de um backup completo ou repare o banco de dados.
Causa
Esse problema ocorre quando as alterações são aplicadas durante o processo de refazer se o mecanismo de banco de dados encontra LSNs de fora da ordem nas páginas do sistema (GAM, PFS).
Resolução
O problema foi corrigido primeiro 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 incluídas na atualização cumulativa anterior. Recomendamos que você baixe e instale as atualizações cumulativas mais recentes do SQL Server:
A atualização impede que esse problema ocorra. Se o problema já ocorreu, siga estas etapas para reingressar no grupo de disponibilidade do AlwaysOn:
-
Remova a réplica secundária AlwaysOn existente.
-
Execute o seguinte comando nos arquivos de dados afetados para remover o espaço não alocado do banco de dados:
DBCC SHRINKFILE(<file_id>, TRUNCATEONLY)
-
Fazer backup do banco de dados e dos arquivos de log.
-
Restaure o banco de dados e os logs na réplica secundária AlwaysOn.
-
Ingresse no grupo de disponibilidade do AlwaysOn.
Status
A Microsoft confirmou que este é um problema nos produtos Microsoft listados na seção "Aplicável a".
Referências
Saiba mais sobre a terminologia que a Microsoft usa para descrever atualizações de software.
