none
Replicação Wan RRS feed

  • Pergunta

  • Olá Pessoal

    Preciso de dicas, ajudas, opiniões etc, de como posso resolver este impasse abaixo:

    Tenho um Servidor Windows 2008R2 com SQL Server 2012, Base de Dados com 25 GB, 

    trabalhando no modo Simple.

    Foi montando uma estrutura em um DataCenter, com o mesmo S.O, e mesma versão do SQL Server, no 

    datacenter que alocamos, e uma copia do banco de dados nosso, ja esta no datacenter.

    Agora o que eu preciso é replicar as informações local para o datacenter.

    Por onde começar?

    terça-feira, 22 de outubro de 2013 17:37

Respostas

  • Fala Felipe!

    Já tentei várias técnicas mas uma que se enquadra na maioria dos cenários é fazer um Log Shipping manual, ou seja, você configura facilmente um backup do Transaction Log do seu servidor localmente, que pode ser em um volume específico pra isso se necessário, bastando configurar no servidor do DC um job que faz o restore destes backups do TLog. Você só precisa alterar o seu Recovery Model para FULL, criar o job de backup do TLog de 1 em 1 hora, por exemplo, e verificar o quanto de espaço foi necessário para armazenar uma hora de transações durante uma semana. 

    Aqui tem um script que fiz, é bem simples de entender e funciona muito bem no restore automático:

    http://sqldicas.com.br/dicas/script-de-restore/

    Você pode utilizar este abaixo para fazer backup, assim você gera os arquivos já no formato que você vai precisar:

    http://sqldicas.com.br/dicas/script-de-backup-nomeando-o-arquivo-pela-data-e-hora/

    Este modelo é muito bom pois não haverá restrições técnicas (caso o DC gerencie o servidor de lá), fácil utilização, se não for um ambiente de intensas transações DML já sobrecarregado você nem percebe que os jobs estão rodando. Em ambientes com menos transações DML, que parece o seu caso com apenas 25GB, você pode agendar pra replicar em intervalos maiores, somente à noite, etc., bastando acompanhar o crescimento do TLog e garantir que há espaço para isso. A administração é simples, são jobs de backup e restore apenas do TLog, ou seja, praticamente não encosta no arquivo de dados de origem.

    Sem contar o show que você vai dar pois o downtime fica muito reduzido. Tudo que você tem a fazer para migrar é pegar o último backup da base de origem deixando ela em Revovery (Tail Log Backup) e restaurá-lo no destino deixando online. Para uma base de 25GB a diferença é pouca mas quando você for migrar uma base grande, um downtime de poucos minutos é muito bem visto pelos envolvidos no projeto.

    Aqui tem algumas outras dicas para o processo de migração:

    http://sqldicas.com.br/dicas/dicas-uteis-de-migraca/

    Neste outro tem algumas medidas preventivas para usar no procedimento de migração:
    http://sqldicas.com.br/dicas/sql-procedimentos-pre-migracao/

    Ajudou? Ficou mais alguma dúvida?

    Abs!


    Luiz Mercante
    MCITP SQL 2008 | MCTS SQL 2008 | MTA Database Fundamentals | MCTS Windows Apps | MCTS Windows Network | MCP 2003
    sqldicas@outlook.com
    http://sqldicas.com.br
    Se a resposta foi útil de alguma forma, classifique como resposta ou vote como útil.

    • Sugerido como Resposta Durval Ramos quarta-feira, 23 de outubro de 2013 10:24
    • Marcado como Resposta Felipe_Senna1 segunda-feira, 28 de outubro de 2013 16:54
    terça-feira, 22 de outubro de 2013 23:50
    Moderador

Todas as Respostas

  • Encontrei estes post do cara falando de latência e performance, http://blogs.technet.com/b/claudia_silva/archive/2010/01/04/replication-transactional-replication-over-wan.aspx

    Mas este link aqui talvez ajude, http://technet.microsoft.com/en-us/library/dd263442.aspx

    Recomendo você conversar com o Junior Galvão, cara fera nessa parte, ele vai te dar uma resposta. http://pedrogalvaojunior.wordpress.com/

    ___________________

    André Novello - Blog

    MCTS Server Virtualization

    terça-feira, 22 de outubro de 2013 17:57
  • Fala Felipe!

    Já tentei várias técnicas mas uma que se enquadra na maioria dos cenários é fazer um Log Shipping manual, ou seja, você configura facilmente um backup do Transaction Log do seu servidor localmente, que pode ser em um volume específico pra isso se necessário, bastando configurar no servidor do DC um job que faz o restore destes backups do TLog. Você só precisa alterar o seu Recovery Model para FULL, criar o job de backup do TLog de 1 em 1 hora, por exemplo, e verificar o quanto de espaço foi necessário para armazenar uma hora de transações durante uma semana. 

    Aqui tem um script que fiz, é bem simples de entender e funciona muito bem no restore automático:

    http://sqldicas.com.br/dicas/script-de-restore/

    Você pode utilizar este abaixo para fazer backup, assim você gera os arquivos já no formato que você vai precisar:

    http://sqldicas.com.br/dicas/script-de-backup-nomeando-o-arquivo-pela-data-e-hora/

    Este modelo é muito bom pois não haverá restrições técnicas (caso o DC gerencie o servidor de lá), fácil utilização, se não for um ambiente de intensas transações DML já sobrecarregado você nem percebe que os jobs estão rodando. Em ambientes com menos transações DML, que parece o seu caso com apenas 25GB, você pode agendar pra replicar em intervalos maiores, somente à noite, etc., bastando acompanhar o crescimento do TLog e garantir que há espaço para isso. A administração é simples, são jobs de backup e restore apenas do TLog, ou seja, praticamente não encosta no arquivo de dados de origem.

    Sem contar o show que você vai dar pois o downtime fica muito reduzido. Tudo que você tem a fazer para migrar é pegar o último backup da base de origem deixando ela em Revovery (Tail Log Backup) e restaurá-lo no destino deixando online. Para uma base de 25GB a diferença é pouca mas quando você for migrar uma base grande, um downtime de poucos minutos é muito bem visto pelos envolvidos no projeto.

    Aqui tem algumas outras dicas para o processo de migração:

    http://sqldicas.com.br/dicas/dicas-uteis-de-migraca/

    Neste outro tem algumas medidas preventivas para usar no procedimento de migração:
    http://sqldicas.com.br/dicas/sql-procedimentos-pre-migracao/

    Ajudou? Ficou mais alguma dúvida?

    Abs!


    Luiz Mercante
    MCITP SQL 2008 | MCTS SQL 2008 | MTA Database Fundamentals | MCTS Windows Apps | MCTS Windows Network | MCP 2003
    sqldicas@outlook.com
    http://sqldicas.com.br
    Se a resposta foi útil de alguma forma, classifique como resposta ou vote como útil.

    • Sugerido como Resposta Durval Ramos quarta-feira, 23 de outubro de 2013 10:24
    • Marcado como Resposta Felipe_Senna1 segunda-feira, 28 de outubro de 2013 16:54
    terça-feira, 22 de outubro de 2013 23:50
    Moderador
  • Olá Felipe,

    em adição ao que o Mercante disse, além do Log Shipping, você também pode usar o recurso de Database Mirroring. Esse recurso "espelha" uma base em produção em outra instância, enviando as transações disparadas na base produção para a base mirrored. Por usar um linka Wan, você pode configurar o recurso em modo de operação High Performance, onde a instância que de produção (pincipal) envia a transação para a base espelhada (mirrored), porém não espera a base espelhada concluir o commit, já respondendo para a aplicação com um ok do término da transação. Esse modo tem a vantagem de consumir menos banda, porém há a possibilidade da base espelhada não estar completamente sincronizada.

    Mais detalhes podem ser obtidos em:

    http://technet.microsoft.com/en-us/library/ms189852(v=sql.105).aspx

    Configuração de Database Mirroring:

    Configurando Database Mirroring em Workgroup - Parte I

    Configurando Database Mirroring em Workgroup - Parte II

    Espero ter ajudado.

    Att,



    Angelo Máximo
    MCSA | MTA | MCITP | MCT | CCSQLA
    sqlmax@outlook.com
    http://angmaximo.wordpress.com/

    Se a resposta foi útil, não esqueça de classificá-la.


    • Editado Angelo Maximo quarta-feira, 23 de outubro de 2013 12:05
    quarta-feira, 23 de outubro de 2013 12:05
  • Ola luiz,

    Pelo que entendi temos primeiramente que passar nosso banco para FULL?

    Isso pode interferir no nosso desempenho?

    E após fazer isso, temos que agendar o backup de 1 em 1 hora e isso?

    O job que você mandou de restauração eu tenho que agendar no datacenter?

    segunda-feira, 28 de outubro de 2013 17:21
  • Felipe, para implementar o log shipping é necessário que o banco tenha seu recovery model alterado para Full. A periodicidade de execução dos backups será definida por você, baseado em fatores como RPO (Recovery point objective). Esse indicador define o tempo de perda máxima tolerável de dados. Se a regra de negócio da empresa define que 30 minutos é o seu tempo máximo, então defina o intervalo de backups de logs para ser realizado no máximo para esse valor.

    No momento da configuração do log shipping, você setar a opção "Yes, Generate a full backup of the primary database and restore it onto the secondary database". Essa opção irá gerar um backup da base primária, na sua instância secundária, porém recomendo que isso seja feito apenas se o link de ligação entre os datacenters seja de alta velocidade, caso contrário é recomendável que você gere um backup full, grave em uma mídia (hd externo, fita) e envie para o destine e restaure o backup.

    Todo o processo de configuração é realizado na base primária.

    Att,


    Angelo Máximo
    MCSA | MTA | MCITP | MCT | CCSQLA
    sqlmax@outlook.com
    http://angmaximo.wordpress.com/

    Se a resposta foi útil, não esqueça de classificá-la.


    • Editado Angelo Maximo segunda-feira, 28 de outubro de 2013 17:35 Correção
    segunda-feira, 28 de outubro de 2013 17:34
  • Olá Felipe,

    Alterar a base para FULL não deve impactar na performance do seu ambiente já que em SIMPLE funciona igual ao FULL mas a cada Checkpoint seu TLog é truncado, mas você deve ter espaço para o seu Transaction Log crescer quando estiver em FULL. O ideal seria já aumentar o tamanho do arquivo de Transaction Log se você tiver espaço em disco, e ir monitorando através do comando DBCC SQLPERF(logspace) - http://sqldicas.com.br/dicas/acompanhando-a-utilizacao-do-tlog/.

    Se você tiver acesso às configurações do servidor que fica no Data Center, você pode configurar o Log Shipping que automaticamente já faz um backup da sua base e restaura no servidor de destino. Qual a largura de banda do link que você tem?

    Nas próprias configurações do Log Shipping você pode definir o agendamento de 1 em 1 hora, por exemplo. 

    Se você achar que está meio confuso, sugiro habilitar a compressão do backup no sp_configure e migrar fazendo backup e resotre da sua base. Com 25GB de tamanho, não deve chegar aos 3GB compactada. Já testou enviar um arquivo de aproximadamente 3GB pelo link pra ver quanto tempo demora?

    Abraços,



    Luiz Mercante
    MCITP SQL 2008 | MCTS SQL 2008 | MTA Database Fundamentals | MCTS Windows Apps | MCTS Windows Network | MCP 2003
    sqldicas@outlook.com
    http://sqldicas.com.br
    Se a resposta foi útil de alguma forma, classifique como resposta ou vote como útil.

    segunda-feira, 28 de outubro de 2013 20:26
    Moderador
  • Tenho 10 Mb de upload ( nao dedicado)
    terça-feira, 29 de outubro de 2013 10:15
  • Faz um teste Felipe.

    Habilita a compactação do seu backup, veja que tamanho ele fica e testa a transferência dele pra saber quanto tempo demora.

    Posso te ajudar em algo mais?

    Abraços,


    Luiz Mercante
    MCITP SQL 2008 | MCTS SQL 2008 | MTA Database Fundamentals | MCTS Windows Apps | MCTS Windows Network | MCP 2003
    sqldicas@outlook.com
    http://sqldicas.com.br
    Se a resposta foi útil de alguma forma, classifique como resposta ou vote como útil.

    terça-feira, 29 de outubro de 2013 15:43
    Moderador