none
Backups log X LogShipping RRS feed

  • Pergunta

  • Olá,

    Montei uma solução de Logshipping que está funcionando direitinho, minha dúvida é com relação a minha rotina de backups.

    Faço um backup full por dia e os backups log ocorrem de hora em hora, como o logshipping trabalha justamente com backups de log gostaria de saber se o logshipping poderá afetar meu conjunto de backups.

     

    Att,

    Ricardo Muramatsu


    http://ricardomura.spaces.live.com
    terça-feira, 1 de junho de 2010 16:27

Respostas

  • Ricardo,

    Entendi a sua estratégia e realmente é muito interessante.

    Em relação ao Log Shipping, acredito que você não terá problemas, pois para cada processo de Backup o SQL Server gera um sequência de LSN específica, sendo assim, mesmo que o Backup Log tenha uma sequência LSN o Log Shipping é um processo totalmente externo ao Backup Log então teremos outra sequência.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário]
    quarta-feira, 2 de junho de 2010 12:39
    Moderador
  • Fala Jr,

    Tudo bem ? Eu acho que como o tópico falou de várias tecnologias, deve ter havido uma certa confusão.

    Todo backup de log irá retirar as entradas inativas do log e gravá-las em um arquivo (que corresponde justamente ao arquivo de backup). Então se temos um banco com os LSNs 001 a 004 inativos, um backup de log irá apagar esses LSNs e gravá-los em um arquivo deixando apenas o LSN005 disponível no banco.

    Se o log shipping realmente fosse um processo a parte e mantivesse uma sequência separada, como ele poderia funcionar e fazer a restauração, se o backup de log limpou os LSNs 001 a 004 ? Ele simplesmente não poderia, pois, não haveria como recuperar essa informação.

    O fato é que tanto o log shipping quanto um backup de log tradicional tem o mesmo comportamento e por isso os backups gravados pelo log shipping também devem ser armazenados, pois, embora o log shipping disponibilize a base no outro lado, alguém pode desejar restaurar um backup em uma posição específica em outro servidor. Podemos por exemplo ter o servidor A como primário e o servidor B como secundário, mas podemos desejar restaurar um backup antigo do servidor A no servidor C e para isso será necessário os logs antigos (exatamente os mesmos utilizados no log shipping de A para B).

    Normalmente esse detalhe "passa batido", pois, se faz log shipping de A para B e portanto tem-se em B uma cópia "pronta" da base A (com algum DELAY), mas isso não isenta a necessidade de cópia daqueles backups e por isso necessita-se de um cuidado com os backups gerados via log shipping. A opção COPY_ONLY poderia servir para resolver isso, mas ainda não foi o caso. Apenas a replicação transacional é capaz de "bloquear" os LSNs mesmo contra um processo de backup, ou seja, se houver replicação transacional, enquanto os registros não forem replicados, os LSNs não serão limpos mesmo que se trunque o log ou que se faça um backup de log.

    Sobre as técnicas de alta disponibilidade, apenas o Log Shipping pode influenciar no processo de backup. Mirror, Clustering e replicação não irão provocar problemas com os backups de LOGs.

    Como você fez a afirmação eu me peguei na dúvida se o seu raciocínio estaria certo e o meu errado. Quando li "uma sequência a parte" fiquei pensando que talvez o que eu conhecesse sobre log shipping estivesse incompleto. Embora não tenha encontrado uma fonte mais formal para evidenciar a linha de raciocínio, achei algo parecido no site da Red Gate que confirma que realmente é necessário copiar os logs utilizados pelo log shipping para um outro local de forma a possibilitar restaurações posteriores.

    What happens during log shipping?

    When log shipping is running, the SQL Server Agent backup job periodically makes a backup of the transaction logs on the primary server using SQL Backup. Each backup file is given a unique name.

    The transaction log backup files are then copied to the shared folder.

    The SQL Server Agent restore job periodically restores the completed transaction log backup files on the shared folder to the standby server using SQL Backup. SQL Backup identifies backup sets (or split backups), ensures all members of a backup set are present, arranges the files in sequence, and then restores each backup set sequentially.

    The transaction log backup files that have been restored are then moved from the shared folder to a location that you specify for processed backups when you configure the log shipping so that they are not picked up when the restore job is next run.

    Fonte:http://www.red-gate.com/supportcenter/Content.aspx?p=SQL%20Backup&c=SQL_Backup%5Carticles%5Csql_backup_log_shipping_standby_server.htm

    Ricardo,

    Sim. Você não só pode como deve reaproveitar esses logs. Afinal são os backups de log que você faria em uma rotina normal e caso você os perca, haverá uma quebra na sequência de log.

    [ ]s,

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

    Algumas implementações multivaloradas com XML e Table Value Parameter – Parte I
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!1066.entry

    Algumas implementações multivaloradas com XML e Table Value Parameter – Parte II
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!1067.entry


    Classifique as respostas. O seu feedback é imprescindível
    quinta-feira, 10 de junho de 2010 18:54

Todas as Respostas

  • Ricardo,

    Afetar em relação a performance ou integridade de dados?

    Se você já executa um backup full, e a cada 1 uma hora realiza um backup de log, qual o motivo de realizar um log shipping?


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário]
    terça-feira, 1 de junho de 2010 17:57
    Moderador
  • Os dados nesta base de dados que hoje está no servidor principal será migrada para o servidor secundário, desta forma a idéia é causar um período mínimo de indisponibilidade.

    A questão é apenas com relação a integridade do conjunto de backups, por exemplo, se no intervalo de um backup log e outro ocorrer um backup do banco o LSN muda e o conjunto de backups ficará inquerente, minha dúvida é se os backps log que o LogShipping efetua poderá comprometer a sequencia do LSN do meu conjunto de backups.

     

    Vlws

    Ricardo


    http://ricardomura.spaces.live.com
    terça-feira, 1 de junho de 2010 18:11
  • Ricardo,

    Entendi a sua estratégia e realmente é muito interessante.

    Em relação ao Log Shipping, acredito que você não terá problemas, pois para cada processo de Backup o SQL Server gera um sequência de LSN específica, sendo assim, mesmo que o Backup Log tenha uma sequência LSN o Log Shipping é um processo totalmente externo ao Backup Log então teremos outra sequência.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário]
    quarta-feira, 2 de junho de 2010 12:39
    Moderador
  • Show de bola, vlw mesmo cara.

    A estrutura é bem mais complexa, o Mirroring está ativa em um Cluster que faz parte de outra rede e domínio.

    Alem do Logshipping pensando no momento da migração também tenho um Mirroring para uma outra máquina usando certificados para os usuários do Mirroring.

    Com isto caso haja uma falha na rede (uma vez que o que fizemos foi uma gambiarra para uma rede acessar a outra) o Mirroring assume a aplicação, e quando formos migrar o Logshipping já estará atualizado.

    Att,

    Ricardo


    http://ricardomura.spaces.live.com
    quarta-feira, 2 de junho de 2010 13:00
  • Ricardo,

    Realmente você esta pensando de forma correta, trabalhando com recursos de alta-disponibilidade e contigência de dados, com certeza em caso de falha seu ambiente será desviado e continuará dentro das possibilidades em funcionamento.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário]
    quarta-feira, 2 de junho de 2010 13:10
    Moderador
  • Boa Tarde,

    Eu não concordo com o funcionamento do Log Shipping exposto. O Log Shipping faz backups de logs e um backup de log irá retirar as entradas inativas do log de transações independente de ser via Log Shipping ou um backup comum. Se a lógica fosse essa, ou seja, o log shipping mantivesse uma sequência a parte, a ausência de um backup de log normal iria deixar o tamanho do log da base gigante, pois, a sequência do log shipping nada teria a ver com a sequência do banco. Outro problema seria quando um backup de log acontesse. Se o backup de log limpa as entradas, como poderia o log shipping fazer elas "reaparecerem" e funcionar ?

    Se você utiliza o log shipping, você terá que contemplar esses logs na sua rotina de backup. Se esses logs forem apagados você não conseguirá restaurar o banco.

    [ ]s,

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

    Algumas implementações multivaloradas com XML e Table Value Parameter – Parte I
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!1066.entry

    Algumas implementações multivaloradas com XML e Table Value Parameter – Parte II
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!1067.entry


    Classifique as respostas. O seu feedback é imprescindível
    quinta-feira, 10 de junho de 2010 16:48
  • Maia,

    Com o que você não concordou? Foi com a minha orientação sobre o funcionamento do Log Shipping?


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário]
    quinta-feira, 10 de junho de 2010 17:00
    Moderador
  • Boa Tarde,

    Eu não concordo com o funcionamento do Log Shipping exposto. O Log Shipping faz backups de logs e um backup de log irá retirar as entradas inativas do log de transações independente de ser via Log Shipping ou um backup comum. Se a lógica fosse essa, ou seja, o log shipping mantivesse uma sequência a parte, a ausência de um backup de log normal iria deixar o tamanho do log da base gigante, pois, a sequência do log shipping nada teria a ver com a sequência do banco. Outro problema seria quando um backup de log acontesse. Se o backup de log limpa as entradas, como poderia o log shipping fazer elas "reaparecerem" e funcionar ?

    Se você utiliza o log shipping, você terá que contemplar esses logs na sua rotina de backup. Se esses logs forem apagados você não conseguirá restaurar o banco.

    [ ]s,

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

    Algumas implementações multivaloradas com XML e Table Value Parameter – Parte I
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!1066.entry

    Algumas implementações multivaloradas com XML e Table Value Parameter – Parte II
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!1067.entry


    Classifique as respostas. O seu feedback é imprescindível

    Entendi, foi pensando em um problem assim que fiz o post.

    Mediante isto, a solução seria eu guardar os log (.trc) gerados pela rotina do Logshipping para o caso de uma possível necessidade de restore? Eu poderia substituir minha rotina de backup log pelos traces gerados pelo Logshipping?


    http://ricardomura.spaces.live.com
    quinta-feira, 10 de junho de 2010 17:17
  • Fala Jr,

    Tudo bem ? Eu acho que como o tópico falou de várias tecnologias, deve ter havido uma certa confusão.

    Todo backup de log irá retirar as entradas inativas do log e gravá-las em um arquivo (que corresponde justamente ao arquivo de backup). Então se temos um banco com os LSNs 001 a 004 inativos, um backup de log irá apagar esses LSNs e gravá-los em um arquivo deixando apenas o LSN005 disponível no banco.

    Se o log shipping realmente fosse um processo a parte e mantivesse uma sequência separada, como ele poderia funcionar e fazer a restauração, se o backup de log limpou os LSNs 001 a 004 ? Ele simplesmente não poderia, pois, não haveria como recuperar essa informação.

    O fato é que tanto o log shipping quanto um backup de log tradicional tem o mesmo comportamento e por isso os backups gravados pelo log shipping também devem ser armazenados, pois, embora o log shipping disponibilize a base no outro lado, alguém pode desejar restaurar um backup em uma posição específica em outro servidor. Podemos por exemplo ter o servidor A como primário e o servidor B como secundário, mas podemos desejar restaurar um backup antigo do servidor A no servidor C e para isso será necessário os logs antigos (exatamente os mesmos utilizados no log shipping de A para B).

    Normalmente esse detalhe "passa batido", pois, se faz log shipping de A para B e portanto tem-se em B uma cópia "pronta" da base A (com algum DELAY), mas isso não isenta a necessidade de cópia daqueles backups e por isso necessita-se de um cuidado com os backups gerados via log shipping. A opção COPY_ONLY poderia servir para resolver isso, mas ainda não foi o caso. Apenas a replicação transacional é capaz de "bloquear" os LSNs mesmo contra um processo de backup, ou seja, se houver replicação transacional, enquanto os registros não forem replicados, os LSNs não serão limpos mesmo que se trunque o log ou que se faça um backup de log.

    Sobre as técnicas de alta disponibilidade, apenas o Log Shipping pode influenciar no processo de backup. Mirror, Clustering e replicação não irão provocar problemas com os backups de LOGs.

    Como você fez a afirmação eu me peguei na dúvida se o seu raciocínio estaria certo e o meu errado. Quando li "uma sequência a parte" fiquei pensando que talvez o que eu conhecesse sobre log shipping estivesse incompleto. Embora não tenha encontrado uma fonte mais formal para evidenciar a linha de raciocínio, achei algo parecido no site da Red Gate que confirma que realmente é necessário copiar os logs utilizados pelo log shipping para um outro local de forma a possibilitar restaurações posteriores.

    What happens during log shipping?

    When log shipping is running, the SQL Server Agent backup job periodically makes a backup of the transaction logs on the primary server using SQL Backup. Each backup file is given a unique name.

    The transaction log backup files are then copied to the shared folder.

    The SQL Server Agent restore job periodically restores the completed transaction log backup files on the shared folder to the standby server using SQL Backup. SQL Backup identifies backup sets (or split backups), ensures all members of a backup set are present, arranges the files in sequence, and then restores each backup set sequentially.

    The transaction log backup files that have been restored are then moved from the shared folder to a location that you specify for processed backups when you configure the log shipping so that they are not picked up when the restore job is next run.

    Fonte:http://www.red-gate.com/supportcenter/Content.aspx?p=SQL%20Backup&c=SQL_Backup%5Carticles%5Csql_backup_log_shipping_standby_server.htm

    Ricardo,

    Sim. Você não só pode como deve reaproveitar esses logs. Afinal são os backups de log que você faria em uma rotina normal e caso você os perca, haverá uma quebra na sequência de log.

    [ ]s,

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

    Algumas implementações multivaloradas com XML e Table Value Parameter – Parte I
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!1066.entry

    Algumas implementações multivaloradas com XML e Table Value Parameter – Parte II
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!1067.entry


    Classifique as respostas. O seu feedback é imprescindível
    quinta-feira, 10 de junho de 2010 18:54
  • Entendi, obrigado Gustavo, esse seu post respondeu exatamente a minha dúvida com relação ao LSN do logshipping e do backup log, vlw.

    Att,

    Ricardo Muramatsu


    http://ricardomura.spaces.live.com
    quinta-feira, 10 de junho de 2010 19:24