none
Limpar LOG RRS feed

  • Pergunta

  •  

    Pessoal,

     

    Tenho uma base de dados que faço backup full toda noite.

    Ela esta com os arquivos da seguinte forma:

     

    Data: 164,88MB free: 24,68MB

    Log: 21.231,97MB free: 1.635,4MB

     

    Sou leigo nisto

     

    Bem, seria interresenta limpar o log do banco ? gostaria de uma dica, quais os pontos positivos e negativos de fazer isto ?

    Após limpar o log o tamanho fisico do banco diminiu ?

     

    Abraço

    • Movido Gustavo Maia Aguiar quinta-feira, 22 de dezembro de 2011 14:34 (De:SQL Server - Desenvolvimento Geral)
    terça-feira, 23 de setembro de 2008 22:17

Respostas

  • Olá Dexter,

     

    Acho que se eu pudesse melhorar algo na documentação ou nos livros de SQL Server ou até nos treinamentos, seria uma forma de disseminar o funcionamento do log de transações de modo que essa dúvida não fosse tão recorrente e tão presente em praticamente a maioria dos ambientes de SQL Server que existem. Não vou encher mais uma Thread com páginas e páginas sobre esse assunto, mas em todo caso vamos lá de novo...

     

    O SQL Server possui basicamente duas formas de trabalhar com o log. Vou pegar emprestado os termos de banco de dados, ou seja, temos o log circular e o Archieve.

     

    No log circular, os arquivo de log, vai gravando as transações que ocorrem e de tempos em tempos ele repassa as alterações para o arquivo de dados. Após isso acontecer, as transações são apagados do arquivo de log. Isso significa que se você definir um bom tamanho, ele nunca crescerá, pois, da mesma forma que novas transações chegam no arquivo de log, as antigas são eliminadas.

     

    No log Archieve, o funcionamento é o mesmo, mas a diferença é que as transações antigas não são apagadas do arquivo de log e é por isso que ele costuma encher podendo atingir proporções enormes (o que é o seu caso e de muitos certamente). Para impedir que ele encha, você precisa fazer o backup do log para copiar as transações antigas em um arquivo e eliminá-las do log.

     

    No log circular, você nunca conseguirá fazer um backup de log, já que o próprio SGBD limpa o log pra você. Nesse modelo você só poderá contar com backups full e diferenciais para restaurar bases de dados.

     

    No log archieve, você poderá contar com backups full, diferencial e de log e o backup de log permite que você volte a base a um ponto específico (ex: 20/09/2008 19:30:05) ainda que não haja um backup nesse mesmo momento.

     

    Então como você pode ver, há vantagens e desvantagens em deixar que o log se administre e não cresça e deixar que você o administre e o impeça de crescer. Vale a pena lembrar que se você limpar o log, poderá perder a capacidade de voltar o backup em um momento específico (pelo menos até o próximo backup full).

     

    Em todo caso, como você possivelmente não estava a par dessas questões (razão pela qual o log deve ter crescido), você pode limpar o log, reduzir o seu tamanho e a partir de agora fazer o backup de log regularmente (ou mudar para o log circular se o restore em um ponto específico não for importante).

     

    Para limpar o log rode os comandos abaixo (com a consciência de que se precisar voltar o backup em um momento específico isso não será possível).

     

    Code Snippet

    BACKUP Log Banco WITH TRUNCATE_ONLY

    GO

    USE Banco

    GO

    DBCC SHRINKFILE(2)

    GO

     

     

    Os termos log circular e log archieve são conhecidos como Recory Model Simple e Recovery Model Full no SQL Server.

     

    [ ]s,

     

    Gustavo

    terça-feira, 23 de setembro de 2008 22:44
  • Boa Tarde,

    Recomendo fortemente os artigos abaixo:

    Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE_ONLY – Parte I
    http://gustavomaiaaguiar.wordpress.com/2009/08/01/piores-praticas-%e2%80%93-utilizar-o-comando-backup-log-com-a-opcao-with-truncate_only-%e2%80%93-parte-i/

    Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE_ONLY – Parte II
    http://gustavomaiaaguiar.wordpress.com/2009/08/01/piores-praticas-%E2%80%93-utilizar-o-comando-backup-log-com-a-opcao-with-truncate_only-%E2%80%93-parte-ii/

    Não desperdice o seu tempo e não crie problemas pra você utilizando TRUCANTE_ONLY.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta KNascimento quinta-feira, 15 de novembro de 2012 20:38
    quinta-feira, 22 de dezembro de 2011 14:34

Todas as Respostas

  • Pessoal,

     

    Bem, como faço um backup full toda noite, estou pensando em colocar no script de backup's as seguintes linhas após o backup ser executado:

     

    - backup log meuBD with truncate_only

    - dbcc shrinkdatabase(meuDB)

     

    Que acham ?
    terça-feira, 23 de setembro de 2008 22:39
  • Olá Dexter,

     

    Acho que se eu pudesse melhorar algo na documentação ou nos livros de SQL Server ou até nos treinamentos, seria uma forma de disseminar o funcionamento do log de transações de modo que essa dúvida não fosse tão recorrente e tão presente em praticamente a maioria dos ambientes de SQL Server que existem. Não vou encher mais uma Thread com páginas e páginas sobre esse assunto, mas em todo caso vamos lá de novo...

     

    O SQL Server possui basicamente duas formas de trabalhar com o log. Vou pegar emprestado os termos de banco de dados, ou seja, temos o log circular e o Archieve.

     

    No log circular, os arquivo de log, vai gravando as transações que ocorrem e de tempos em tempos ele repassa as alterações para o arquivo de dados. Após isso acontecer, as transações são apagados do arquivo de log. Isso significa que se você definir um bom tamanho, ele nunca crescerá, pois, da mesma forma que novas transações chegam no arquivo de log, as antigas são eliminadas.

     

    No log Archieve, o funcionamento é o mesmo, mas a diferença é que as transações antigas não são apagadas do arquivo de log e é por isso que ele costuma encher podendo atingir proporções enormes (o que é o seu caso e de muitos certamente). Para impedir que ele encha, você precisa fazer o backup do log para copiar as transações antigas em um arquivo e eliminá-las do log.

     

    No log circular, você nunca conseguirá fazer um backup de log, já que o próprio SGBD limpa o log pra você. Nesse modelo você só poderá contar com backups full e diferenciais para restaurar bases de dados.

     

    No log archieve, você poderá contar com backups full, diferencial e de log e o backup de log permite que você volte a base a um ponto específico (ex: 20/09/2008 19:30:05) ainda que não haja um backup nesse mesmo momento.

     

    Então como você pode ver, há vantagens e desvantagens em deixar que o log se administre e não cresça e deixar que você o administre e o impeça de crescer. Vale a pena lembrar que se você limpar o log, poderá perder a capacidade de voltar o backup em um momento específico (pelo menos até o próximo backup full).

     

    Em todo caso, como você possivelmente não estava a par dessas questões (razão pela qual o log deve ter crescido), você pode limpar o log, reduzir o seu tamanho e a partir de agora fazer o backup de log regularmente (ou mudar para o log circular se o restore em um ponto específico não for importante).

     

    Para limpar o log rode os comandos abaixo (com a consciência de que se precisar voltar o backup em um momento específico isso não será possível).

     

    Code Snippet

    BACKUP Log Banco WITH TRUNCATE_ONLY

    GO

    USE Banco

    GO

    DBCC SHRINKFILE(2)

    GO

     

     

    Os termos log circular e log archieve são conhecidos como Recory Model Simple e Recovery Model Full no SQL Server.

     

    [ ]s,

     

    Gustavo

    terça-feira, 23 de setembro de 2008 22:44
  • Bom Dia, tentei rodar o mesmo comando no meu banco porem o sql me retornou o seguinte erro:
    Comando:
    BACKUP Log Teste WITH TRUNCATE_ONLY
    GO
    USE Teste
    GO
    DBCC SHRINKFILE(2)
    GO

     

    Erro:

    Mensagem 155, Nível 15, Estado 1, Linha 1
    'TRUNCATE_ONLY' is not a recognized BACKUP option.
    Cannot shrink log file 2 (Teste_log) because the logical log file located at the end of the file is in use.

    (1 linha(s) afetadas)
    DBCC execution completed. If DBCC printed error messages, contact your system administrator.

    quinta-feira, 22 de dezembro de 2011 14:15
  • Boa Tarde,

    Recomendo fortemente os artigos abaixo:

    Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE_ONLY – Parte I
    http://gustavomaiaaguiar.wordpress.com/2009/08/01/piores-praticas-%e2%80%93-utilizar-o-comando-backup-log-com-a-opcao-with-truncate_only-%e2%80%93-parte-i/

    Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE_ONLY – Parte II
    http://gustavomaiaaguiar.wordpress.com/2009/08/01/piores-praticas-%E2%80%93-utilizar-o-comando-backup-log-com-a-opcao-with-truncate_only-%E2%80%93-parte-ii/

    Não desperdice o seu tempo e não crie problemas pra você utilizando TRUCANTE_ONLY.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta KNascimento quinta-feira, 15 de novembro de 2012 20:38
    quinta-feira, 22 de dezembro de 2011 14:34
  • Só para lembrar...

    Truncate_Only não existe mais a partir do SQL 2008.

    Os links que o Gustavo passou são excelentes.


    View Ricardo Muramatsu's profile on LinkedIn
    sexta-feira, 23 de dezembro de 2011 09:59