Nos meus dois últimos posts, discuti maneiras de reduzir a quantidade de log de transações sendo gerado e como garantir que o log de transações sempre possa ser limpo corretamente. Neste post, quero continuar com o tema de desempenho do log de transações e discutir alguns problemas de configuração do log de transações que podem causar problemas.
Muitos VLFs
O log de transações é dividido em partes chamadas de arquivos de log virtuais (VLFs) para que o sistema de gerenciamento de logs possa acompanhar facilmente quais partes do log de transações estão disponíveis para reutilização. Existe uma fórmula para quantos VLFs você obtém quando cria seu log de transações, aumenta-o manualmente ou aumenta automaticamente:
| Até 1 MB | 2 VLFs, cada um com aproximadamente 1/2 do tamanho total |
|---|---|
| 1 MB a 64 MB | 4 VLFs, cada um com aproximadamente 1/4 do tamanho total |
| 64 MB a 1 GB | 8 VLFs, cada um com aproximadamente 1/8 do tamanho total |
| Mais de 1 GB | 16 VLFs, cada um com aproximadamente 1/16 do tamanho total |
Por exemplo, se você criar um log de transações com 8 GB, obterá 16 VLFs, cada um com aproximadamente 512 MB. Se você aumentar o log em mais 4 GB, obterá 16 VLFs adicionais, cada um com aproximadamente 256 MB, para um total de 32 VLFs.
Observação:esse algoritmo mudou um pouco para o SQL Server 2014 para aliviar os problemas de fragmentação do VLF – consulte esta postagem do blog para obter detalhes
Uma prática recomendada geral é definir o crescimento automático de log para algo diferente do padrão de 10%, para que você possa controlar a pausa necessária ao inicializar zero novo espaço de log de transações. Digamos que você crie um log de transações de 256 MB e defina o crescimento automático para 32 MB e, em seguida, o log cresce para um tamanho estável de 16 GB. Dada a fórmula acima, isso resultará em seu log de transações com mais de 2.000 VLFs.
Esses muitos VLFs provavelmente resultarão em alguns problemas de desempenho para operações que processam o log de transações (por exemplo, recuperação de falhas, limpeza de log, backups de log, replicação transacional, restaurações de banco de dados). Essa situação é chamada de fragmentação VLF. Geralmente, qualquer número de VLFs acima de mil ou mais será problemático e precisa ser resolvido (o máximo que já ouvi é 1,54 milhão de VLFs em um log de transações com mais de 1 TB de tamanho!).
A maneira de saber quantos VLFs você tem é usar o
DBCC LOGINFO não documentado (e completamente seguro) comando. O número de linhas de saída é o número de VLFs em seu log de transações. Se você acha que tem muitos, a maneira de reduzi-los é:- Permitir que o registro seja limpo
- Reduza o registro manualmente
- Repita as etapas 1 e 2 até que o log atinja um tamanho pequeno (o que pode ser complicado em um sistema de produção ocupado)
- Aumente o log manualmente para o tamanho que deveria ter, em etapas de até 8 GB, para que cada VLF não seja maior que 0,5 GB
Você pode ler mais sobre problemas de fragmentação de VLF e o processo para corrigi-los em:
- Artigo da base de conhecimento da Microsoft que aconselha a redução dos números de VLF
- O crescimento dos arquivos de log pode afetar o DML?
- 8 etapas para melhorar a taxa de transferência do log de transações
Tempdb
O Tempdb precisa ter seu log de transações configurado como qualquer outro banco de dados e pode crescer como qualquer outro banco de dados. Mas também tem um comportamento insidioso que pode causar problemas.
Quando uma instância do SQL Server é reiniciada por qualquer motivo, os dados e os arquivos de log do tempdb serão revertidos para o tamanho para o qual foram definidos mais recentemente. Isso é diferente de todos os outros bancos de dados, que permanecem em seu tamanho atual após a reinicialização de uma instância.
Esse comportamento significa que se o log de transações tempdb cresceu para acomodar a carga de trabalho normal, você deve executar um
ALTER DATABASE para definir o tamanho do arquivo de log, caso contrário, seu tamanho diminuirá após a reinicialização de uma instância e terá que crescer novamente. Toda vez que um arquivo de log cresce ou cresce automaticamente, o novo espaço deve ser inicializado em zero e a atividade de log é pausada enquanto isso é feito. Portanto, se você não gerenciar o tamanho do arquivo de log tempdb corretamente, pagará uma penalidade de desempenho à medida que ele aumentar após cada reinicialização da instância. Redução regular do arquivo de log
Muitas vezes, ouço pessoas dizendo como elas geralmente reduzem o log de transações de um banco de dados depois que ele cresce a partir de uma operação regular (por exemplo, uma importação de dados semanal). Isso não é uma boa coisa a fazer.
Assim como expliquei acima, sempre que o log de transações cresce ou cresce automaticamente, há uma pausa enquanto a nova parte do arquivo de log é inicializada com zero. Se você está reduzindo regularmente o log de transações porque ele cresce para o tamanho X, isso significa que você está sofrendo regularmente com problemas de desempenho à medida que o log de transações volta a crescer automaticamente para o tamanho X.
Se o seu log de transações continuar crescendo até o tamanho X, deixe-o em paz! Configure-o proativamente para o tamanho X, gerenciando seus VLFs conforme expliquei acima e aceite o tamanho X como o tamanho necessário para sua carga de trabalho normal. Um log de transações maior não é um problema.
Vários arquivos de registro
Não há ganho de desempenho com a criação de vários arquivos de log para um banco de dados. A adição de um segundo arquivo de log pode ser necessária, no entanto, se o arquivo de log existente ficar sem espaço e você não estiver disposto a forçar a limpeza do log de transações alternando para o modelo de recuperação simples e executando um ponto de verificação (pois isso interrompe o backup de log cadeia).
Muitas vezes me perguntam se há algum motivo urgente para remover o segundo arquivo de log ou se não há problema em deixá-lo no lugar. A resposta é que você deve removê-lo o mais rápido possível.
Embora o segundo arquivo de log não cause problemas de desempenho para sua carga de trabalho, ele afeta a recuperação de desastres. Se seu banco de dados for destruído por algum motivo, você precisará restaurá-lo do zero. A primeira fase de qualquer sequência de restauração é criar os dados e os arquivos de log, caso eles não existam.
Você pode tornar a criação do arquivo de dados quase instantânea habilitando a inicialização instantânea do arquivo que ignora a inicialização zero, mas que não se aplica aos arquivos de log. Isso significa que a restauração precisa criar todos os arquivos de log que existiam quando o backup completo foi feito (ou são criados durante o período coberto por um backup de log de transações) e inicializá-los. Se criou um segundo arquivo de log e esqueceu de descartá-lo novamente, inicializá-lo com zero durante uma operação de recuperação de desastres aumentará o tempo de inatividade total. Este não é um problema de desempenho da carga de trabalho, mas afeta a disponibilidade do servidor como um todo.
Revertendo de um instantâneo de banco de dados
O problema final na minha lista é, na verdade, um bug no SQL Server. Se você usar um instantâneo de banco de dados como uma forma de recuperar rapidamente para um ponto no tempo conhecido sem precisar restaurar backups (conhecido como reversão do instantâneo), poderá economizar muito tempo. No entanto, há uma grande desvantagem.
Quando o banco de dados é revertido do instantâneo do banco de dados, o log de transações é recriado com dois VLFs de 0,25 MB. Isso significa que você terá que aumentar seu log de transações de volta ao tamanho e número ideais de VLFs (ou ele crescerá automaticamente), com todas as pausas de inicialização zero e de carga de trabalho que discuti anteriormente. Claramente não é o comportamento desejado.
Resumo
Como você pode ver neste post e nos meus dois posts anteriores, há muitas coisas que podem levar a um desempenho ruim do log de transações, o que tem um efeito indireto no desempenho de sua carga de trabalho geral.
Se você puder cuidar de todas essas coisas, terá logs de transações saudáveis. Mas não termina aí, pois você precisa ter certeza de que está monitorando seus logs de transações para ser alertado sobre coisas como crescimento automático e latências excessivas de E/S de leitura e gravação. Vou abordar como fazer isso em um post futuro.
