none
Backup TSM & Log Shipping RRS feed

  • Pergunta

  • Boa tarde,

    Temos aqui um banco no SQL 2000 com cerca de 30GB.

    Sempre fizemos um backup full diario as 4h em um arquivo local no servidor.

    Tivemos um tempo atras o Veritas como solução de backup em fita, para todos os servidores inclusive neste, porém como uma vez ficamos na mão sem conseguir fazer um restore no Veritas, sempre confiamos neste backup local.
    A solução de backup geral foi alterada para o IBM TSM (Tivoli Storage Manager), porém também continuamos com nosso confiável arquivo de backup local.

     

    Então este banco tem um full aproximadamente as 18h em fita através do TSM e outro full as 4h em disco em um job.

     

    O problema é que surgiu a necessidade de:

    A) Uma réplica deste banco em outro servidor, somente para consulta. Pensei em usar Log Shipping ou Replicação.

     

    B) Diminuir a perda de dados em caso de crash do banco, fazendo backups de log peródicos.

     

    Resolvo os 2 problemas com Log Shipping, certo !?

    Minha dúvida são os dois full's diários, eles criarão problemas nas sequências das log´s não é !?

    Em alguns testes que fiz, alguns restores de log davam aquele mensagem de fora de sequência ...

     

    Minha solução é tirar um dos full's ou tenho outra alternativa !?

     

    muito obrigado por qualquer ajuda ...

    até logo!

     

    Fabio Caiut

    segunda-feira, 8 de outubro de 2007 19:27

Respostas

  • se sua latencia for pequena, ou seja vc. pode ter um tempo entre o de producao e as outros servers, um log shipping seria ideal ( veja se seu sql e enterprise so o enterprise faz log shipping direto o stantard da para implementar algo pareeido fazer restore de log em uma base read only ), agora se vc. precisa ter as bases up to date, exatamente iguais uma replicacao transacional immediate update seria o mais indicado.

     

    Abs;

    segunda-feira, 8 de outubro de 2007 19:42
  • Fabio,

     

    Analisando a sua necessidade, eu prefiro trabalhar com replicação transacional por se tratar de um processo que pode ser automatizado, principalmente para obter uma melhor performance.

     

    Em relação ao log shipping, por se tratar de um processo de restauração de um log de banco de dados entre servidores diferentes, este processo dependendo da base da dados pode se tornar mais demorado, e também possui um grau de complexidade maior em relação a troca de informações entre servidores.

    segunda-feira, 8 de outubro de 2007 19:58
    Moderador
  • vai ter problema sim, vc. so vai poder fazer um backup full durante o dia. depois so os de log mesmo, se vc. pode ter 2 horas de perda banco acho que o log shipping e a melhor opcao.

     

     

    Abs;

     

    terça-feira, 9 de outubro de 2007 11:03

Todas as Respostas

  • se sua latencia for pequena, ou seja vc. pode ter um tempo entre o de producao e as outros servers, um log shipping seria ideal ( veja se seu sql e enterprise so o enterprise faz log shipping direto o stantard da para implementar algo pareeido fazer restore de log em uma base read only ), agora se vc. precisa ter as bases up to date, exatamente iguais uma replicacao transacional immediate update seria o mais indicado.

     

    Abs;

    segunda-feira, 8 de outubro de 2007 19:42
  • Fabio,

     

    Analisando a sua necessidade, eu prefiro trabalhar com replicação transacional por se tratar de um processo que pode ser automatizado, principalmente para obter uma melhor performance.

     

    Em relação ao log shipping, por se tratar de um processo de restauração de um log de banco de dados entre servidores diferentes, este processo dependendo da base da dados pode se tornar mais demorado, e também possui um grau de complexidade maior em relação a troca de informações entre servidores.

    segunda-feira, 8 de outubro de 2007 19:58
    Moderador
  •  

    Obrigado Marcelo ...

    Temos Enterprise .... e podemos atualizar a outra base com até 1 dia de atraso .... porém pensamos em 2h ...

     

    Quanto a ter 2 backups full .... vc saberia me dizer alguma coisa !? Isto criaria algum problema para as logs subsequentes !?
    O TSM usa a API para backup do SQLServer .... e no job uso o comando BACKUP DATABASE ... não sei se eles produzem o mesmo efeito sobre o banco ...

    Será que ambos truncam a log !?

     

    Eu ficaria com algo assim:

    4h .......... backup full disco

    6h .......... backup log

    8h .......... backup log

    ....

    16h .......... backup log

    18h .......... backup log
    18:30 ........ backup full TSM..  << == ISTO É UM PROBLEMA ???
    20h .......... backup log

    22h .......... backup log

    ...

     

    obrigado ...

    Fabio Caiut

    segunda-feira, 8 de outubro de 2007 20:06
  •  

    Obrigado Galvão ...

    Não tinha dito isto no primeiro post ... mas mesmo podendo ter a outra base com até 1 dia de diferença ... a replicação continua boa opção !?

     

    E no caso da base principal ter um crash ... pensei em aproveitar os backups de log feitos pelo Log Shipping para restaurar a base com no máximo 2 horas de perda ....

     

    O que acha !?

     

    obrigado ...

    Fabio Caiut

    segunda-feira, 8 de outubro de 2007 20:13
  •  

    Aproveitando ... se puder me ajudar na questão de ter 2 backups full entre os logs .... como descrevi acima .... Sabe se isto pode me criar problemas !??

     

    obrigado novamente ...

    Fabio Caiut

    segunda-feira, 8 de outubro de 2007 20:15
  • vai ter problema sim, vc. so vai poder fazer um backup full durante o dia. depois so os de log mesmo, se vc. pode ter 2 horas de perda banco acho que o log shipping e a melhor opcao.

     

     

    Abs;

     

    terça-feira, 9 de outubro de 2007 11:03
  •  

    Fabio,

     

    Realmente com este cenário, você terá problemas, o log shipping acaba sendo uma melhor solução.

    terça-feira, 9 de outubro de 2007 11:56
    Moderador
  • Obrigado pela ajuda pessoal ...

    Vou ter que tirar um dos backup's full mesmo ...

     

    um abraço ...

    Fabio Caiut

    terça-feira, 9 de outubro de 2007 14:00
  • Fábio,

     

    Isso mesmo, agora é melhor você fazer uma análise para identificar a melhor estratégia.

    terça-feira, 9 de outubro de 2007 15:05
    Moderador