locked
Merge Replication - SQL Server 2008 R2 RRS feed

  • Pergunta

  • Boa tarde Pessoal,

    Atualmente em um ambiente de produção, tenho um datacenter e tres ambientes remotos, todos interligados com VPN ao datacenter, onde tenho uma base replicadas para todas as instâncias.

    Base datacenter <=> Remoto 01

    Base datacenter <=> Remoto 02

    Base datacenter <=> Remoto 03

    -------------------------------------

    Meu problema é que em algums processos de replicação estão acontecendo alguns conflitos, que não são justificaveis, levando em consideração que a unica base de dados que é utilizada é a base "Base datacenter"

    -------------------------------------

    O merge agent é executado somente uma vez por dia para cada subscription, e não são executados ao mesmo tempo.

    ------------------------------------

    A causa dos conflitos pode ser a execução da replicação em horários diferentes?

     


     

    Marcos Vinícius Oliveira Schardong

    MCTS – SQL Server 2008 / Forefront / Virtualization

    Técnico em Informática

     



    quinta-feira, 7 de abril de 2011 18:07

Respostas

  • Marcos,

    Sei que já faz tempo de seu post, mas o encontrei sem resposta final e decidi tentar ajudar em algum entendimento, mesmo que o problema já tenha sido resolvido.

    Se seus servidores destino são usados somente para consulta, você poderia alterar a configuração dos artigos replicados, colocando-os read-only no Subscriber.

    No SQL Server 2008 em diante, você pode configurar artigos para que sejam replicados e marcados somente leitura no servidor destino, para tal, acesse a tela de propriedades da publicação e entre na aba "Articles", selecione a tabela que você deseja e marque a opção: "Highlighted table is download-only".

    Após esta configuração, é necessário reiniciar apenas o Merge Agent.

    Observação: Para que funcione, é necessário que os servidores destino estejam configurados como "Clients" da replicação, pois caso estejam configurados como "Servers", mesmo que com uma prioridade baixa na resolução de conflitos configurada, você encontrará o mesmo erro.

    Este link pode ser usado como base inicial de leitura sobre este recurso:

    http://msdn.microsoft.com/en-us/library/ms151748(v=sql.90).aspx

    Obrigado.

    Att,

    Felipe de Assis

    terça-feira, 8 de novembro de 2011 17:17
  • Olá Marcos,

    Ao contrário do que você citou antes, estes conflitos são justificáveis sim. Note que pela própria mensagem de erro podemos notar que a causa do conflito foi o registro atualizado em mais de uma ponta entre um período de sincronização.

    Para saber mais como os conflitos são gerenciados pelo SQL, bem como, porque eles ocorrem, sugiro uma lida neste artigo.

    "Tipos de conflitos"

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

     

    Abraço,


    MCP – MCTS – MCITP – MCT SQL Server ADM / BI / Dev Sharepoint IBM Optim Certification http://demetriosilva.wordpress.com/
    quinta-feira, 10 de novembro de 2011 12:53

Todas as Respostas

  • Marcos,

    Bom, teóricamente precisamos entender que tipo de conflito você esta se deparando?

    Os dados estão sendo mesclados normalmente ou alguma quebra na integridade esta acontecendo?


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]
    quarta-feira, 13 de abril de 2011 17:42
    Moderador
  • Bom dia Junior Galvão,

     Não tive quebra de integridade, basicamente tenho conflitos entre o servidor "Base datacenter " e "Remoto 01", "Remoto 02", "Remoto 03".

    "The same row was updated at both 'CAPRICA.blumenau' and 'Razon.Blumenau'. The resolver chose the update from 'CAPRICA.blumenau' as the winner"

    "The same row was updated at both 'CAPRICA.blumenau' and 'CylonRyder.Blumenau'. The resolver chose the update from 'CAPRICA.blumenau' as the winner."

    "The same row was updated at both 'CAPRICA.blumenau' and 'astralqueen.Blumenau'. The resolver chose the update from 'CAPRICA.blumenau' as the winner."

    O servidor que é realizado update é o caprica. Os outros três são somente base de consulta offline. E o conflito de update do mesmo registro é gerado para todos os subscriptions.

     

    Obrigado a todos.

     


    Marcos Vinícius Oliveira Schardong MCTS – SQL Server 2008 / Forefront / Virtualization
    terça-feira, 19 de abril de 2011 11:35
  • Marcos,

    Sei que já faz tempo de seu post, mas o encontrei sem resposta final e decidi tentar ajudar em algum entendimento, mesmo que o problema já tenha sido resolvido.

    Se seus servidores destino são usados somente para consulta, você poderia alterar a configuração dos artigos replicados, colocando-os read-only no Subscriber.

    No SQL Server 2008 em diante, você pode configurar artigos para que sejam replicados e marcados somente leitura no servidor destino, para tal, acesse a tela de propriedades da publicação e entre na aba "Articles", selecione a tabela que você deseja e marque a opção: "Highlighted table is download-only".

    Após esta configuração, é necessário reiniciar apenas o Merge Agent.

    Observação: Para que funcione, é necessário que os servidores destino estejam configurados como "Clients" da replicação, pois caso estejam configurados como "Servers", mesmo que com uma prioridade baixa na resolução de conflitos configurada, você encontrará o mesmo erro.

    Este link pode ser usado como base inicial de leitura sobre este recurso:

    http://msdn.microsoft.com/en-us/library/ms151748(v=sql.90).aspx

    Obrigado.

    Att,

    Felipe de Assis

    terça-feira, 8 de novembro de 2011 17:17
  • Olá Marcos,

    Ao contrário do que você citou antes, estes conflitos são justificáveis sim. Note que pela própria mensagem de erro podemos notar que a causa do conflito foi o registro atualizado em mais de uma ponta entre um período de sincronização.

    Para saber mais como os conflitos são gerenciados pelo SQL, bem como, porque eles ocorrem, sugiro uma lida neste artigo.

    "Tipos de conflitos"

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

     

    Abraço,


    MCP – MCTS – MCITP – MCT SQL Server ADM / BI / Dev Sharepoint IBM Optim Certification http://demetriosilva.wordpress.com/
    quinta-feira, 10 de novembro de 2011 12:53
  • Demétrio,

    Concordo com você isso indica a existência de duas ou mais versões de um determinado registro ou melhor dizendo a existência de registros com valores distintos mas com a mesma chave em locais diferentes.

     


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]
    quinta-feira, 10 de novembro de 2011 22:41
    Moderador
  • Pessoal,

    Pensando no que foi dito pelo amigo Marcos, seria ruim sugerir que ao invés dele usar replicação utilizar simplismente o Merge?

    será que teriamos ganho ou perda em performance? e com isso talvez evitar estes problemas no update dos dados!

    abcs,

    Kleber Rafael


    • Editado Kleber Rafael quarta-feira, 6 de fevereiro de 2013 14:04
    quarta-feira, 6 de fevereiro de 2013 13:55
  • Kleber,

    Não acho uma boa saída, visto que, o esforço administrativo seria enorme.

    Abraço


    MCP – MCTS – MCITP – MCT SQL Server ADM / BI / Dev Sharepoint IBM Optim Certification http://demetriosilva.wordpress.com/

    quarta-feira, 6 de fevereiro de 2013 16:53
  • Boa tarde,

    Sei que o tópico já tem algum tempo, mas resolvi deixar uma reflexão: se os dados são atualizados em apenas uma réplica (Caprica) e os outros três seriam apenas assinantes (de leitura, não realizando nenhuma modificação na base primária, pelo que eu entendi), não seria mais interessante avaliar alternativas pro Merge Replication, como, por exemplo, a replicação Snapshot mesmo (dependendo do tamanho da base, se compensar) ou a Transacional?

    []'s


    - :)

    domingo, 15 de setembro de 2013 19:55