locked
Replicação Matriz-Filial e Filial-Matriz RRS feed

  • Pergunta

  •  

    Pessoal, to precisando fazer um esquema de replicação no SQL 2000 sendo q tenho1 banco na minha SEDE e outros 2, em 2 filiais(1 BD em cada).

    E nas filiais uso o MSDE 2000.

     

    O problema:

    Preciso puxar todos os dados das filiais, e alimentar este.

    Depois, enviar os dados deste BD atualizado, de volta para cada filial.

     

    Sei que a replicação é pra isto e sei fazer ela até certo nivel, mas não tenho a minima idéia de como fazer isto nesta situação.

    Alguem poderia me dar um luz, orientação, pesca(rsrs) ou até mesmo se tiver algum site q conteha instruções de como fazer isto?

     

    Desde já grato a todos.

     

     

    Emerson Machado

    domingo, 13 de janeiro de 2008 13:53

Respostas

  • O Ideal a fazer q que funcinou mesmo foi o MERGE.

    Mas tmq ter os seguintes detalhes para que de certo:

     

    - Quando isto for inciar, os BDs tem q estar exatamente iguais. Senão os BDs das filiais TRAVAM.

    - O merge faz uma REPLICAÇÃO SNAPSHOT INICIAL, depois é configurado a REPLICAÇÃO MERGE, em diversos horários.

    - A REPLICAÇÃO SNAPSHOT tem q ficar agendada OCASIONALMENTE, pra evitar inconsistencias, eu coloquei 1 vez por semana.

     

    Agora tá funcionando 100%

    domingo, 6 de abril de 2008 14:23

Todas as Respostas

  •  

    se puder dar uma olhada na SQL Magazzine, numero 40. caso tenho duvidas por entrar em contato pelo email

     

    mcolla@bol.com.br

     

     

    link da revista:

    http://www.devmedia.com.br/articles/viewcomp.asp?comp=6982&hl=

     

     

    Abs;

    segunda-feira, 14 de janeiro de 2008 10:45
  • Esta é um publicação meia-boca, e se quiser ler o resto inteiro, tem q ser assinante e pagar.

    Não conheço SQL 100%, mas o que conheço sempre esponho aqui sem restrições.

    Penso q aqui devemos compartilhar informações e soluções abertase não cobradas.

    domingo, 20 de janeiro de 2008 14:18
  •  

    Olá!!!

     

    De certa forma, concordo contigo. Em alguns momentos, não temos tempo o bastante para escrever uma solução completa. Fica mais rápido indicarmos um outro caminho que pode levar a solução.

     

    Sobre a sua questão, a replicação Merge vai resolver seus problemas.

     

     

    Com ela, serão replicadas as informações modificadas, além disso é possível fazer um filtro, de forma que os dados sejam enviados somente a filial específica. Tenho essa solução criada num cliente e funciona perfeitamente.

     

    Eu sugiro que abra o Books Online e procure por "merge replication [SQL Server replication], how it works" pelo index, vai encontrar descrição completa.

     

     

    Abraço!!!

    segunda-feira, 21 de janeiro de 2008 11:25
  • Amigo, seguindo a linha do Colla e do Alexandre, a replicação vai te atender sim, porém não entendi se você quer que as filiais sejam atualizadas?

     

    Caso sim, você pode utilizar um esquema de replicação Merge, caso não precise você pode usar uma replicação Transacional mesmo, lembrando que o MSDE aceita ser um subscriber, publisher ou distributor, porém existem algumas limitações em alguns esquemas de replicação.

     

    Segue um link: http://support.microsoft.com/default.aspx?scid=kb;en-us;324992

     

    Você sabe que deve publicar o database em seguida inscrever os subscribers correto?

     

    Se você tiver alguma dúvida específica no processo de montagem da replicação mande pra gente.

     

    Ok?

     

    Qualquer dúvida, estamos aí.

     

    Abraços,

     

    segunda-feira, 21 de janeiro de 2008 14:10
  • Eu consegui fazer, e usei a opção SNAPSHOT e funcionou atualizando bidirecionalmente.

    Mas tinha uma porção de particularidades q tavam dando erro no meu processo.

    Foram elas:

    - O usuarios q levanta o SQL Agent, não pode ser SERVIÇO, tem q ser um usuario cadastrado da rede, senão não serve.

    - Num servidor, tinha o MENAGER 2005 e o MSDE2000, as DLs e OCXs deste "MELAVAM" a replicação.

    - O diretório dos LOGs DEFAULT tem q ficar padrão como o da instalação, senão o MSDE não cria os BDs de REPLICAÇÃO.

    - A pasta compartilhada REPL tem q ser compartilhada e o nivel se segurança liberada manualmente.

    - Vc só consegue configurar uma maquina para ser PUBLISHER, pelo IP se na MENAGER q estiver fazendo o praocesso, ela também estiver cadastrada com o NOME DNS da rede.

     

    Como veem não basta só o WIZARD do MENAGER pra fazer funcionar não. Sinceramente me arrependo de ter indicado ao cliente o uso do MS-SQL ou do MSDE, pois os probelmas de replicação destes, também acontecem com o MS-SQL SERVER.

     

    Bom, mas futucando aqui e ali, consegui resolver. Agradeço a todos que me responderam e tentaram me ajudar.

    quinta-feira, 24 de janeiro de 2008 16:49
  •  

    Olá!!

     

    Não sei se é esta a intenção, mas o SNAPSHOT simplesmente faz um REPLACE da tabelas e qualquer outro objeto selecionado na replicação!!!

     

    Tenho vários clientes com soluções de replicação implementadas, e funciona perfeitamente, é basicamente questão de conhecer o recurso e suas funcionalidades.

     

    Como você mesmo disse, não basta somente o Wizard, tem que conhecer os detalhes envolvidos.

     

     

    Bom, pelo menos você conseguiu fazer funcionar.

     

    O mundo "DBA" tem muito de REDES, é preciso conhecer a questão da comunicabilidade entre serviços e hosts.

     

     

    Sempre que precisar de uma mão, estamos aqui.

     

     

    Grande abraço!!

    sexta-feira, 25 de janeiro de 2008 01:19
  • Valeu Alexandre!

    Mas deixa eu matar um dúvida com vc?

    Como vc sugeriria um replicação onde os dados precisaraim estar atualizados em AMBOS os LADOS de forma igual?

    SNAPSHOT, TRANSACTIONAL ou MERGE?

    sexta-feira, 25 de janeiro de 2008 17:53
  •  

    Podemos dizer que no SQL 2000, os recursos disponíveis ainda são um pouco limitados, mas, a melhor alternativa ainda seria a utilização do MERGE. É claro, mesmo com o MERGE existe uma latência, um intervalo entre as atualizações. Mas este tempo é configurável.

     

    No SQL 2005, usando o TRANSACTIONAL, foi introduzido um novo conceito chamado "Peer-to-Peer Topology", que permite a utilização de database de forma distribuida, desde que o acesso e modificação de dados seja "particionado", ou seja, um tipo ou grupo de dados é alterado em um servidor. Por exemplo, se você tiver a matriz e duas filiais, cada um atualiza os seus dados, mas recebe a atualização dos outros servidores.

     

    Resumindo, se eu fosse você, analisaria a utilização do merge com uma pequena latência, isso se as suas regras de negócio permitirem. Isso vai depender de qual tipo de dado que se trabalha, digamos, um estoque central não funcionaria muito bem, já que os mesmos dados são alterados em vários lugares. Mas, se cada local tiver um controle de estoque e os outros apenas precisam saber da quantidade de estoque disponível no outro local, daria para tranquilamente usar o Merge.

     

    Qual a implementação que você quer fazer??

     

     

    Abraço!!

    sexta-feira, 25 de janeiro de 2008 19:10
  • O Ideal a fazer q que funcinou mesmo foi o MERGE.

    Mas tmq ter os seguintes detalhes para que de certo:

     

    - Quando isto for inciar, os BDs tem q estar exatamente iguais. Senão os BDs das filiais TRAVAM.

    - O merge faz uma REPLICAÇÃO SNAPSHOT INICIAL, depois é configurado a REPLICAÇÃO MERGE, em diversos horários.

    - A REPLICAÇÃO SNAPSHOT tem q ficar agendada OCASIONALMENTE, pra evitar inconsistencias, eu coloquei 1 vez por semana.

     

    Agora tá funcionando 100%

    domingo, 6 de abril de 2008 14:23