Nota
Depois de aplicar esse hotfix, você deve habilitar o sinalizador de rastreamento 1800 como um parâmetro de inicialização em todos os servidores ou réplicas que têm 512 bytes de tamanho de setor físico e reiniciá-los, para fazer esse hotfix funcionar corretamente.
Sintomas
Tenha em conta o seguinte cenário:
Ativa a funcionalidade AlwaysOn Availability Groups ou Logshipping no Microsoft SQL Server.
Os discos que armazenam os arquivos de log da réplica primária e secundária em um Grupo de Disponibilidade AlwaysOn (AG) têm tamanhos de setor diferentes. Ou, em ambientes de Logshipping, os discos que armazenam os arquivos de log para servidores primários Logshipping e servidores secundários Logshipping têm tamanhos de setor diferentes. Por exemplo:
- O arquivo de log de réplica primário está localizado em um disco que tem um tamanho de setor de 512 bytes. No entanto, o arquivo de log de réplica secundário está localizado em um disco que tem o tamanho de setor de 4 kilobytes (KB).
- O arquivo de log de réplica primário está localizado em um sistema local local que tem um tamanho de setor de 512 bytes. No entanto, a réplica secundária está localizada em um disco de armazenamento do Windows Azure que tem o tamanho de setor de 4 kilobytes (KB).
Nesse cenário, a seguinte mensagem de erro é registrada no SQL Server Log de erros. 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.
Nota
Houve X de E/S de log desalinhadas que exigiram retornar à E/S síncrona. O IO atual está no arquivo ....
Além disso, a sincronização AG ou Logshipping é executada muito lentamente devido ao E/S síncrono. Se a réplica secundária estiver no Windows Armazenamento do 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 o tamanho do setor 4K e SQL Server – espaços de armazenamento/VHDx e tamanho do setor 4K.
Resolução
O problema foi corrigido na atualização cumulativa seguinte do SQL Server.
Atualização cumulativa 5 para SQL Server 2014 /pt-pt/help/3011055
Atualização Cumulativa 3 para SQL Server 2012 SP2 /en-us/help/3002049
Atualização Cumulativa 13 para SQL Server 2012 SP1 /en-us/help/3002044
Depois de aplicar o hotfix e habilitar o sinalizador de rastreamento 1800 como um parâmetro de inicialização em todas as réplicas de servidores em execução em um disco que tem um tamanho de setor de 512 bytes, você observa um pequeno aumento no tamanho dos seguintes arquivos:
- Ficheiro de registo de transações
- Fazer cópias de segurança de registos
Além disso, você observa que as seguintes mensagens são registradas no log de erros de SQL Server do servidor primário:
Nota
A cauda do log para o banco de dados '<nome >do banco de dados' está sendo reescrita para corresponder ao novo tamanho do setor de 4096 bytes
Esta é uma mensagem informativa que pode ser ignorada com segurança.
Acerca das atualizações cumulativas para SQL Server
Cada nova atualização cumulativa para 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. Consulte as atualizações cumulativas mais recentes para SQL Server:
- Atualização cumulativa mais recente para o SQL Server 2014
- Atualização cumulativa mais recente para o SQL Server 2012 SP2
- Atualização cumulativa mais recente para o SQL Server 2012 SP1
Solução
Para contornar esse problema, mova o arquivo de log de transações no destino para uma unidade que tenha Bytes por setor físico definido como 512 bytes.
Estado
A Microsoft confirmou que se trata de um problema nos produtos Microsoft listados na secção "Aplica-se a".
Mais Informações
Como prática recomendada, tente certificar-se de que todos os discos em todas as réplicas (pelo menos todos os discos que hospedam arquivos de log) tenham o mesmo tamanho de setor. Em ambientes mistos, onde 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 que tenham 512 bytes de tamanho de setor físico e sejam reiniciados. Isso garante que o formato de criação de log contínuo use um tamanho de setor de 4 KB.
Para obter mais informações sobre como o SQL Server funciona com setores maiores, consulte a seguinte mensagem 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 de 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 982018 da KB .
Para verificar o tipo de unidade que possui, siga estes passos:
Execute o seguinte comando numa linha de comandos elevada:
Fsutil fsinfo ntfsinfo x: Observação O espaço reservado x representa a unidade que você está verificando.Use os valores de Bytes por setor e Bytes por setor físico para determinar o tipo de unidade que você tem. Para tal, utilize a tabela seguinte:
Valor "bytes por setor" Valor "Bytes por Setor Físico" Tipo de unidade 4096 4096 4K nativo 512 4096 Formato Avançado (também conhecido como 512E) 512 512 Nativo de 512 bytes