Em minha postagem anterior sobre como simplificar as operações do log de transações, discuti duas das causas mais comuns de geração de registros de log extra:peso morto de índices não clusterizados não utilizados e operações de divisão de página (que causam fragmentação do índice). Supondo que você tenha lido esse post, mencionei que há problemas mais sutis que podem prejudicar o desempenho do log de transações, e vou abordá-los aqui.
Muitas, muitas pequenas transações
De vez em quando, o SQL Server libera uma parte do log de transações para o disco. Uma liberação de log ocorre sempre que:
- Um registro de log de confirmação de transação é gerado.
- Um registro de log de interrupção de transação é gerado no final de uma reversão de transação.
- 60 KB de registros de log foram gerados desde a liberação de log anterior.
A menor liberação de log possível é um único bloco de log de 512 bytes. Se todas as transações em uma carga de trabalho forem muito pequenas (por exemplo, inserir uma única linha de tabela pequena), haverá muitos fluxos de log de tamanho mínimo ocorrendo. As liberações de log são executadas de forma assíncrona, para permitir uma taxa de transferência de log de transações decente, mas há um limite fixo de 32 E/Ss de liberação de log simultâneas a qualquer momento (aumentado para 112 no SQL Server 2012).
Existem dois efeitos possíveis que isso pode ter:
- Em um subsistema de E/S de desempenho lento, o volume de pequenas gravações de log de transações pode sobrecarregar o subsistema de E/S, levando a gravações de alta latência e degradação subsequente da taxa de transferência do log de transações. Essa situação pode ser identificada por latências de alta gravação para o arquivo de log de transações na saída de sys.dm_io_virtual_file_stats (veja os links de demonstração na parte superior da postagem anterior)
- Em um subsistema de E/S de alto desempenho, as gravações podem ser concluídas com extrema rapidez, mas o limite de 32 E/Ss de liberação de log simultâneas cria um gargalo ao tentar tornar os registros de log duráveis no disco. Essa situação pode ser identificada por baixas latências de gravação e um número quase constante de gravações de log de transações pendentes próximo a 32 na saída agregada de sys.dm_io_pending_io_requests (consulte os mesmos links de demonstração).
Em ambos os casos, tornar as transações mais longas (o que é muito contra-intuitivo!) pode reduzir a frequência de liberações do log de transações e aumentar o desempenho. Além disso, no caso nº 1, mudar para um subsistema de E/S de alto desempenho pode ajudar – mas pode levar ao caso nº 2. Com o caso 2, se as transações não puderem ser feitas mais longas, a única alternativa é dividir a carga de trabalho em vários bancos de dados para contornar o limite fixo de 32 E/Ss de liberação de log simultâneas ou atualizar para o SQL Server 2012 ou superior.
Aumento automático do registro de transações
Sempre que um novo espaço é adicionado ao log de transações, ele deve ser inicializado com zero (escrevendo zeros para substituir o uso anterior dessa parte do disco), independentemente de o recurso de inicialização instantânea de arquivo estar ativado ou não. Isso se aplica à criação, crescimento manual e crescimento automático do log de transações. Enquanto a inicialização zero está ocorrendo, os registros de log não podem ser liberados para o log, portanto, o crescimento automático durante uma carga de trabalho que está alterando dados pode levar a uma queda notável na taxa de transferência, especialmente se o tamanho do crescimento automático estiver definido como grande ( diga gigabytes, ou deixados nos 10% padrão.
O crescimento automático deve ser evitado, se possível, permitindo que o log de transações seja limpo para que sempre haja espaço livre que possa ser reutilizado para novos registros de log. A limpeza do log de transações (também conhecida como truncamento do log de transações, que não deve ser confundida com a redução do log de transações) é realizada por backups de logs de transações ao usar os modos de recuperação Completo ou Bulk-Logged e por pontos de verificação ao usar o modo de recuperação Simples.
A limpeza de log só pode ocorrer se nada exigir que os registros de log na seção do log de transações sejam apagados. Um problema comum que impede a limpeza de log é ter transações de longa duração. Até que uma transação seja confirmada ou revertida, todos os registros de log desde o início da transação em diante são necessários caso a transação seja revertida – incluindo todos os registros de log de outras transações intercalados com os da transação de longa duração. As transações de longa duração podem ser devido a um design ruim, código que está aguardando entrada humana ou uso inadequado de transações aninhadas, por exemplo. Tudo isso pode ser evitado quando identificado como um problema.
Você pode ler mais sobre isso aqui e aqui.
Recursos de alta disponibilidade
Alguns recursos de alta disponibilidade também podem atrasar a limpeza do log de transações:
- O espelhamento de banco de dados e grupos de disponibilidade ao serem executados de forma assíncrona podem criar uma fila de registros de log que ainda não foram enviados para a cópia do banco de dados redundante. Esses registros de log devem ser mantidos até serem enviados, atrasando a limpeza do log de transações.
- A replicação transacional (e também o Change Data Capture) depende de um trabalho do Log Reader Agent para verificar periodicamente o log de transações em busca de transações que modificam uma tabela contida em uma publicação de replicação. Se o Log Reader Agent ficar para trás por qualquer motivo, ou for feito intencionalmente para ser executado com pouca frequência, todos os registros de log que não foram verificados pelo trabalho devem ser mantidos, atrasando a limpeza do log de transações.
Ao executar no modo síncrono, o espelhamento de banco de dados e os grupos de disponibilidade podem causar outros problemas com o mecanismo de log. Usando o espelhamento de banco de dados síncrono como exemplo, qualquer transação confirmada no principal não pode retornar ao usuário ou aplicativo até que todos os registros de log gerados sejam enviados com êxito ao servidor espelho, adicionando um atraso de confirmação no principal. Se o tamanho médio da transação for longo e o atraso for curto, isso pode não ser perceptível, mas se a transação média for muito curta e o atraso for bastante longo, isso poderá ter um efeito perceptível na taxa de transferência da carga de trabalho. Nesse caso, as metas de desempenho da carga de trabalho precisam ser alteradas, a tecnologia de alta disponibilidade alterada para o modo assíncrono ou a largura de banda da rede e a velocidade entre os bancos de dados principal e redundante devem ser aumentadas.
Aliás, o mesmo tipo de problema pode ocorrer se o próprio subsistema de E/S for espelhado de forma síncrona – com um atraso potencial para todas as gravações que o SQL Server executa.
Resumo
Como você pode ver, o desempenho do log de transações não é apenas sobre a geração de registros extras de log de transações – há muitos fatores ambientais que também podem ter um efeito profundo.
A conclusão é que a integridade e o desempenho do log de transações são de suma importância para manter o desempenho geral da carga de trabalho. Nestes dois posts, detalhei as principais causas dos problemas de desempenho do log de transações, então espero que você consiga identificar e corrigir qualquer um que tenha.
Se você quiser aprender muito mais sobre operações de log de transações e ajuste de desempenho, recomendo que você confira meu curso de treinamento online de 7,5 horas sobre log, recuperação e log de transações, disponível no Pluralsight.
