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:

  1. Remova a réplica secundária AlwaysOn existente.

  2. 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)

  3. Fazer backup do banco de dados e dos arquivos de log.

  4. Restaure o banco de dados e os logs na réplica secundária AlwaysOn.

  5. 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.

Precisa de mais ajuda?

Expanda suas habilidades
Explore o treinamento
Obtenha novos recursos primeiro
Ingressar no Microsoft Insider

Estas informações foram úteis?

Qual é o seu grau de satisfação com a qualidade da tradução?
O que afetou sua experiência?

Obrigado por seus comentários!

×