none
O backup regular de Logs impede que este cresça indefinidamente em um modo de Recovery Full RRS feed

  • Pergunta

  • Bom dia! Estive lendo o artigo do Gustavo sob crescimento de Arquivos de Log e fiquei com uma dúvida (como não foi possível postar um comentário, tive que vir aqui).

    Ele disse que uma boa prática para impedir que o Log cresça indefinidamente é realizar regularmente o backup dos Logs.

    Mas realizando o backup, o log é truncado?

    Entendi que no sql server 2008 não há a opção de realizar o backup log witch truncate_only. Como seria feito o truncamento do log neste caso?

    É palpável de tempos em tempos, quando em um grande intervalo de tempo, realizar o backup com a opção de truncate imediatamente antes ao backup Full?

    Obrigado pela atenção de todos, Alex
    quarta-feira, 9 de dezembro de 2009 13:21

Respostas

  • Boa Tarde,

    Como autor do artigo gostaria de esclarescer as dúvidas (estou vendo algumas confusões se formando nesse post...)
     
    O processo de backup de log e de truncamento de log é exatamente o mesmo, ou seja, as entradas mais antigas do log são descartadas. A única diferença é que um backup de log irá retirar as entradas antigas do arquivo de log e irá colocá-las em um arquivo (o arquivo de backup que normalmente tem a extensão .TRN). Já o "TRUNCATE" irá retirar as entradas mas antigas e não irá salvá-las em nenhum local. Ambas as implementações irão fazer com que o arquivo de log fique mais "vazio" para novas entradas, mas isso não irá diminuir o tamanho do arquivo. O arquivo apenas terá mais área livre, mas o espaço continuará alocado. Nesse ponto, precisamos diferenciar o que é truncar o log do que é fazer um shrink no log, já que não significa a mesma coisa.

    O arquivo de log terá sempre uma área alocada e uma área utilizada. Digamos por exemplo 10GB de área alocada e 8GB de área utilizada. Se temos um arquivo com 10GB alocado, o tamanho dele é 10GB. 10GB serão ocupados pelo SQL Server junto ao SO e 10GB será necessários na hora de restaurar o backup para remontar o arquivo de Log. Se a área alocada é 10GB, mas a utilizada é 8GB há então 2GB de folga, ou seja, de área não utilizada. Essa área não utilizada (2GB) pode ficar retida para que caso a área utilizada aumente (digamos de 8GB para 9GB), não haja necessidade do arquivo crescer de novo. Se a área utilizada sai de 8GB para 9GB, mas há uma área alocada de 10GB, esses mesmos 10Gb podem comportar a área utilizada de 9GB e ainda assim manter mais 1GB de sobra. Evitar que o arquivo "tenha" de crescer significa ganhos de desempenho, pois, o log não terá que "parar o seu trabalho" para aguardar que o arquivo "cresça". Outra possibilidade é liberar esses 2GB para o SO, ou seja, igualar a área alocada de 8GB com a área utilizada de 8GB e assim não utilizar nenhuma sobra. Pode ser interessante para diminuir o tamanho do log, mas é preciso lembrar que se a área alocada é de 8GB e a área utilizada também é de 8GB, qualquer crescimento irá aumentar a área utilizada que irá solicitar mais área a ser alocada incorrendo em perda de desempenho e fragmentação do arquivo de log.

    O uso do backup (ou do truncate) age sobre a área utilizada enquanto que o SHRINK age sobre a área alocada. Um arquivo de 10GB de área alocada e 8GB de área utilizada pode sofrer um SHRINK para igualar a área alocada (10GB) à área utilizada (8GB) o que significa em outras palavras eliminar a sobra. O uso do backup (ou do truncate) irá agir na área utilizada, ou seja, "despejar" os 8GB em um arquivo (na hipótese do backup) ou simplesmente eliminar os 8GB de Log (na hipótese do truncate). Apenas liberar a área utilizada, não irá fazer com que a área alocada (10GB) seja reduzida. Mesmo que a área utilizada (8GB) seja reduzida a zero, a área alocada (10GB) continuará com o mesmo tamanho. O que irá aumentar nessa caso é a sobra, ou seja, tem-se uma área alocada de 10GB, uma área utilizada de 0 e por consequência uma sobra de 10GB para crescimento.

    Por isso que normalmente, se faz o backup de log (limpa-se a área utilizada e se aumenta a sobra), para posteriormente se realizar o SHRINK (eliminar a folga). A combinação desses procedimentos (nessa ordem) faz com o tamanho do arquivo seja reduzido. Vale lembrar que não é tão efetivo rodar o SHRINK sem um backup anterior, pois, não será possível eliminar área além da folga. Se a área alocada é de 10GB e a área utilizada é de 8GB, o SHRINK irá reduzir o Log até 8GB no máximo. Somente um backup (ou o truncate) conseguirá liberar mais espaço da área utilizada para que o SHRINK seja mais efetivo.

    Você jamais deve preocupar-se de forma primária com o tamanho de um arquivo de log. Normalmente crescimentos inesperados do arquivo de log são frutos de má administração ou mau planejamento. Em linhas gerais, se você necessita do backup de log (ou seja vai precisar retornar o banco em momentos específicos), você deve utilizar o recovery model full e planejar-se para fazer os backups de log. Se os backups de log são realizados regularmente, então a área utilizada não irá crescer além da conta e não irá fazer com que mais área seja alocada para crescimento. Se você não necessita do backup de log (ou seja, precisará do backup apenas nos momentos do backup full e diferencial) então não use o Recovery Model Full, use o Simple e esqueça o arquivo de log, pois, nesse recovery model, a área utilizada é sempre reciclada automaticamente. Não é preciso fazer backup para limpar a área utilizada, mas o fato de não haver backup do log é justamente o que irá lhe "tirar" a possibilidade de voltar o banco em momentos específicos. O Recovery Model Full significa mais administração mas também trás consigo mais possibilidades. O Recovery Model Simple significa menos possibilidades mas também menos administração.

    Truncar o log é no mínimo uma atividade sem significado. Se o log encheu é porque não houve o backup, e se você precisa truncá-lo é porque o backup de log não é necessário (se o log é truncado, o backup é perdido). Se o log não é necessário não há porque usar o recovery model full, basta utilizar o simple. A Microsoft entende que isso é correto e por isso mesmo retirou o TRUNCATE do SQL Server 2008.

    Mudar um Recovery Model de FULL para SIMPLE apenas para truncar o log pode ser uma atitude desesperada e com consequências. Se a mudança está sendo feito porque se entende que o backup de log não é necessário, então ela é bem vinda. Se a mudança está sendo feita para eliminar a parte utilizada do log, a mesma pode ser um erro. Se o log é necessário que se faça o backup, se ele não é necessário que se mude o recovery model em caráter definitivo. O que não pode é mudar para SIMPLE e depois mudar para FULL só para truncá-lo.

    Acredito que juntamente com o artigo, a apresentação de Disaster Recovery que realizei no SQL Server Day (na qual abordo mais sobre o log de transações) será muito esclarescedora (se você gostou do artigo vai gostar do Webcast). Maiores detalhes em:

    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!765.entry

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    A Impedância, o Mapeamento Objeto Relacional e Implementações – Parte II
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!814.entry
    Classifique as respostas. O seu feedback é imprescindível
    quinta-feira, 10 de dezembro de 2009 18:19

Todas as Respostas

  • Alex,

    Vou tentar de ajudar:

    Mas realizando o backup, o log é truncado?
     - Após a reliazação do backup de log, o mesmo é descartado.

    No SQL Server 2008 não é mais possível realizar o backup log with Truncate_Only.

    A própria Microsoft não recomenda fazer o backup de log utilizando truncate.


    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    quarta-feira, 9 de dezembro de 2009 13:25
    Moderador
  • Boa tarde Alex

    Fazendo o backup do log regularmente, não irá diminuir o tamanho do LOG se você estiver usando como Recovery Model FULL, então a alternativa é você efetuar o Shrink do LOG.



    Espero ter ajudado
    Anderson - DBA/MCP/MCTS/MCITP/MCT - Sua pergunta foi respondida ? Marque-a como tal! www.myspace.com/andersondpa
    quarta-feira, 9 de dezembro de 2009 16:07
  • Alex,

    Se você deseja descartar o log, então neste caso a solução mais simples e indicada é alterar o seu recovery model para Simples neste banco de dados.
    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    quarta-feira, 9 de dezembro de 2009 16:33
    Moderador
  • Alex,

        Seguindo o que o Galvão falou, mudando para recovery simple, é preciso que p/ isso você tenha total consciencia que você vai precisar de um backup plan diferenciado e muito bem amarrado, e que com o "simple" você não consegue fazer por exemplo um mirroring ou log shipping do servidor.
    Tks. Fausto Fiorese Branco MCTS - SQL Server 2k5 São Paulo - Brasil * http://www.linkedin.com/in/faustobranco
    quarta-feira, 9 de dezembro de 2009 16:47
  • Pessoal, muito obrigado pelo auxílio.

    O problema do tamanho do Log era que, na empresa que estou trabalhando, a política de backup era feita de outra forma por outra pessoa. Quando cheguei, os logs já estavam grandes demais e estou me preocupando em diminuí-los e criar uma política que seja eficiente e que o problema não continue a ocorrer.

    Acho que as informações que vocês me passaram foram muito proveitosas. Vou pensar em um modo de melhorar esta questão aqui na empresa.

    Se houver mais alguma sugestão, estou pronto a recebê-las.

    Muito obrigado a todos!!!

    alex_fsi
    quinta-feira, 10 de dezembro de 2009 15:22
  • Boa Tarde,

    Como autor do artigo gostaria de esclarescer as dúvidas (estou vendo algumas confusões se formando nesse post...)
     
    O processo de backup de log e de truncamento de log é exatamente o mesmo, ou seja, as entradas mais antigas do log são descartadas. A única diferença é que um backup de log irá retirar as entradas antigas do arquivo de log e irá colocá-las em um arquivo (o arquivo de backup que normalmente tem a extensão .TRN). Já o "TRUNCATE" irá retirar as entradas mas antigas e não irá salvá-las em nenhum local. Ambas as implementações irão fazer com que o arquivo de log fique mais "vazio" para novas entradas, mas isso não irá diminuir o tamanho do arquivo. O arquivo apenas terá mais área livre, mas o espaço continuará alocado. Nesse ponto, precisamos diferenciar o que é truncar o log do que é fazer um shrink no log, já que não significa a mesma coisa.

    O arquivo de log terá sempre uma área alocada e uma área utilizada. Digamos por exemplo 10GB de área alocada e 8GB de área utilizada. Se temos um arquivo com 10GB alocado, o tamanho dele é 10GB. 10GB serão ocupados pelo SQL Server junto ao SO e 10GB será necessários na hora de restaurar o backup para remontar o arquivo de Log. Se a área alocada é 10GB, mas a utilizada é 8GB há então 2GB de folga, ou seja, de área não utilizada. Essa área não utilizada (2GB) pode ficar retida para que caso a área utilizada aumente (digamos de 8GB para 9GB), não haja necessidade do arquivo crescer de novo. Se a área utilizada sai de 8GB para 9GB, mas há uma área alocada de 10GB, esses mesmos 10Gb podem comportar a área utilizada de 9GB e ainda assim manter mais 1GB de sobra. Evitar que o arquivo "tenha" de crescer significa ganhos de desempenho, pois, o log não terá que "parar o seu trabalho" para aguardar que o arquivo "cresça". Outra possibilidade é liberar esses 2GB para o SO, ou seja, igualar a área alocada de 8GB com a área utilizada de 8GB e assim não utilizar nenhuma sobra. Pode ser interessante para diminuir o tamanho do log, mas é preciso lembrar que se a área alocada é de 8GB e a área utilizada também é de 8GB, qualquer crescimento irá aumentar a área utilizada que irá solicitar mais área a ser alocada incorrendo em perda de desempenho e fragmentação do arquivo de log.

    O uso do backup (ou do truncate) age sobre a área utilizada enquanto que o SHRINK age sobre a área alocada. Um arquivo de 10GB de área alocada e 8GB de área utilizada pode sofrer um SHRINK para igualar a área alocada (10GB) à área utilizada (8GB) o que significa em outras palavras eliminar a sobra. O uso do backup (ou do truncate) irá agir na área utilizada, ou seja, "despejar" os 8GB em um arquivo (na hipótese do backup) ou simplesmente eliminar os 8GB de Log (na hipótese do truncate). Apenas liberar a área utilizada, não irá fazer com que a área alocada (10GB) seja reduzida. Mesmo que a área utilizada (8GB) seja reduzida a zero, a área alocada (10GB) continuará com o mesmo tamanho. O que irá aumentar nessa caso é a sobra, ou seja, tem-se uma área alocada de 10GB, uma área utilizada de 0 e por consequência uma sobra de 10GB para crescimento.

    Por isso que normalmente, se faz o backup de log (limpa-se a área utilizada e se aumenta a sobra), para posteriormente se realizar o SHRINK (eliminar a folga). A combinação desses procedimentos (nessa ordem) faz com o tamanho do arquivo seja reduzido. Vale lembrar que não é tão efetivo rodar o SHRINK sem um backup anterior, pois, não será possível eliminar área além da folga. Se a área alocada é de 10GB e a área utilizada é de 8GB, o SHRINK irá reduzir o Log até 8GB no máximo. Somente um backup (ou o truncate) conseguirá liberar mais espaço da área utilizada para que o SHRINK seja mais efetivo.

    Você jamais deve preocupar-se de forma primária com o tamanho de um arquivo de log. Normalmente crescimentos inesperados do arquivo de log são frutos de má administração ou mau planejamento. Em linhas gerais, se você necessita do backup de log (ou seja vai precisar retornar o banco em momentos específicos), você deve utilizar o recovery model full e planejar-se para fazer os backups de log. Se os backups de log são realizados regularmente, então a área utilizada não irá crescer além da conta e não irá fazer com que mais área seja alocada para crescimento. Se você não necessita do backup de log (ou seja, precisará do backup apenas nos momentos do backup full e diferencial) então não use o Recovery Model Full, use o Simple e esqueça o arquivo de log, pois, nesse recovery model, a área utilizada é sempre reciclada automaticamente. Não é preciso fazer backup para limpar a área utilizada, mas o fato de não haver backup do log é justamente o que irá lhe "tirar" a possibilidade de voltar o banco em momentos específicos. O Recovery Model Full significa mais administração mas também trás consigo mais possibilidades. O Recovery Model Simple significa menos possibilidades mas também menos administração.

    Truncar o log é no mínimo uma atividade sem significado. Se o log encheu é porque não houve o backup, e se você precisa truncá-lo é porque o backup de log não é necessário (se o log é truncado, o backup é perdido). Se o log não é necessário não há porque usar o recovery model full, basta utilizar o simple. A Microsoft entende que isso é correto e por isso mesmo retirou o TRUNCATE do SQL Server 2008.

    Mudar um Recovery Model de FULL para SIMPLE apenas para truncar o log pode ser uma atitude desesperada e com consequências. Se a mudança está sendo feito porque se entende que o backup de log não é necessário, então ela é bem vinda. Se a mudança está sendo feita para eliminar a parte utilizada do log, a mesma pode ser um erro. Se o log é necessário que se faça o backup, se ele não é necessário que se mude o recovery model em caráter definitivo. O que não pode é mudar para SIMPLE e depois mudar para FULL só para truncá-lo.

    Acredito que juntamente com o artigo, a apresentação de Disaster Recovery que realizei no SQL Server Day (na qual abordo mais sobre o log de transações) será muito esclarescedora (se você gostou do artigo vai gostar do Webcast). Maiores detalhes em:

    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!765.entry

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    A Impedância, o Mapeamento Objeto Relacional e Implementações – Parte II
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!814.entry
    Classifique as respostas. O seu feedback é imprescindível
    quinta-feira, 10 de dezembro de 2009 18:19
  • Gustavo, muito obrigado! Como dizem alguns, você praticamente teve que desenhar para que eu entendesse! Você tinha razão... estava começando a fazer confusão.... A todos os outros que responderam muito obrigado!!!! Gostaria de parabenizar a todos vocês pela atenção que vocês dispõe a todos os participantes!!! Vlw mesmo!!!!! alex_fsi
    quinta-feira, 10 de dezembro de 2009 22:14