Arquivo de log gigante?

Para quem sofre com este problema, a prática mais comum no SQL Server 2005 é utilizar o Backup Log Truncate em seguida Shrink (at. http://blog.sqlauthority.com/2006/12/30/sql-server-shrinking-truncate-log-file-log-full/ ), mas será que é realmente a melhor escolha a fazer? Será que não há um motivo para não haver isso no SQL Sever 2008? Será que não vale a pena mudar o Recovery Model do banco de dados para Simple?

Bem quer saber o jeito correto de para resolver o problema com o arquivo de log? Então dê uma boa lida nestes dois tópicos sobre o assunto, escritos pelo MVP Gustavo Maia Aguiar:
Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE_ONLY – Parte I
Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE_ONLY – Parte II

Já tive uns problemas legais com arquivo de log gigante, que nem com o método Truncate/Shrink deu jeito, mas sempre vale a pena verificar se o plano de manutenção do SQL Server não esta mal estruturado (já resolvi este problema assim), ou se tem replicações “mortas” no banco de dados (um dia, talvez eu entenda o que aconteceu e como resolvi o problema com replicações “mortas” e o arquivo de log, para poder escrever sobre).

4 pensamentos sobre “Arquivo de log gigante?

  1. Kra, não consegui postar a dúvida no próprio artigo, mas talvez você possa me responder.

    Ele disse que uma boa prática para evitar que o Log cresça indefinidamente é realizar periodicamente o backup do log. Mas no caso do modo de recuperação FULL, isso é verdadeiro? Ele realiza o truncate do log no momento do backup?

    No caso, realizar o backup do log com a opção do truncate imediatamente antes de realizar um backup full é aceitável?

    Obrigado
    Alex

    • Alex,

      Sobre suas duas primeiras perguntas, quando você realiza um backup full em recovery model full, você esta informando ao SQL Server que o espaço do log anterior poderá ser reutilizado para as próximas transações. Exemplo:

      1. Tenho 1X de log se faço gero mais 1X de log, logo vou ter 2X log.
      2. Tenho 1X de log, faço um backup full, gero mais 1X de log, terei somente 1X log.

      Então, usar o backup full é uma boa alternativa para manter o tamanho do log.

      Sobre o backup log antes do backup full, creio que não há necessidade, pois você terá 2 backups dos mesmos dados, só que de formas diferentes.

      • Uma dúvida, estou com um banco com modo de recuperação FULL… realizo periodicamente o backup full desta base. Porém o banco está com 56MB de espaço (é um sistema simples) mas o log está com 11.4 GB. É seguro realizar o backup com truncate neste banco quando ele estiver inativo e continuar com a política de backup de Fulls?

        E no caso de uma política de backup, o fato de eu realizar um backup full me dá um log de tamanho controlado?

        Vlw.. kra.. obrigado

  2. Bom dia Alex,

    Não vejo problema em executar um shrink no seu banco para um tamanho adequado, mas valide o porquê dele estar com tanto log. Depois continue com a politica de backup full para manter o log em um tamanho controlável.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s