Recentemente configuramos a feature “Always On: Availability Groups” em um ambiente Microsoft SQL Server 2017 no Windows Server. Ao realizar a configuração, nos deparamos com a ocorrência da seguinte mensagem no errorlog do SQL Server:
“There have been X misaligned log IOs which required falling back to synchronous IO. The current IO is on file xxx”
Ao realizar o troubleshooting, descobrimos que este problema impacta em operações de E/S dos arquivos de log, aumentando seu tempo de sincronismo. Pode causar inclusive situações mais sérias, como a perda do sincronismo e/ou inviabilizar o uso do modo síncrono.
Este problema ocorre em cenários onde os discos que armazenam os arquivos de log da réplica primária e secundária possuem tamanhos de setor diferentes; por exemplo, quando temos o arquivo de log da réplica primária localizado em um disco com tamanho de setor de 512 bytes enquanto na réplica secundária está localizado em um disco que tem tamanho de setor de 4096 bytes. Também ocorre na situação inversa.
A recomendação da Microsoft para esse tipo de cenário é usar discos com mesmo tamanho de setor físico (pelo menos para armazenar os arquivos de log), porém nem sempre isto é possível, principalmente quando lidamos com ambientes híbridos (on premises + cloud).
Para confirmarmos se o ambiente segue o cenário acima, é necessário descobrir qual o tamanho setores dos discos. Para isso, é possível executar o utilitário fsutil da seguinte forma:
fsutil fsinfo ntfsinfo [seu disco] (Dica: abra o prompt de comando como administrador)
O retorno será algo desse tipo:
A informação que estamos buscando está destacada na imagem. No exemplo acima, o disco tem setores físicos com tamanho de 512 bytes (Bytes Per Physical Sector). O problema que estamos descrevendo ocorre justamente quando há diferença no tamanho dos setores físicos entre os discos que armazenam os arquivos de log nos servidores que contêm réplicas primárias e secundárias. Então, devemos executar esse mesmo comando em cada servidor que irá armazenar réplicas (primárias ou secundárias), verificando sempre o disco que irá armazenar os arquivos de log e comparando-o com os demais discos.
Ao nos depararmos com esta situação, descobrimos a existência de um Trace Flag para “corrigir” esse problema. A Trace Flag 1800. De acordo com a documentação oficial da Microsoft, este Trace Flag é descrito como:
“Permite a otimização do SQL Server quando discos de diferentes tamanhos de setor são usados para arquivos de log de réplica primária e secundária, nos ambientes Always On e de envio de logs do SQL Server. Este sinalizador de rastreamento só precisa ser habilitado em instâncias do SQL Server que tenham o arquivo de log de transações residindo no disco, com um tamanho de setor de 512 bytes. Ele não precisa ser habilitado para discos com tamanhos de setor de 4 mil. Para obter mais informações, confira este artigo do Suporte da Microsoft (https://support.microsoft.com/kb/3009974).
Observação: esse sinalizador de rastreamento se aplica a SQL Server 2012 (11.x) SP1 CU13, SQL Server 2012 (11.x) SP2 CU3, SQL Server 2014 (12.x) RTM CU5 e builds superiores.
Escopo: apenas global”
Habilitamos esse Trace Flag no ambiente que estávamos analisando, de acordo com a recomendação da Microsoft, e o problema foi corrigido.
É importante lembrar que para habilitar esse Trace Flag, deve-se colocá-lo como parâmetro de inicialização do serviço do MSSQL, conforme imagem abaixo:
Observação: Habilitamos este Trace Flag apenas no servidor que estava com tamanho de setor físico de 512 bytes, conforme recomendação da Microsoft.
De acordo com a Microsoft, esta mesma situação pode ocorrer em um ambiente com a feature Log Shipping.
Links úteis:
