Início / dba / Perguntas / 93262
Accepted
M.Ali
Asked: 2015-02-19 13:33:39 +0800 CST

Maior espera WriteLog

  • 772

Recebi um servidor (SQL Server 2008R2 64 bits) onde nosso aplicativo está sendo executado. Houve uma diminuição gradual no desempenho do aplicativo. Agora chegou a um ponto em que o desempenho se tornou uma preocupação séria. Comecei a investigar e segui os seguintes passos.

  1. Verifiquei o uso do processador e da memória no servidor sql (nada está esgotado), muitos recursos gratuitos.

  2. A fragmentação do índice foi mínima, mas reconstruiu os índices e atualizou as estatísticas.

  3. Nenhuma alteração foi feita no código do aplicativo (código do aplicativo/código do servidor SQL), portanto, é improvável que o baixo desempenho devido ao código mal escrito seja a causa do baixo desempenho geral do aplicativo.

  4. Finalmente consegui o roteiro de Paul Randal Wait statistics, or please tell me where it hurts. O resultado do script mostra que o sql server precisa esperar muito ao gravar no arquivo de log. O maior tipo de espera é WRITELOG.

Usei a ferramenta SQLIO para medir o desempenho de leitura/gravação do disco e parece tão rápido quanto qualquer outro disco.

Eu sei de fato que suspeito que é mais provável que haja algo errado com o processo de gravação de log, mas estou ficando sem lugares para procurar, alguém pode me aconselhar onde mais devo procurar problemas.

Quais podem ser as possíveis causas de gravações de log lentas? ou qualquer conselho ou indicação na direção certa são muito apreciados. Obrigada.

╔═══════════════╦═════════════╦═══════════╗
║   WaitType    ║   Wait_S    ║ WaitCount ║
╠═══════════════╬═════════════╬═══════════╣
║ IO_COMPLETION ║ 4850500.20  ║ 4553514   ║
║ WRITELOG      ║ 25291893.90 ║ 795877    ║
╚═══════════════╩═════════════╩═══════════╝
sql-server sql-server-2008-r2

1 respostas

  1. Best Answer

    Depois de fazer muito mais investigação, isso é o que eu encontrei.

    Ele corrigiu o problema (ganho significativo de desempenho e WRITELOG tem um tempo de espera médio de 0,0126, que inicialmente era 14,681)

    Aparentemente, o problema era com o número de arquivos de log virtual em meu arquivo de log físico.

    Há um trabalho agendado para reconstruir índices todas as noites, o trabalho cria 36 GB de logs e, até algumas semanas atrás, alguém adicionava um trabalho para reduzir o arquivo de log semanalmente. O arquivo de log estava sendo reduzido para 500 MB.

    Como é um servidor muito ocupado, o arquivo de log aumentaria de tamanho e foi configurado para aumentar automaticamente em 3%. Cada vez que crescia, adicionava mais e mais VLFs. Como resultado, meu arquivo de log de 35,5 GB tinha 1600 VLFs.

    Para resolver o problema fiz o seguinte: 

    -- To get the number of VLFs in a physical Log file.
DECLARE @count INT, @DBname SYSNAME;
------------------------------------------------------------
SET @DBname = N'TEST_DB'
------------------------------------------------------------

DBCC LOGINFO(@DBname)
     SET @count = @@ROWCOUNT;

SELECT @DBname AS DatabaseName , @count Total_VLFs;
GO

    A consulta acima retornou o nome do banco de dados e o número de VLFs (1600)

    Para reduzir o número de VLFs, fiz o seguinte:

    USE TEST_DB;
GO

DBCC SHRINKFILE (TEST_DB_log, 0, TRUNCATEONLY)
GO

DBCC SHRINKFILE (TEST_DB_log  , 0)
GO

ALTER DATABASE TEST_DB
  MODIFY FILE ( NAME       = TEST_DB_log
              , SIZE       = 36864MB
              , FILEGROWTH = 4096MB)
GO

    Isso reduziu o número de VLFs de 1600para 20. Os usuários finais observaram uma melhora repentina no desempenho do aplicativo.

    Agora, uma coisa que não tenho certeza é se 20 VLFs é o número certo de VLFs para um arquivo de log de 36 GB. Mas parece ter um bom impacto no desempenho do banco de dados.

    • 1

relate perguntas