Compartilhar via

A restauração de um banco de dados do SQL Server usando um aplicativo VDI com distribuição múltipla pode falhar com o erro 3456

  • Artigo

Este artigo ajuda você a resolver um problema que ocorre quando você usa aplicativos baseados em VDI (Interface de Dispositivo Virtual) para restaurar seus bancos de dados do SQL Server.

Sintomas

Ao restaurar um backup completo da VDI (interface de dispositivo virtual) com várias faixas no SQL Server 2019 ou posterior, você pode receber o erro MSSQLSERVER_3456:

Msg 3456, Level 16, State 1, Line <LineNumber>
Could not redo log record (120600:18965748:1), for transaction ID (0:1527178398), on page (14:1987189), allocation unit 72057761533001728, database 'DB1_STRIPE' (database ID 8).
Page: LSN = (120598:23255372:8), allocation unit = 72057761317781504, type = 1. Log: OpCode = 6, context 2, PrevPageLSN: (120600:18965371:85).

Motivo

Quando o SQL Server faz backup na VDI, ele passa dados para a VDI por meio de um buffer. Em seguida, a VDI lida com a formatação de como armazenar esse backup. No entanto, em muitos casos, o cliente VDI pode esperar apenas uma única cópia de cada página de dados.

Quando você distribui um backup para VDI, vários dispositivos de backup juntos compõem o conteúdo de um backup completo. Os dados são gravados de forma assíncrona e a ordenação da cópia de dados é tratada pela lógica do cliente VDI. Como a fase de cópia de dados é assíncrona, os dados podem ser gravados fora de ordem. No entanto, em um cenário de backup completo antes do SQL Server 2019, há apenas uma cópia por página de dados. Portanto, quando o cliente VDI envia dados para o buffer do qual o SQL Server lê para uma restauração, o SQL Server ainda poderá saber exatamente onde e como restaurar cada página de dados. Com a introdução da fixação de log atrasada no SQL Server 2019, várias cópias da página de dados podem ser encontradas nos arquivos de backup. Existem várias cópias devido a um mini backup diferencial acontecendo dentro do backup completo (consulte a seção Mais informações para obter detalhes). O cliente VDI não está esperando várias cópias da mesma página de dados ou passando as páginas de dados de volta para o SQL Server na ordem errada. Esse comportamento causa a falha de restauração. O erro 3456 Could not redo log record indica que o SQL Server tenta aplicar um registro de log que espera a versão mais recente da página de dados, mas encontra uma versão mais antiga.

Resolução

  1. Dependendo da configuração, você precisa habilitar um ou mais sinalizadores de rastreamento como parâmetros de inicialização para sua instância do SQL Server:

    • Se você estiver fazendo backups completos quando a instância estiver atuando como uma réplica primária ou uma instância sem grupos de disponibilidade, habilite o sinalizador de rastreamento 3471 para desabilitar o recurso de fixação de log atrasado para backups completos.

    • Se você estiver fazendo backups diferenciais quando a instância estiver atuando como uma réplica primária ou uma instância sem grupos de disponibilidade, habilite o sinalizador de rastreamento 3475 para desabilitar o recurso de fixação de log atrasado para backups diferenciais.

    • Se você estiver fazendo backups completos com COPY_ONLY quando a instância estiver atuando como uma réplica secundária, habilite o sinalizador de rastreamento 3472 para desabilitar o recurso de fixação de log atrasado para backups diferenciais.

  2. Reinicie o SQL Server.

  3. Faça seus backups completos ou diferenciais novamente.

Observação

Você também pode habilitar temporariamente esses sinalizadores de rastreamento usando o comando DBCC TRACEON .

DBCC TRACEON(3471,3472,3475,-1)

Esse comando pode ser usado para atenuar o problema se você não puder reiniciar sua instância do SQL Server imediatamente.

Importante

Devido a esse problema, os backups existentes podem não ser restauráveis se as seguintes condições forem verdadeiras:

  • O backup é feito com o recurso de fixação de log de atraso ativado.
  • A ferramenta de backup está usando VDI.
  • O backup é feito usando multi-striping (backup em vários arquivos).

Recomendamos que você restaure seus backups existentes em um servidor de teste para verificar se eles podem ser restaurados com êxito.

Mais informações

O SQL Server 2019 apresenta um recurso chamado fixação de log atrasado. Antes da introdução desse recurso, durante um backup completo do banco de dados, o SQL Server bloqueia a ocorrência de qualquer transação (fixa o log), copia os dados e o log e remove o pin logo no início. Com o recurso presente, o SQL Server atrasa a ocorrência de transações (fixa o log) no final da duração do backup, em vez de logo no início. Esse recurso foi projetado para evitar um problema de log de transações completo (erro MSSQLSERVER_9002 ) durante um backup completo que está demorando muito para ser concluído. Como a fixação de log está atrasada, as transações ainda podem ser aplicadas às páginas de dados do banco de dados enquanto o backup está em andamento. O SQL Server mantém um bitmap para identificar as páginas que foram alteradas desde a hora de início do backup completo em andamento, para que ele possa fazer um mini backup diferencial delas. Dessa forma, ele obtém uma cópia atualizada de cada página de dados que foi alterada durante o backup de todo o banco de dados. Isso causa uma cópia extra de algumas páginas de dados. Além disso, essa seção extra do backup completo é criada.