none
Replicacao de banco de dados RRS feed

  • Pergunta

  • Estou com a necessidade de replicar as bases de dados de produção para um site de contingencia, sendo que os dois sites terão que ficar disponiveis, isto é, nos dois sites haverá leitura e escrita nas bases de dados ao mesmo tempo, com isso a pergunta, existe alguma forma de realizar isso sem ser por "merge replication"?

     

    Hoje eu tenho o SQL Server 2000 instalado e sei que no 2000 não tenho para onde fugir, mas no 2005 existe algum milagre para fazer isso? Senão tenho outra duvida, a replicação do 2005 é muito diferente do 2000?

     

    Um dos meus maiores problemas para realizar a replicação do tipo merge esta na base ERP que temos, pois são 5000 tabelas e todas só possuem indice unico, não tem pk. Alguem tem alguma sugestão?

     

    Desde já agradeço a ajuda,

    Otávio Amaral.

    segunda-feira, 21 de janeiro de 2008 12:11

Todas as Respostas

  • Amaral,

     

    Primeiramente estes dados replicados serão alterados?

    segunda-feira, 21 de janeiro de 2008 12:48
    Moderador
  • Para ter as duas bases totalmente operacionais, vc terá que usar a replicação merge.

     

    Antes de implementar o procedimento analise o seguinte: todas as 5000 tabelas estão realmente em uso?

     

    Digo isso, pois trabalho com uma empresa que desenvolve um ERP para a área textil, no modelo de dados temos por volta de 1100 tabelas, mas em uso real nos clientes apenas 500 delas. Sendo que no máximo 15 tabelas são de grande movimentação.

     

    1100 já é um absurdo, agora 5000...com certeza não estão todas em uso...

     

    segunda-feira, 21 de janeiro de 2008 12:52
  • Bom Dia,

     

    Acredito que a replicação irá trazer um imenso overhead administrativo (entre outras coisas) e talvez você devesse avaliar outras soluções que envolvessem hardware, storage, ou até a contratação de um DataCenter para hospedar sua solução (apenas uma idéia inicial, não tenho condições de afirmar se é viável ou não).

     

    Se você puder garantir que não haverá conflitos, ou seja, o que um usuário cadastrar em um site não será cadastrado em outro site, a replicação transacional com Imediatte Subscription ou Queue Updating são soluções interessantes para o seu caso. A replicação transacional exige uma chave primária, mas se você já possui um índice Unique pode ser que ela funcione (índices unique e chaves primárias tem muitas características em comum). Se os índices são colocados sobre colunas NOT NULL, você poderia dropar os índices e transformá-los em chaves primárias (em termos físicos estaria trocando seis por meia dúzia).

     

    No SQL Server 2005 temos alternativas interessantes para esse caso como a replicação P2P (disponível apenas na Enterprise) e a replicação Transacional Bidirecional. No entanto, todas essas soluções são dedicadas a quando há ausência de conflito. Se conflitos forem ocorrer de forma esperada, ou seja, é inerente ao negócio que eles ocorram, a única alternativa será lidar com a replicação Merge ou pensar em outra solução.

     

    No caso de optar pela replicação, a colocação do colega Alex sobre analisar as tabelas utilizadas é imprescindível.

     

    [ ]s,

     

    Gustavo

     

    segunda-feira, 21 de janeiro de 2008 13:24
  • Sim, os dados são alterados nos dois sites. Acredito que raramente poderá ocorrer conflitos, porem não posso afirmar porque nunca trabalhei com replicação merge e muito menos P2P, no caso de tabelas com identity por exemplo, quando ocorre inserção na mesma tabela nos dois lados, como o SQL trata isso???

     

    Referente ao ERP, com certeza não são todas as tabelas em uso, mas mesmo assim terei um trabalho gigantesco para descobrir quais estão em uso e no final criar uma replicação para umas 1000 tabelas por exemplo!!!!! Acho que não daria certo pela quantidade, ate porque a replicação merge obriga a criação do campo rowid alem da pk, correto? A P2P também? Seria mais fácil a P2P?

     

    Já pensamos em outras soluções, mas nenhum atende, pois a premissa é termos os dois sites ativos e com a mesma posição. A replicação de storage por exemplo não dá, pois um deles tem que estar parado, sendo ativado apenas quando o outro for desativado, conceito de failover. Aqui também temos base Oracle e iremos implementar o DataGuard que atende a nossa necessidade, mantendo os bancos dos dois sites ativo, realizando read-write e replicando entre si.

     

    Muito obrigado pela ajuda de vocês e estou aceitando sugestões... rs

    Otávio Amaral

    terça-feira, 22 de janeiro de 2008 12:03
  • Será preciso dividir as faixas de utilização em cada tabela.

     

    Ex.: Tabela A com Identity

    Publisher - trabalha com a faixa de 1 a 100.000

    Subscriber - trabalha com a faixa de 100.001 a 200.000

     

     

    Sobre os conflitos a Replicação Merge pode ser configurado para validar os dados por colunas, diminuindo o trafego de rede e os conflitos, pois somente se houver atualização na mesma coluna o serviço de replicação irá gerenciar o conflito.

    É possivel também definir que irá prevalecer (gerenciamento de conflito automatico - padrão) se é o Publisher ou o Subscriber (por padrão é o Publisher).

    terça-feira, 22 de janeiro de 2008 12:15
  • Uma outra duvida, no caso de ocorrer conflito existe alguma forma do usuário saber que a transação que ele comandou não foi realizada? Principalmente no caso de prevalecer um lado, existe algum aviso ao usuário?

    terça-feira, 22 de janeiro de 2008 13:22
  • não, vc pode consultar algumas tabelas da replicação para ver o que ocorreu, mas o usuário não é notificado no momento do conflito se vc usar o gerenciador automático.

     

    se existir eu não conheço uma configuração que possa fazer isso.

     

    terça-feira, 22 de janeiro de 2008 14:44