Muitos VLF’s podem degradar a performance da sua instância do SQL Server!


Olá pessoal tudo certo? Espero que sim!

Hoje irei falar sobre um assunto já bastante discutido entre a comunidade relacionado a perda de performance no ambiente devido a uma grande quantidade de VLF’s (Virtual Log Files) no log de transações das bases de dados.

O Engine do SQL Server divide cada arquivo físico de log internamente em um determinado número de VLF’s. Estes não possuem um tamanho fixo nem uma quantidade padrão para cada arquivo físico de log. O engine escolhe dinamicamente o tamanho dos VLF’s quando o arquivo de log é criado ou passa por uma expansão.

Se as configurações de auto-growth dos arquivos de log não estiverem bem definidas, você irá ter o log de transações com uma quantidade muito grande de VLFs e que irá ficar fragmentado com uma frequência maior, o que pode ser extremamente prejudicial à performance do processo de recovery e atividades relacionadas à replicação.

Primeiramente, vamos entender como são adicionados os VLF’s que passam por uma expansão, usando como referência o post da Kimberly Tripp (SQL Skills):

Expansões menores que 64MB e até 64MB = 4 VLFs serão adicionados.
Expansões maiores que 64MB e até 1GB = 8 VLFs serão adicionados.
Expansões maiores que 1GB = 16 VLFs serão adicionados.

Agora, vamos listar o que muitos VLF’s em um arquivo de log podem vir a causar:

1 – Lentidão no backup do transaction log: No processo de backup todos VLF’s presentes no log serão lidos antes da operação iniciar.

2  - Lentidão no processo de recovery da base de dados: Na primeira fase do processo de recovery das bases de dados chamada de Discovery, todos os VLF’s nas logs serão lidos e uma lista deles será montada para que a operação se inicie, muitos VLF’s podem vir a prejudicar a performance desta operação. Veja mais informações sobre nos links abaixo:



3 – Lentidão em uma replicação transacional: O log reader realiza a leitura dos arquivos de log varrendo os VLF’s, logo muitos VLF’s podem onerar o processo e prejudicar a replicação dos dados como um todo.

4 – Lentidão nas operações de insert/update/delete: Recomendo a vocês a realizar o teste proposto pelo Linchi no site abaixo para evidenciarem o problema neste caso:
  

Portanto, a recomendação é que você mantenha os seus logs sempre com uma quantidade de VLF’s razoável. Você pode verificar a quantidade de VLF’s de um banco de dados através do comando DBCC LOGINFO. Se você já possui o log de transações com muitos VLF’s e deseja reduzir a quantidade dos mesmos, você deve fazer o shrink do arquivo com o log de transações, e expandi-lo numa única operação para o tamanho desejado / necessário para suportar a carga de trabalho.
 
Outros links utilizados de referência para escrita deste post:

Nenhum comentário:

Postar um comentário