locked
"Tudo" sobre Replicação RRS feed

  • Pergunta

  • Amigos(as), muito bom dia

    Onde posso encontrar mais detalhes (não documentados ou oficiais) sobre replicação no SQL Server 2005? 
    A pergunta é um pouco generalizada, mas creio que replicação é um assunto longe de ser esgotado, principalmente para ambientes com bases 'gigantes'. Conheço bem a arquitetura, comportamento dos agentes, monitoramento, validação e etc, mas muitas outras coisas são complicadas de entender, parece uma caixa preta. 
    Vou exemplificar um pouco... Encontro situações onde existe "exigência" de reinicializar o(s) assinante(s) ou até mesmo executar um novo snapshot; se o assinante for inicializado usando snapshot existe um comportamento diferenciado se for inicializado sem snapshot; se adiciono ou removo artigos sou às vezes surpreendido com o pedido de um novo snapshot; apenas adicionar ou remover um campo de uma table replicada algumas vezes fez a replicação parar de funcionar, sendo necessário o "bendito" snapshot. Basicamente é isto amigos, creio ser a dúvida de muita gente, existem práticas não oficiais (blogs etc) explicando a manutenção de réplicas?

    Muito Obrigado

    Bruno Santos
    sábado, 6 de fevereiro de 2010 12:07

Respostas

  • Bruno,
    Essa duvida mostra que você quer saber como funciona e não somente como se faz. Isso é um bom indicativo para um excelente DBA. Dou antecipadamente meus parabéns!

    Todas essa situações podem de uma forma ou de outra serem "burladas" mas para isso você tem que ter a absoluta certeza do que você está fazendo. Por isso a Microsoft não tem recomendações publicas para certos procedimentos de replicação. Claro que não existe um passo a passo para resolver todos os problemas. Existe sim experiencia e conhecimento adquirido.

    Claro que cada ambiente de replicação tem suas particularidades. O meu por exemplo tem um pouco mais 250 servidores espalhados geograficamente pelo brasil onde tenho algumas publicações para 250 assinantes e os proprios assinantes também são publicadores. é uma grande arquitetura de replicação onde a propria microsoft brasil disse ser impossivel\problematica utilizando SQL Server. Mas o projeto foi para frente e hoje já está a dois anos em produção e de certa forma atendendo para o fim que foi implementada.

    Minhas recomendações:

    1. Não pense que você sabe tudo sobre replicação. tem muita coisa que não está no BOL.
    2. Deixa um pouco de lado o "Replciation monitor" aprenda a usar todos os agentes via console CMD.
    3. Leia um pouco sobre o protocolo WAL e veja o funcionamento do arquivo de log da base de dados e compreenda o mesmo.
    4. Começe pelo agente Log Reader "..\COM\logread.exe" e por ele que começa a "magica".
    5. Estude as tabelas utilizadas pela replicação. è lá onde você pode encontrar as respostas para suas duvidas.
    6. Não veja a replicação como parte do SQL Serve. Ela é uma aplicação que utiliza o SQL Server como base de dados.E você pode melhora-la para o seu ambiente.
    7. Faça muitos laboratorios e simule casos onde sua replicação falha e você tem que resolver no menor esforço possivel.
    8. Veja as procedures de replicação "sp_repl..." conheça em cada uma. elas um dia vão lhe ajudar muito.
    9. No mais é estudo e pratica mesmo. e para isso não tem segredo.
    Claro que existem situações que não tem jeito, onde o desenvolvedor(MS) "amarrou" para que fosse assim. Mas tem muitas outras que você consegue resolver.


    Espero que lhe ajude.

    []´s

    SQL Server - SQLOS
    http://leivio.spaces.live.com/blog/cns!A9C38548B0E679DB!236.entry
    MCP | MCTS | MCITP - DBA SQL Server Sênior http://leivio.spaces.live.com/ | http://br.linkedin.com/in/leivio
    sábado, 6 de fevereiro de 2010 20:21
  • Olá Bruno,

    As explicações do Leivio foram excelentes. No entanto, acredito que algumas de suas dúvidas existem no próprio BOL:

    1 - Encontro situações onde existe "exigência" de reinicializar o(s) assinante(s) ou até mesmo executar um novo snapshot;

    Não seria porque a assinatura expirou?

    2 - se o assinante for inicializado usando snapshot existe um comportamento diferenciado se for inicializado sem snapshot;

    Isso é previsível já que são procedimentos diferentes. Vea mais em:

    http://msdn.microsoft.com/pt-br/library/ms151705.aspx
    http://msdn.microsoft.com/pt-br/library/ms151795.aspx

    3 - se adiciono ou removo artigos sou às vezes surpreendido com o pedido de um novo snapshot;

    Qual valor fornecido para @force_invalidate_snapshot em sp_addmergearticle ( para merge ) ou sp_addarticle ( transacional ) ?
    Veja a descrição do BOL:

    [ @force_invalidate_snapshot = ] force_invalidate_snapshot

    Acknowledges that the action taken by this stored procedure may invalidate an existing snapshot. force_invalidate_snapshot is a bit , with a default of 0.

    0 specifies that adding an article does not cause the snapshot to be invalid. If the stored procedure detects that the change requires a new snapshot, an error occurs and no changes are made.

    1 specifies that adding an article may cause the snapshot to be invalid, and if subscriptions exist that would require a new snapshot, gives permission for the existing snapshot to be marked as obsolete and a new

    4 - apenas adicionar ou remover um campo de uma table replicada algumas vezes fez a replicação parar de funcionar, sendo necessário o "bendito" snapshot.

    São será porque está acontecendo erros de FKs, Contraints ou algo do tipo? Esse é um dos proncipais problemas para o topico acima.

    Espero ter ajudado.

    Abraços,

    Demétrio Silva


    Demétrio Silva
    quarta-feira, 17 de fevereiro de 2010 21:02

Todas as Respostas

  • Bruno,
    Essa duvida mostra que você quer saber como funciona e não somente como se faz. Isso é um bom indicativo para um excelente DBA. Dou antecipadamente meus parabéns!

    Todas essa situações podem de uma forma ou de outra serem "burladas" mas para isso você tem que ter a absoluta certeza do que você está fazendo. Por isso a Microsoft não tem recomendações publicas para certos procedimentos de replicação. Claro que não existe um passo a passo para resolver todos os problemas. Existe sim experiencia e conhecimento adquirido.

    Claro que cada ambiente de replicação tem suas particularidades. O meu por exemplo tem um pouco mais 250 servidores espalhados geograficamente pelo brasil onde tenho algumas publicações para 250 assinantes e os proprios assinantes também são publicadores. é uma grande arquitetura de replicação onde a propria microsoft brasil disse ser impossivel\problematica utilizando SQL Server. Mas o projeto foi para frente e hoje já está a dois anos em produção e de certa forma atendendo para o fim que foi implementada.

    Minhas recomendações:

    1. Não pense que você sabe tudo sobre replicação. tem muita coisa que não está no BOL.
    2. Deixa um pouco de lado o "Replciation monitor" aprenda a usar todos os agentes via console CMD.
    3. Leia um pouco sobre o protocolo WAL e veja o funcionamento do arquivo de log da base de dados e compreenda o mesmo.
    4. Começe pelo agente Log Reader "..\COM\logread.exe" e por ele que começa a "magica".
    5. Estude as tabelas utilizadas pela replicação. è lá onde você pode encontrar as respostas para suas duvidas.
    6. Não veja a replicação como parte do SQL Serve. Ela é uma aplicação que utiliza o SQL Server como base de dados.E você pode melhora-la para o seu ambiente.
    7. Faça muitos laboratorios e simule casos onde sua replicação falha e você tem que resolver no menor esforço possivel.
    8. Veja as procedures de replicação "sp_repl..." conheça em cada uma. elas um dia vão lhe ajudar muito.
    9. No mais é estudo e pratica mesmo. e para isso não tem segredo.
    Claro que existem situações que não tem jeito, onde o desenvolvedor(MS) "amarrou" para que fosse assim. Mas tem muitas outras que você consegue resolver.


    Espero que lhe ajude.

    []´s

    SQL Server - SQLOS
    http://leivio.spaces.live.com/blog/cns!A9C38548B0E679DB!236.entry
    MCP | MCTS | MCITP - DBA SQL Server Sênior http://leivio.spaces.live.com/ | http://br.linkedin.com/in/leivio
    sábado, 6 de fevereiro de 2010 20:21
  • Bruno,

    Sou obrigado a concordar com o Leivio, ele expressou todas as referências e procedimentos que devem ter antes de criar qualquer tipo de ambiente de replicação, é muito importante enteder como as coisas funcionam para depois fazer funcionar.
    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    • Sugerido como Resposta Anderson.fsa terça-feira, 8 de junho de 2010 18:33
    domingo, 7 de fevereiro de 2010 17:57
    Moderador
  • Olá Bruno,

    As explicações do Leivio foram excelentes. No entanto, acredito que algumas de suas dúvidas existem no próprio BOL:

    1 - Encontro situações onde existe "exigência" de reinicializar o(s) assinante(s) ou até mesmo executar um novo snapshot;

    Não seria porque a assinatura expirou?

    2 - se o assinante for inicializado usando snapshot existe um comportamento diferenciado se for inicializado sem snapshot;

    Isso é previsível já que são procedimentos diferentes. Vea mais em:

    http://msdn.microsoft.com/pt-br/library/ms151705.aspx
    http://msdn.microsoft.com/pt-br/library/ms151795.aspx

    3 - se adiciono ou removo artigos sou às vezes surpreendido com o pedido de um novo snapshot;

    Qual valor fornecido para @force_invalidate_snapshot em sp_addmergearticle ( para merge ) ou sp_addarticle ( transacional ) ?
    Veja a descrição do BOL:

    [ @force_invalidate_snapshot = ] force_invalidate_snapshot

    Acknowledges that the action taken by this stored procedure may invalidate an existing snapshot. force_invalidate_snapshot is a bit , with a default of 0.

    0 specifies that adding an article does not cause the snapshot to be invalid. If the stored procedure detects that the change requires a new snapshot, an error occurs and no changes are made.

    1 specifies that adding an article may cause the snapshot to be invalid, and if subscriptions exist that would require a new snapshot, gives permission for the existing snapshot to be marked as obsolete and a new

    4 - apenas adicionar ou remover um campo de uma table replicada algumas vezes fez a replicação parar de funcionar, sendo necessário o "bendito" snapshot.

    São será porque está acontecendo erros de FKs, Contraints ou algo do tipo? Esse é um dos proncipais problemas para o topico acima.

    Espero ter ajudado.

    Abraços,

    Demétrio Silva


    Demétrio Silva
    quarta-feira, 17 de fevereiro de 2010 21:02
  • Leivio e amigos, bom dia

    Primeiramente muito obrigado pelas informações, foram muito importante.

    Estou frequentemente estudando e simulando cenários 'complexos' de replicação, como comentei, já conheço boa parte da arquitetura e as práticas de implementação, configuração e administração mais comuns, o que falta é conhecer um pouco mais a "caixa preta", aquilo que não está explícito no BOL ou nos sites especializados no SQL Server.

    Continuo pesquisando e praticando, mas não sei se os amigos podem me ajudar numa dúvida que não quer calar: hoje no meu ambiente existem publicações onde consigo adicionar um artigo sem a necessidade de novo snapshot ou reinicializar o(s) assinante(s), basicamente incluo o artigo e não marco a opção "Generate the new snapshot now". Já as novas publicações criadas seguindo o procedimento padrão pedem sempre um snapshot ao adicionar novo(s) artigo(s) e se não marco a opção comentada acima a replicação pára. Onde posso identificar melhor este comportamento? É alguma modificação no agent log reader (ou distribution)? Imaginei que o mistério seria na propriedade immediate sync, mas pelas práticas que fiz é simplesmente para permitir aplicação de snapshot se um assinante não necessita.

    Muito Obrigado

     


    Bruno Santos
    sexta-feira, 19 de março de 2010 10:49