KB3009974 - CORREção: sincronização lenta quando os discos têm tamanhos de setor diferentes para arquivos de log de réplica primários e secundários em ambientes ag e logshipping SQL Server

Sintomas

Considere o seguinte cenário:

• Você habilita o recurso Grupos de Disponibilidade AlwaysOn ou Logshipping no Microsoft SQL Server.

• Os discos que armazenam os arquivos de log do réplica primário e secundário em um AG (Grupo de Disponibilidade AlwaysOn) têm tamanhos de setor diferentes. Ou em ambientes de logshipping, os discos que armazenam os arquivos de log para servidores primários do Logshipping e servidores secundários do Logshipping têm tamanhos de setor diferentes. Por exemplo:

  • O arquivo de log principal réplica está localizado em um disco que tem um tamanho de setor de 512 bytes. No entanto, o arquivo de log secundário réplica está localizado em um disco que tem o tamanho do setor de 4 quilobytes (KB).

  • O arquivo de log principal réplica está localizado em um sistema local que tem um tamanho de setor de 512 bytes. No entanto, o réplica secundário está localizado em um disco de Armazenamento do Windows Azure que tem o tamanho do setor de 4 quilobytes (KB).

Nesse cenário, a seguinte mensagem de erro é registrada no log de erros SQL Server. A mensagem de erro pode continuar por um tempo depois de reiniciar se houver logs que não foram aplicados ao secundário antes de reiniciar o servidor.

Além disso, a sincronização de AG ou Logshipping é executada muito lentamente devido à E/Síncrona. Se o réplica secundário estiver no Armazenamento do Windows Azure, levará muito mais tempo do que o esperado para concluir o processo de sincronização.

Observação Esse problema ocorre quando você usa as novas unidades que têm um tamanho de setor de 4 KB e as unidades antigas que têm um tamanho de setor de 512 bytes. Para obter mais informações sobre as novas unidades, consulte SQL Server – Novas unidades Use tamanho do setor 4K e SQL Server-Espaços de armazenamento/VHDx e tamanho do setor 4K.

Resolução

O problema foi corrigido pela primeira vez na atualização cumulativa a seguir de SQL Server.

Solução alternativa

Para contornar esse problema, mova o arquivo de log de transações no destino para uma unidade que tem Bytes por Setor Físico definido como 512 bytes.

Status

A Microsoft confirmou que este é um problema nos produtos Microsoft listados na seção "Aplicável a".

Informações adicionais

Como prática recomendada, tente garantir que todos os discos em todas as réplicas (pelo menos todos os discos que hospedam arquivos de log) tenham o mesmo tamanho do setor. Em ambientes mistos, em que o secundário tem um setor físico de 512 bytes e o primário tem um tamanho de setor de 4 KB, o TF 1800 deve ser usado como um sinalizador de inicialização em todos os servidores ou réplicas com tamanho do setor físico de 512 bytes e reiniciado. Isso garante que o formato de criação de log em andamento use um tamanho do setor de 4 KB.

Para obter mais informações sobre como SQL Server funciona com tamanhos maiores do setor, confira a seguinte postagem no blog de suporte:

SQL Server-Espaços de armazenamento/VHDx e tamanho

do setor 4K Você pode usar o utilitário de prompt de comando Fsutil para determinar o valor Bytes por Setor Físico. Se esse parâmetro não estiver visível na saída, você deverá aplicar o hotfix especificado no artigo do KB 982018.

Para verificar o tipo de unidade que você tem, siga estas etapas:

1. Execute o seguinte comando em um prompt de comando elevado:

   Fsutil fsinfo ntfsinfo x: Observação O espaço reservado x representa a unidade que você está verificando.

2. Use os valores de Bytes por Setor e Bytes por Setor Físico para determinar o tipo de unidade que você tem. Para fazer isso, use a seguinte tabela:

   Valor "Bytes por Setor"	Valor "Bytes por Setor Físico"	Tipo de unidade
   4096	4096	Nativo de 4K
   512	4096	Formato Avançado (também conhecido como 512E)
   512	512	Nativo de 512 bytes