Carregando ...
Desculpe, ocorreu um erro ao carregar o conteúdo.

33123RE: [mssql-l] Transaction log

Expandir mensagens
  • João Polisel
    16 de set de 2015

      Ismael,

       

      Internamente o transaction log é dividido em porções menores chamadas VLF – Virtual Log File

       

      O shrink não é eficaz se houver um VLF ativo no final do arquivo. Os VLFs podem ser usados em um sequência física diferente da sequência lógica.

       

      Pense que teu arquivo tem 100 VLFs numerados 1 a 100. Você está atualmente usando o VLF 100 e todos os outros estão ocupados. Você faz um backup de log, o SQL Server copia tudo para disco, marca os VLFs como livres, e move o VLF ativo para o de número 90.

       

      Neste caso o SHRINK não vai conseguir liberar muita coisa do arquivo. Se você fizer novamente o procedimento grandes são as chances do novo VLF ativo ser um mais para o começo do arquivo e aí sim você consegue liberar bastante espaço.

       

      Tenha em mente também que os VLFs podem ter tamanhos variáveis pois são calculados de acordo com o incremento que houve no tamanho do arquivo de log.

       

      O comando abaixo te retorna uma linha para cada VLF do banco de dados

       

      USE <DATABASE>

      GO

      DBCC LOGINFO

      GO

       

      Bancos de dados com grandes quantidades de VLFs também podem sofrer de problemas de performance durante operações que façam log scan, como o processo de recovery, replicação transacional e etc...

       

      A recomendação é que você mantenha a quantidade de VLFs sempre inferior a 300. Claro que há exceções, se teu log for gigantesco (e você precisa dele enorme assim) então talvez precise passar de 300 VLFs J

       

      No SQL Server 2012 ou mais recente quando um banco de dados tem mais de 10000 VLFs o SQL Server registra no ERRORLOG a seguinte mensagem durante o recovery:

       

      Database %ls has more than %d virtual log files which is excessive. Too many virtual log files can cause long startup and backup times. Consider shrinking the log and using a different growth increment to reduce the number of virtual log files.

       

      O banco de dados %1! tem mais de %2! arquivos de log virtuais, o que é excessivo. O excesso de arquivos de log virtuais pode causar longos tempos de inicialização e backup. Considere reduzir o log e usar um incremento de aumento diferente para reduzir o número de arquivos de log virtuais.

       

      Observe que o número de VLFs na mensagem não é uma constante e portanto isso pode mudar entre versões. De fato no SQL Server 2012 CTP a mensagem era exibida para qualquer quantidade acima de 1000 VLFs e no RTM multiplicaram esse valor por 10

       

      []s
      João Polisel

       

      From: mssql-l@... [mailto:mssql-l@...]
      Sent: Tuesday, September 15, 2015 6:32 PM
      To: mssql-l
      Subject: Re: [mssql-l] Transaction log

       

       

      Ismael,

       

      boa tarde,

       

      Acho que vc inverteu a ordem dos fatos ai... 

       

      Pois o correto seria... fazer um backup full antes de tudo  e depois o shrink file, shrink log

      É backup full e depois backup do log e segue a sequencia.

       

      E para causar um pouco de terror benefico no cliente e criar o habito, caso este nao se acostumar a fazer backup full e mais backup do transact log, a tendencia será o logfile crescer cada vez mais, até lotar o HD (se nao tiver configurado limite para esses arquivos crescer)  e o problema vai ficar bem sério.. $$$

       

      []s angelo

       

       

       

       

      2015-09-10 11:38 GMT-03:00 Ismael Costa Junior icjunior07@... [mssql-l] <mssql-l@...>:

       

      Bom dia pessoal,

       

      Precisei fazer um shrink em um transaction log, pois o cliente não fazia backup e deixou o arquivo ficar maior que os datafiles. Para isso, gerei um backup do log e depois fiz o shrink, porém após rodar este primeiro shrink o arquivo não diminuiu de tamanho. Precisei gerar um novo backup do log e depois do segundo shrink é que ele diminuiu o tamanho. 

       

      Alguém teria alguma dica do motivo disto ocorrer? Teoricamente, se eu fiz o primeiro backup do log, ele já não deveria fazer o shrink?

       

      Obrigado a todos,

       

      -- 

      Att.,

      Ismael Junior

       

    • Mostrar todas as 6 mensagens neste tópico