Database
 sql >> Base de Dados >  >> RDS >> Database

Monitoramento de log de transações


Ao longo do ano passado, escrevi várias vezes no SQLPerformance.com sobre problemas de desempenho do log de transações (veja aqui) e prometi discutir o monitoramento do log de transações, o que farei neste post. Vou apresentar algumas das métricas que você pode acompanhar, por que você deve se importar e qualquer conselho para lidar com o problema indicado.

Detrancas


A maneira mais fácil de monitorar as latências de E/S do log de transações é usar o sys.dm_io_virtual_file_stats DMV. Você precisará realizar algumas contas para obter resultados úteis e pode obter algum código de exemplo no script VirtualFileStats.sql neste arquivo zip de demonstração. Você realmente deseja ver latências de gravação inferiores a 5 ms para o log de transações.

No início de novembro, publiquei no blog os resultados de uma pesquisa mostrando latências de log de transações e arquivos de dados tempdb para mais de 25.000 bancos de dados em todo o mundo (veja aqui), com 80% dos bancos de dados atingindo a marca de 5 ms ou menos para latência de gravação de log de transações.

Se a latência de gravação for superior a 5 ms, você poderá:
  • Trabalhe para reduzir a quantidade de logs gerados e/ou a quantidade de liberações de logs que ocorrem em pequenas transações, conforme descrevi em posts anteriores.
  • Siga algumas das etapas de solução de problemas que descrevo na postagem do blog da pesquisa acima.
  • Mude para um subsistema de E/S mais rápido, lembrando que, se você decidir usar um SSD, precisará usar dois em uma configuração RAID-1.

Outra coisa que você pode observar é se certificar de que não está atingindo o limite rígido de 32 E/Ss de gravação pendentes para o log de transações de cada banco de dados em 2008 R2 e antes (aumentado para 2012 a partir do SQL Server 2012 em diante). Você pode tentar fazer isso olhando para o Physical Disk/Avg. Comprimento da fila de gravação do disco, mas isso é para um volume inteiro, não por arquivo, portanto, se houver mais alguma coisa no volume além do arquivo de log em que você está interessado, isso não fornecerá um número válido. Uma maneira melhor é agregar os resultados do sys.dm_io_pending_io_requests DMV, que lista todas as E/Ss pendentes. Aqui está algum código para fazer isso:
SELECT
	COUNT (*) AS [PendingIOs],
	DB_NAME ([vfs].[database_id]) AS [DBName],
	[mf].[name] AS [FileName],
	[mf].[type_desc] AS [FileType],
	SUM ([pior].[io_pending_ms_ticks]) AS [TotalStall]
FROM sys.dm_io_pending_io_requests AS [pior]
JOIN sys.dm_io_virtual_file_stats (NULL, NULL) AS [vfs]
	ON [vfs].[file_handle] = [pior].[io_handle]
JOIN sys.master_files AS [mf]
	ON [mf].[database_id] = [vfs].[database_id]
	AND [mf].[file_id] = [vfs].[file_id]
WHERE
   [pior].[io_pending] = 1
GROUP BY [vfs].[database_id], [mf].[name], [mf].[type_desc]
ORDER BY [vfs].[database_id], [mf].[name];

Você pode modificar isso facilmente para exibir apenas os resultados dos arquivos de log (filtro em type_desc ='LOG' ) e apenas para o ID do banco de dados em que você está interessado.

Se você achar que está atingindo o limite de 32 para um banco de dados específico, você pode:
  • Reduza a quantidade de liberações de log que ocorrem reduzindo o número de pequenas transações e observando coisas como divisões de página e índices não utilizados/duplicados sendo alterados durante as operações de modificação de dados. Você pode ler mais sobre como otimizar a liberação de logs nesta postagem do blog
  • Tente usar um subsistema de E/S mais rápido
  • Atualize para o SQL Server 2012 ou superior, onde o limite é 112
  • Experimente o delayed durability feature DMV que foi adicionado no SQL Server 2014
  • Como último recurso, divida a carga de trabalho em vários bancos de dados ou servidores

Se você estiver interessado em ver quanto log de transações está sendo gerado por suas transações, você pode usar o sys.dm_tran_database_transactions DMV, em código semelhante ao abaixo:
BEGIN TRAN;
GO
 
-- Do something you want to evaluate
GO 
 
SELECT [database_transaction_log_bytes_used]
FROM sys.dm_tran_database_transactions
WHERE [database_id] = DB_ID (N'YourTestDB');
GO

Você pode se surpreender com a quantidade de log que está sendo gerada, especialmente em tempdb para código que faz uso de objetos temporários. E, claro, o log de transações do tempdb pode ser um gargalo, assim como para um banco de dados de usuário.

Contadores do Monitor de Desempenho


Os contadores de desempenho relacionados ao log estão todos no objeto de desempenho Bancos de Dados. Aqui estão alguns dos principais a serem observados (com o próprio Monitor de desempenho, ou usando alertas do SQL Agent, ou usando o DMV sys.dm_os_performance_counters, ou em sua ferramenta de monitoramento de terceiros favorita):
    Crescimentos de log

    Você não quer ver esse contador aumentando, pois isso diz que há algo acontecendo no banco de dados que está causando a geração de mais logs de transações do que o espaço atual. Isso implica que o log de transações não pode ser limpo, portanto, você deve investigar a causa consultando o campo log_reuse_wait_desc de sys.databases e tomar qualquer ação necessária (consulte o tópico dos Manuais Online Fatores que podem atrasar o truncamento de log para obter mais detalhes). Algum código de exemplo seria:
    SELECT [log_reuse_wait_desc]
    	FROM sys.databases
    	WHERE [name] = N'YourDB';
    GO

    Sempre que ocorre um crescimento de log, a parte recém-alocada do log de transações deve ser zerada, além de mais arquivos de log virtuais serem adicionados - ambos podem causar problemas como eu escrevi anteriormente.
    Redução de log

    A menos que você seja a pessoa que executa a operação de redução para trazer um log de transações fora de controle de volta ao controle, você não quer ver esse contador aumentando. Se alguém simplesmente encolher o log de transações sem um bom motivo, ele provavelmente crescerá novamente, causando problemas como eu escrevi anteriormente.
    Porcentagem de log usado

    Você deve monitorar esse contador e se preocupar se o valor for superior a 90%, pois isso indica que um crescimento de log pode ser iminente e o log de transações não consegue limpar corretamente, conforme discutido acima.
    Aguardas de liberação de log/s

    Você deseja que esse valor permaneça o mesmo ou diminua. Se aumentar, significa que você tem um gargalo de subsistema de E/S ou um gargalo dentro do mecanismo de liberação de log porque está liberando muitas pequenas porções de log. Um aumento aqui também pode se correlacionar com a obtenção de 32 E/Ss pendentes para o log. Veja a discussão de sys.dm_io_pending_io_requests acima para mais detalhes.
    Log Bytes liberados/s e registros liberados/s

    Esses dois contadores permitem que você descubra o tamanho médio de liberação de log, dividindo o primeiro contador pelo segundo. O resultado será um valor entre 512 e 61440 (os tamanhos mínimo e máximo de uma liberação de log, respectivamente). É mais provável que um valor mais baixo se correlacione com o aumento das Esperas de Liberação de Log/s. Novamente, veja a discussão de sys.dm_io_pending_io_requests acima para mais detalhes.
Eventos estendidos

Para os mais avançados, existem alguns Eventos Estendidos que você pode usar para observar o que está acontecendo com o log. Eu recomendo que você comece usando o modelo de rastreamento de IO do arquivo de log do banco de dados no SQL Server 2012 SSMS. Você pode chegar a isso acessando o Pesquisador de Objetos e, em seguida, sua instância -> Gerenciamento -> Eventos Estendidos e clicando com o botão direito do mouse em Sessões para selecionar Assistente de Nova Sessão. Na janela exibida, digite um nome de sessão e selecione o modelo de acompanhamento na lista suspensa. Em seguida, pressione Ctrl+Shift+N e a sessão será roteirizada para uma janela de consulta. Os detalhes de tudo lá estão além do escopo deste post, infelizmente, mas a descrição do modelo é bastante explicativa:
Este modelo monitora a E/S para arquivos de log de banco de dados em um servidor rastreando E/S assíncronas, liberações de log de banco de dados, gravações de arquivos, backoffs de spinlock do tipo LOGFLUSHQ e esperas do tipo WRITELOG. Esse modelo coleta dados de duas maneiras:dados brutos são coletados em um buffer de anel e as informações de backoff de spinlock são agregadas com base no buffer de entrada (sql_text). A sessão é filtrada para um único arquivo de log por banco de dados; se você tiver vários arquivos de log, poderá modificar o filtro para os eventos file_write_completed e file_written para incluir mais do que apenas file_id =2.
Há também um novo evento estendido no SQL Server 2012 chamado transaction_log que pode ser usado para fazer todo tipo de análise interessante de quais registros de log estão sendo gerados. Esse é definitivamente um assunto que abordarei em um post futuro.

Resumo


Dadas todas as informações acima, você deve ser capaz de criar um sistema de monitoramento de log de transações muito bom. A integridade do log de transações é de suma importância para garantir que sua carga de trabalho esteja funcionando como deveria e espero que as quatro postagens desta série (mais todos os outros links) tenham ajudado você a melhorar o desempenho geral do ambiente do SQL Server.