none
Arquivo Log RRS feed

 > 

  • Pergunta

  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Boa tarde!!!

    O SQL Server 2000 e 2005 eu tenho uma procedure de BKP que sempre apos fazer o BKP truncava o LOG usando o comando:

    BACKUP LOG NomeBanco WITH TRUNCATE_ONLY

    Dessa forma, sempre que o usuario faz um BKP do banco pelo Sistema, o Log é TRUNCADO. Agora com o SQL Server 2008, o TRUNCATE_ONLY foi descontinuado. Ja abordei esse ajunto no Forum, e me disseram que teria que alterar o Recover Model para Simple, fazer um shinkfile e depois voltar para Full.

    Isso é impossivel de ficar executando esse processo em todos nossos clientes. Gostaria de saber se tem alguma forma de apos realizar CHECK POINT no LOG, realizar um BKP FULL e apos reduzir o LOG.

    Tenho um cliente que estava começando a travar, conectei la para dar uma olhada o LOG estava com 200 GB. Eu preciso realizar essa manutencao diariamente para evitar que chega a ser um problema o tamanho do LOG.

    Obrigado!!!

    • Editado DaviSaba segunda-feira, 10 de maio de 2010 18:31 .
    segunda-feira, 10 de maio de 2010 18:30
    |

Respostas

  • Question
    Entrar para Votar
    1
    Entrar para Votar

    Boa Tarde,

    Truncar o log com frequência é um dos maiores pecados capitais que se pode cometer em um banco de dados. Se você não precisa do log, deixe o recovery model como simple e ele jamais irá crescer. A cada CHECKPOINT ele automaticamente truncará a si próprio dispensando a necessidade de alguém ou alguma aplicação faça o truncate.

    Se o log é importante para que você utilize-o para RESTORE, então você não poderá truncá-lo, pois, truncá-lo irá inviabilizar o RESTORE de Log. Nesse caso faça o backup de log normalmente que o arquivo jamais aumentára e você não precisará truncá-lo.

    Não há meio termo. Ou você precisa do Log ou não precisa. Se não precisa, coloque SIMPLE e não se preocupe em truncá-lo. Se precisa, administre-o para que ele não cresça. Quem trunca o LOG normalmente não precisa dele. Senão precisa não faz sentido ter o RECOVERY MODEL FULL.

    Maiores detalhes em:

    Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE ONLY - Parte I
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!670.entry

    Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE ONLY - Parte II
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!671.entry

    [ ]s,

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

    Por que utilizar uma ferramenta de ETL ?
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!1026.entry 

    Classifique as respostas. O seu feedback é imprescindível
    • Sugerido como Resposta Gustavo Maia Aguiar segunda-feira, 10 de maio de 2010 18:51
    • Marcado como Resposta DaviSaba segunda-feira, 10 de maio de 2010 22:33
    segunda-feira, 10 de maio de 2010 18:51
    |

Todas as Respostas

  • Question
    Entrar para Votar
    1
    Entrar para Votar

    Boa Tarde,

    Truncar o log com frequência é um dos maiores pecados capitais que se pode cometer em um banco de dados. Se você não precisa do log, deixe o recovery model como simple e ele jamais irá crescer. A cada CHECKPOINT ele automaticamente truncará a si próprio dispensando a necessidade de alguém ou alguma aplicação faça o truncate.

    Se o log é importante para que você utilize-o para RESTORE, então você não poderá truncá-lo, pois, truncá-lo irá inviabilizar o RESTORE de Log. Nesse caso faça o backup de log normalmente que o arquivo jamais aumentára e você não precisará truncá-lo.

    Não há meio termo. Ou você precisa do Log ou não precisa. Se não precisa, coloque SIMPLE e não se preocupe em truncá-lo. Se precisa, administre-o para que ele não cresça. Quem trunca o LOG normalmente não precisa dele. Senão precisa não faz sentido ter o RECOVERY MODEL FULL.

    Maiores detalhes em:

    Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE ONLY - Parte I
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!670.entry

    Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE ONLY - Parte II
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!671.entry

    [ ]s,

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

    Por que utilizar uma ferramenta de ETL ?
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!1026.entry 

    Classifique as respostas. O seu feedback é imprescindível
    • Sugerido como Resposta Gustavo Maia Aguiar segunda-feira, 10 de maio de 2010 18:51
    • Marcado como Resposta DaviSaba segunda-feira, 10 de maio de 2010 22:33
    segunda-feira, 10 de maio de 2010 18:51
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Gustavo, li seus artigos sobre o TRUNCATE_ONLY.

    Como eu nao tenho nenhuma estrategia de BKP de LOG, posso usar sem medo o Recovery Model Simple.

    Pela sua explicacao uma das principais utilidades para usar o FULL seria utilizar estragias de BKP. Como trabalhamos com Empresas de pequeno e medio porte, temos no sistema a opção de realizar BKP, que sempre faz um BKP FULL. Nao sei se o fato dos clientes serem PME é justificativa para nao criar uma estrategia de BKP, mas o fato é nossa empresa é uma Softhouse e nao temos condicoes de fazer o papel de DBA em nossos clientes, que por sua vez, nao tem condicoes de manter um DBA interno.

    Com esse cenario, temos que implementar solucoes simples e eficiente. Por isso implementamos BKP Full via sistema que roda proc no banco.

    Sera que estamos no caminho certo? Obrigado!!!

    segunda-feira, 10 de maio de 2010 20:15
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar

    Oi Davi,

    Eu penso que se não há DBA para administrar esse log a melhor postura é optar pelo Recovery Model Simple. O Recovery Model Full só será interessante quando há alguém para administrá-lo e quando é necessário o Restore Point In Time. Me parece que seus clientes não tem DBA e por fazerem o backup via sistema talvez não sintam tanta falta do Restore Point In Time.

    Acredito que você possua duas opções. Pode deixar o RECOVERY MODEL SIMPLE por conta própria ou deixar claro para a empresa que o erro de LOG não é referente ao seu software e que demanda um DBA. Na hipótese (provável) de não haver um, você irá deixar o Recovery Model Simple, mas explique ao cliente que só será possível restaurar os backups a partir do sistema (sem Point In Time).

    [ ]s,

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

    Por que utilizar uma ferramenta de ETL ?
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!1026.entry 

    Classifique as respostas. O seu feedback é imprescindível
    segunda-feira, 10 de maio de 2010 20:50
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Obrigado, foi bem util.
    segunda-feira, 10 de maio de 2010 22:33
    |