none
Replicação de dados SQL Server 2008R2 - Log Shipping, Replication ou Database Mirroring? RRS feed

  • Pergunta

  • Possuo o seguinte cenário, possuo um "DW" que precisa ser replicado para servidores de outras cidades para um acesso mais performático por conta de rede.

    1. Existe um JOB que faz cargas nestes DW através de consultas no transacional.
    2. Este JOB é agendado, mas em alguns momentos do mês é necessário fazer esta carga em alguns horários específicos manualmente.
    3. A carga será feita no servidor do principal (RJ).
    4. Preciso que sempre que acabe este JOB (carga), as bases das outras cidades sejam replicadas.

    Estive lendo sobre o Log Shipping e me pareceu ser um recurso que me atenderia. Pelo que entendi o processo de Log Shiping cria um JOB para Backup do servidor principal(RJ), um JOB para para a cópia do arquivo de backup e um JOB para a restauração do arquivo nos servidores secundários(outras cidades). E ao invés de agendar estes JOBs, eu poderia executa-los, através de linha de comando, em steps ao final do JOB de carga, correto? Assim qualquer execução do JOB de carga, seja automática(agendada) ou manual, as bases seriam replicadas ao final da carga.

    Gostaria de saber se esta seria a melhor solução no meu caso.

    Att,

           Igor Auler.


    Igor Auler

    terça-feira, 15 de janeiro de 2013 16:35

Respostas

  • Correto Igor, o Log Shipping é justamente para deixar tudo automatizado e não precisar mais da intervenção sua para iniciar ou parar a execução de um Job e ser uma solução de alta disponibilidade, a partir do momento que esses objetivos não são os pontos centrais do negocio você pode partir para a sua segunda alternativa de criar os jobs de backup conforme sua necessidade.

    Espero que tenha lhe ajudado.

    Se a resposta foi útil, classifique-a.


    Att,
    Marcos Freccia [MTA|MCTS|MCITP|MCT SQL Server 2008]
    Blog|Twitter
    Assine também os feeds clicando aqui

    • Marcado como Resposta Igor Auler quinta-feira, 17 de janeiro de 2013 13:04
    quinta-feira, 17 de janeiro de 2013 12:25

Todas as Respostas

  • Olá Igor,

    Database Mirroring não te atende, pois a base no servidor secundário vai ficar indisponível para consultas.

    Log Shipping é uma boa estrategia, mas se você for replicar para mais de um servidor essas informações você terá latência de rede da mesma maneira.

    Acho que uma boa alternativa seria uma replicação peer-to-peer, aonde você replica para um único lugar e desse segundo ponto ele será replicado para os demais servidores de SQL, mas ela possui algumas restrições como por exemplo, tabelas sem primary key não podem ser replicadas entre outros problemas.

    Uma pergunta que você deve se fazer é: De quanto em quanto tempo você precisa dessa informação nos outros servidores? Isso sim, vai te ajudar a dimensionar qual das duas features você irá precisar.

    Se a resposta foi útil, classifique-a.


    Att,
    Marcos Freccia [MTA|MCTS|MCITP|MCT SQL Server 2008]
    Blog|Twitter
    Assine também os feeds clicando aqui

    quarta-feira, 16 de janeiro de 2013 11:17
  • Bom dia Marcos,

                    esta replicação deverá acontecer todos os dias de madrugada por um processo agendado, porem, algumas vezes, cerca de 3 à 5 vezes no mês, será feita durante o dia manualmente, de acordo com a demanda.

                    Hoje temos o seguinte problema:

    • Nosso banco transacional está no RJ;
    • Nosso DW está em SP;
    • A carga via linked server, entre SP e RJ, dura 1:30hs fora do expediente e 6hrs durante o expediente;
    • A carga durante o expediente estava consumindo toda banda da rede do RJ e degradando a internet da filial;
    • Replicamos o servidor de DW no RJ e vimos que esta carga demora de 5 à 10 minutos quando os servidores estão na mesma localidade, tanto durante quanto fora do expediente;
    • Logo a solução encontrada foi trazer esta base de DW para o RJ e replica-la para as demais regiões, pois se apenas trouxéssemos esta base para o RJ e não a replicássemos, teríamos o mesmo problema de performance no acesso das pessoas de fora do RJ ao DW. (Isto já foi testado)

    Quanto a parte de Log Shipping ter a mesma latência de rede, eu não entendo o porque, já que a unica transferência por rede que terei será de um arquivo de backup, que pode ser feito via FTP, e mesmo que fosse por rede seria muito mais rápido que um processo de ETL gigantesco.

    Quanto ao processo peer-to-peer eu não conheço, mas logo de cara já posso dizer que não me serve, visto que esta base possui tabelas sem PKs.

    Att,

        Igor Auler.


    Igor Auler

    quarta-feira, 16 de janeiro de 2013 13:12
  • Olá Igor,

    O Log Shipping funcionará automaticamente, ou seja, você iniciando esse processo na mão estará exposto a mais problemas.

    Outro detalhe é que você não conseguirá utilizar o FTP para o Log Shipping, no máximo os backups vão para uma pasta compartilhada. Vale lembrar que o Log Shipping também deixa sua base de dados inoperável, uma vez que o Log Shipping é uma tecnica de alta disponibilidade e não de replicação de dados, o que são coisas diferentes..

    Se a maneira de transferir arquivos para esse servidor é através de FTP apenas, você terá que utilizar o Integration Services para tal tarefa.

    Você poderia também pensar em automatizar uma serie de Jobs para realizar essa copia.

    Se a resposta foi util, classfique-a


    Att,
    Marcos Freccia [MTA|MCTS|MCITP|MCT SQL Server 2008]
    Blog|Twitter
    Assine também os feeds clicando aqui

    quarta-feira, 16 de janeiro de 2013 13:47
  • Olá Marcos,

               pelo que eu entendi o Log Shipping cria 3 JOBs:

    • Um para fazer o backup da base principal;
    • Outro para copiar o arquivo de backup para os servidores secundários;
    • E outro para restaurar o backup nos servidores secundários;

    Estou correto?

    Não gosto do integration service, por conta de manutenção e transparência, prefiro fazer meus códigos a mão, coloca-los em procedures e agenda-los pelo SQL Agente! O processo de ETL é feito por um JOB com 15 Steps, onde cada Step carrega uma área do DW.

    O que eu pensei em fazer foi:

    • Criar um 16º Step que executasse estes 3 JOBs criados pelo processo de Log Shipping, via linha de comando.

    EXEC msdb.dbo.sp_start_job N'<Nome do JOB>';

    GO

    • Porque eu não preciso de uma replicação agendada e sim que a base seja replicada SEMPRE que alguns processos (JOBs) terminem.

    Vamos supor que eu tenha 3 JOBS de ETL, e alem de cada 1 possuir um agendamento em horários diferentes, eles também são executados manualmente algumas vezes no mês. E TODAS AS VEZES que estes JOBs terminarem a carga, eu preciso que a base seja replicada para as outras localidades. Visto que esta base é uma base apenas para consultas, e o único modo de inserção de dados é via estes processos (JOBs).


    Igor Auler

    quarta-feira, 16 de janeiro de 2013 14:48
  • Igor,

    Ele também cria um quarto job para apagar os arquivos de backup antigos.

    Se você vai agendar manualmente e disparar manualmente esse job, não entendo e também não vejo a necessidade de utilizar o log shipping, pois aqui ele seria totalmente desnecessário. Para mim ainda vale a regra de você mesmo criar as procedures de backup full, e de log, de copia dos arquivos e de restore.

    Alguém vai consultar essa base foi replicada nas outras cidades? Se sim, você não pode se esquecer que ao final precisa deixar a base online novamente. 

    Se a resposta foi útil, classifique-a


    Att,
    Marcos Freccia [MTA|MCTS|MCITP|MCT SQL Server 2008]
    Blog|Twitter
    Assine também os feeds clicando aqui

    • Marcado como Resposta Igor Auler quarta-feira, 16 de janeiro de 2013 15:57
    • Não Marcado como Resposta Igor Auler quarta-feira, 16 de janeiro de 2013 17:44
    quarta-feira, 16 de janeiro de 2013 15:25
  • Marcos,

             a primeira coisa que pensei foi em criar as procedures para Backup, Copia dos arquivos para os servidores secundários e restore destes arquivos. Como conhecia o processo de Log Shipping por alto, e nunca havia testado, resolvi estudar sobre o assunto e testar a funcionalidade, mas pelo visto vou terminar na minha ideia inicial rs.

            O "TCHAN" do Log Shipping é a replicação agendada dos dados, correto? A partir do momento que não vou agendar esta replicação e vou precisar fazer esta replicação após alguns processos, o melhor é criar o processo manualmente, correto?

            Existe outra ferramenta de replicação?


    Igor Auler


    • Editado Igor Auler quarta-feira, 16 de janeiro de 2013 17:28
    quarta-feira, 16 de janeiro de 2013 16:44
  • Correto Igor, o Log Shipping é justamente para deixar tudo automatizado e não precisar mais da intervenção sua para iniciar ou parar a execução de um Job e ser uma solução de alta disponibilidade, a partir do momento que esses objetivos não são os pontos centrais do negocio você pode partir para a sua segunda alternativa de criar os jobs de backup conforme sua necessidade.

    Espero que tenha lhe ajudado.

    Se a resposta foi útil, classifique-a.


    Att,
    Marcos Freccia [MTA|MCTS|MCITP|MCT SQL Server 2008]
    Blog|Twitter
    Assine também os feeds clicando aqui

    • Marcado como Resposta Igor Auler quinta-feira, 17 de janeiro de 2013 13:04
    quinta-feira, 17 de janeiro de 2013 12:25
  • Olá Igor

    Se suas bases que estão nos servidores de outras cidades tem a necessidade de serem atualizadas constantemente e não podem ficar fora ar, o recomendado é realmente Transactional Replication.

    Agora se suas bases não tem a necessidade de serem atualizadas constantemente e podem ficar indisponíveis uma vez por dia ou quantas vezes o job de restore for configurado, você pode usar Log Shipping.

    Mirror não dá para você utilizar, o conceito de Mirror é High Performance, a base Mirror fica em Restoring.

    Qualquer dúvida estou a disposição.


    Keny Maciel da Silva
    DBA SQL-Server ITGROUP
    MCTS SQL Server 2008 Implementation and Maintenance
    Email: kenymaciel@gmail.com

    quinta-feira, 17 de janeiro de 2013 19:00
  • Olá Keny,

    • (Transactional) não serve para mim, visto que a base que quero replicar possui tabelas sem chaves primarias e as cargas são grandes, logo causaria um grande consumo de rede.
    • (Snapshot Replication)  não serve para mim, pois a base possui um alto volume de dados e eu preciso de uma baixa latência na replicação dos dados;
    • (Merge)  não serve para mim, pois apenas um servidor será atualizado, os outros servirão apenas como leitura.

               Depois destas conversas e de algumas leituras, optei por eu mesmo criar procedures para "Backup da base no servidor primário", "Copia do arquivo de Backup para os servidores secundários" e "Restore dos servidores secundários", e colocarei a execução destas procedures ao final dos processos de carga do DW.

                Estou pensando primeiramente em testar isto com um Backup Full, mas caso demore muito para fazer o backup, transferir o arquivo e restaurar as bases, tentarei otimizar da seguinte forma:

    1. Vou criar um plano de manutenção diário que fará o backup full e já transferirá este arquivo para todos os servidores secundários.
    2. Ao final da carga do DW em vez de fazer um Backup full, vou fazer um backup differential, transferi-lo para os servidores secundários e depois restaurar as bases com o Backup full + o differential. (O que diminuirá o tempo de backup e transferência do arquivo para os servidores secundários.)

    Caso tenha alguma ideia melhor, estou aberto a sugestões.

    Att,


    Igor Auler

    quinta-feira, 17 de janeiro de 2013 20:42