none
Replicação Merge RRS feed

  • Pergunta

  • Bom Dia

    Tenho um servidor A com Sql Server 2008 Enterprise e outro B com Sql Server Express.

    Preciso Replicar dados do Servidor B (Express) para o Servidor A (Enterprise), como o servidor B é Express não poderá publicar, só poderá ser assinante, mesmo assim para atender esta necessidade montei uma replicação merge entre o Sql Server Enterprise e o Sql Server Express assumindo que a aplicação só conectará no Servidor Express e como é bidirecional (merge), mesmo assim os dados serão enviados para o Enterprise.

    O Servidor B express enviará os dados para o Servidor A e sofrerá expurgo de informações maiores que 90 dias (Para não estourar o tamanho do express 4GB).

    O Servidor A Enterprise será somente para consulta e o Servidor B somente para enviar dados. O delete não será propagado na replicação, com configuração @delete_tracking = 'True', pois se houver delete no B express  não será executado no Enterprise A.

    O @identityrangemanagementoption ficará como manual pois os dados só serão inseridos no express e propagados por ele.

    A opção @pre_creation_cmd ficará como 'none' pois no momento do snapshot (caso eu precise executar) (Só poderei rodar a partir do (Enterprise A) e não quero que os dados no Express sejam Alterados).

    Bom... onde estão os problemas então?

    O problema é o seguinte, digamos que eu remova toda a configuração da replicação no Express e no Enterprise e a recrie.

    Servidor A Enterprise = tabela nomes com código de 1 a 1000

    Servidor B Express = tabela nomes com código de 1 a 1000

    Eu recrio a replicação toda e quando rodo o snapshot passo por problemas de chave duplicada. Na verdade não  quero sobrescrever os dados do servidor B (express) só quero manter a tabela como está e ressincronizar, como poderei fazer a replicação merge funcionar desta forma?

    Esta é a dúvida, fazer replicar tem sido fácil, mas e se eu precisar gerar algum snapshot não gostaria de sobrescrever a tabela, na verdade gostaria de deixá-la como está. Se no Enterprise (A) houverem um milhao de linhas não gostaria de replicá-las para o express, sem esquecer que o express só cresce até 4gb. Lembrando que é só para passar as informações do Express para o Enterprise e se houver expurgo no express o comando de delete não será refletido no Enterprise, este é  o cenário que preciso manter, preciso que o snapshot não distorça este cenário, peço uma orientação quanto isso.

    Maurício

    segunda-feira, 22 de setembro de 2014 12:46

Respostas

  • Tulio

    Você me ajudou tremendamente. Muito obrigado.

    Vou ir pelo caminho a seguir.

    1-Informar que a replicação merge não é a mais adequada, nos testes que fiz tudo foi replicado, porém não é o indicado pela Microsoft para este cenário.

    2-Sugerir uma replicação transacional a partir de um Enterprise.

    3-Se não houver permissão para utilizar este Enterprise por questões de licença, pois desconfio que é licença casada com outra aplicação, então como ultimo recurso utilizar Linked Server.

    4-Se houver restrição de licença me parece que irão sugerir usar mysql, replicação por ele. O problema é que nunca trabalhei com Mysql, rs, daí nem sei se vai atender bem.

    terça-feira, 23 de setembro de 2014 14:11

Todas as Respostas

  • Maumauboy,

    Acho que você esta usando o tipo de replicação errada.... se somente seu express irá atualizar o enterprise, então o tipo de replicação seria transacional... e não merge.

    Quanto ao identity no express, se você apagar as tabelas usando "delete", eles continuaram com a sequencia correta.


    Tulio Rosa | http://tuliorosa.com.br | Se resolveu seu problema, marque como resposta ou vote

    segunda-feira, 22 de setembro de 2014 12:59
  •  

    Eu também usei como 'delete' no @pre_creation_cmd e resolveu mas na verdade se os dados do Enterprise estiverem incompletos ele acaba por popular o Express com todos os dados do Enterprise e ainda por cima incompletos. Mesmo que as tabelas fiquem iguas em ambos não é o que eu gostaria.

    Só quero levar o excedente do express para o Enterprise. Infelizmente quero usar a merge como um "a lá transacional", um workaround para vencer a limitação do express.

    Tentei montar a transacional mas o express não pode atuar como Publicador nem Distribuidor, até consegui colocá-lo como Publicador no distribution do enterprise, mas quando rodo o wizard no express sou avisado que a edição não suporta como publicador.

    Por isso escolhi a merge para atender esta necessidade, podem me ajudar nesta questão?

    Gostaria que o snapshot não alterasse nenhum dado no express, pois se eu precisar reiniciar a replicação serei forçado a rodar um snapshot, só gostaria de sincronizar o express com o enterprise em caso de restabelecer a replicação se possível sem um snapshot que sobrescreva dados.

    Grato,

    Maurício




    • Editado maumauboy segunda-feira, 22 de setembro de 2014 14:36
    segunda-feira, 22 de setembro de 2014 13:41
  • São muitas tabelas que você esta usando nessa replicação "merge" ?

    Se forem poucas você poderia manter tabelas intermediarias na replicação, apos sincronizar você copia os dados das tabelas intermediarias para as definitivas (no enterprise).

    hum... confuso né.... vamos ao exemplo:

    A sua tabela no enterprise é a tabela A, crie uma tabela A2 com a mesma estrutura e dados no enterprise mesmo, faça o merge entre a tabela A2 com a do express.

    Sempre que sincronizar as tabela A2 com a do express, você atualiza a tabela A com a A2 através de algum script.


    Tulio Rosa | http://tuliorosa.com.br | Se resolveu seu problema, marque como resposta ou vote

    segunda-feira, 22 de setembro de 2014 17:28
  • São 40 tabelas.

    Havia pensado nisso também rs! Inclusive usando o script de merge para isso, quando os dados fossem inseridos na definitiva eu simplesmente apagaria os dados da intermediária, inclusive faria uma view realizando o union das duas para que entre o intervalo desta carga o cliente não perdesse informações pois consultaria pela view. mas tudo isso com @delete_tracking = 'true' para não replicar e apagar os dados no express.

    Quanto ao snapshot eu deixaria o parametro @pre_creation_cmd = 'none' para que não sejam excluidas e incrementadas as informações no express.

    Depois no express (somente no express) eu executaria o comando sp_addtabletocontents para incrementar com os valores inseridos enquanto a replicação estava parada.

    Na verdade eu queria evitar usar a tabela intermediária rs! Porém me parece que sem essa forma de tratar os dados não vai funcionar! Caso contrário no snapshot teremos problemas de chave duplicada rs

    Eu ainda vou te fazer uma pergunta crucial depois disso?! Mas até então o que acha, será que é muito crítico sustentar essa solução, arriscado, me dê a sua opinião?

    Lembrando o Enterprise ficará como um histórico definitivo e o express será um intermediário que armazenará registros dos últimos  90 dias, ou seja sofrerá expurgo, porém com @delete_tracking o expurgo não será replicado. Porém será necessário que as informações sejam inseridas no destino em intervalos de poucos segundos. Qual solução seria mais adequada para um merge de poucos em poucos segundos. Realizar isso usando o express me preocupa.


    • Editado maumauboy segunda-feira, 22 de setembro de 2014 18:04
    segunda-feira, 22 de setembro de 2014 17:56
  • Maumauboy,

    40 tabelas em replicação merge acho muito, não faria essa replicação não.

    Me passa mais algumas informações:

    . São 40 tabelas, mas qual o volume de registros a serem atualizados, 1.000 ... 10.000 !?

    . Essa atualização tem que ser em que frequência, 1 vez ao dia ?

    . Seus usuários tem que acessar as informações nos dois servidores ao mesmo tempo ?


    Tulio Rosa | http://tuliorosa.com.br | Se resolveu seu problema, marque como resposta ou vote

    segunda-feira, 22 de setembro de 2014 19:57
  • -A quantidade registros não sei ainda, estimo que 1000.

    -A atualização de algumas destas tem que ser em intervalo de segundos, de outras uma vez ao dia.

    -Os usuários só vão ler as informações no servidor de destino (Por isso os registros não podem ser expurgados nele).

    Grato

    segunda-feira, 22 de setembro de 2014 20:30
  • -A quantidade registros não sei ainda, estimo que 1000.

    -A atualização de algumas destas tem que ser em intervalo de segundos, de outras uma vez ao dia.

    -Os usuários só vão ler as informações no servidor de destino (Por isso os registros não podem ser expurgados nele).

    Grato

    ok...

    Mas qual o motivo que você esta usando o Express para entrada de dados e o Enterprise para consultas ?

    Poque não utiliza somente o Enterprise ?


    Tulio Rosa | http://tuliorosa.com.br | Se resolveu seu problema, marque como resposta ou vote

    segunda-feira, 22 de setembro de 2014 20:38
  • Querem usar o enterprise somente para consulta e o express para entrada das informações, pelo que vejo é para evitar contenção no Enterprise, concorrencia.

    É possível fazer uma replicação transacional puxando os dados do express?, ou nos deparariamos com o mesmo problema?

    A unica forma que arrumei foi colocar um filtro no article onde o rowguid is null no caso de replicação merge, por esta ótica a replicação funcionaria e o snapshot não geraria chave duplicada rodando com sucesso porém quando eu insiro 1000 registros novos no express eles são replicados mas assim que a sincronização termina os registros desaparecem do express pois o retorno do merge não retorna nada afinal não haverá rowguid nulo.

    Resumindo: A cada sincronização os registros serão apagados do express mas no enterprise ficarão intactos e incrementados. Assumindo que só haverá inserção e nenhuma manipulação de dados posterior como updates por exemplo, pois se os dados já foram sincronizados o update não terá nada o que atualizar a tabela ficará vazia.

    Porém um tablediff não faz mal a ninguém, se eu sustentar isso, terei que falar com o fornecedor para levantar melhor a origem e fazer uma query de comparação. Pois o express ficará sempre vazio após cada sincronização.




    • Editado maumauboy segunda-feira, 22 de setembro de 2014 21:33
    segunda-feira, 22 de setembro de 2014 20:57
  • Querem usar o enterprise somente para consulta e o express para entrada das informações, pelo que vejo é para evitar contenção no Enterprise, concorrencia.

    É possível fazer uma replicação transacional puxando os dados do express?, ou nos deparariamos com o mesmo problema?

    A unica forma que arrumei foi colocar um filtro no article onde o rowguid is null no caso de replicação merge, por esta ótica a replicação funcionaria e o snapshot não geraria chave duplicada rodando com sucesso porém quando eu insiro 1000 registros novos no express eles são replicados mas assim que a sincronização termina os registros desaparecem do express pois o retorno do merge não retorna nada afinal não haverá rowguid nulo.

    Resumindo: A cada sincronização os registros serão apagados do express mas no enterprise ficarão intactos e incrementados. Assumindo que só haverá inserção e nenhuma manipulação de dados posterior como updates por exemplo, pois se os dados já foram sincronizados o update não terá nada o que atualizar a tabela ficará vazia.

    Porém um tablediff não faz mal a ninguém, se eu sustentar isso, terei que falar com o fornecedor para levantar melhor a origem e fazer uma query de comparação. Pois o express ficará sempre vazio após cada sincronização.




    Seguinte....

    Entendi o que vocês estão querendo fazer, vou dar minha opinião pessoal sobre isso, outros DBA podem pensar diferente.

    O seu objetivo de fazer a entrada de dados no Express e as consultas no Enterprise para ter ganho de performance, mas utilizar replicação para fazer a sincronização de 40 tabelas praticamente em tempo real vai aumentar a complexidade no seu banco e não terá um ganho significativo.

    O que todo mundo esta fazendo atualmente e criando um servidor para entrada de dados e um ou mais de leitura utilizando o recurso AlwaysOn, mas os servidores utilizados usam a mesma versão, não sendo possível com o Express.

    No seu caso eu sugiro otimizar o banco e o sistema sem utilizar o Express.

    Mas se for continuar com esse projeto, não use a replicação... monte um script para fazer essa atualização, crie um "linked server" entre o Enterprise e o Express, e monte um script consultando, inserindo e apagando os dados, agende como JOB e deixe executando durante todo o tempo.

    Espero ter ajudado...


    Tulio Rosa | http://tuliorosa.com.br | Se resolveu seu problema, marque como resposta ou vote

    • Marcado como Resposta maumauboy terça-feira, 23 de setembro de 2014 12:07
    • Não Marcado como Resposta maumauboy terça-feira, 23 de setembro de 2014 12:08
    terça-feira, 23 de setembro de 2014 12:01
  • Bom Dia

    Infelizmente não temos Sql Server 2012. Somente 2008.

    Creio também que os linked servers são mais comuns em um caso deste, tentar utilizar o express como publicador é incomum e é propor uma solução que aparentemente a Microsoft não oferece para express.

    E se eu conseguir de alguma forma um outro servidor Enterprise Existente e uma replicação replicação transacional nele mandando para o outro Enterprise? Acha uma boa solução? Vou tentar convencer a empresa a utilizarem um enterprise para solução como replicação, o que acha? Sendo assim sendo um enterprise nem precisariamos fazer expurgo de dados de mais de 90 dias na origem.



    • Editado maumauboy terça-feira, 23 de setembro de 2014 12:24
    terça-feira, 23 de setembro de 2014 12:14
  • Bom Dia

    Creio também que os linked servers são mais comuns em um caso deste, tentar utilizar o express como publicador é incomum e é propor uma solução que aparentemente a Microsoft não oferece para express.

    E se eu conseguir de alguma forma um outro servidor Enterprise Existente e uma replicação replicação transacional nele mandando para o outro Enterprise? Acha uma boa solução? Vou tentar convencer a empresa a utilizarem um enterprise para solução como replicação, o que acha? Sendo assim sendo um enterprise nem precisariamos fazer expurgo de dados de mais de 90 dias na origem.


    Se você tiver dois servidores Enterprise fica melhor...

    Você falou que tem o Enterprise 2008, nessa versão você tem a funcionalidade "Database Mirroring", que replica toda a sua base em "tempo real" para consulta.

    Se conseguir a versão mais atualizada do SQL Server... 2012 ou 2014 você pode utilizar o recurso AlwaysON, segue o link com uma solução usando esse recurso:

    Link: http://social.technet.microsoft.com/wiki/pt-br/contents/articles/26463.balanceamento-de-carga-sql-server.aspx


    Tulio Rosa | http://tuliorosa.com.br | Se resolveu seu problema, marque como resposta ou vote

    terça-feira, 23 de setembro de 2014 12:26
  • Na database mirroring eu conseguiria deixar a segunda base online no 2008?Caso sim vou buscar fazer mirror seria bem mais interessante, ou é só no always on mesmo?

    terça-feira, 23 de setembro de 2014 12:59
  • Na database mirroring eu conseguiria deixar a segunda base online no 2008?Caso sim vou buscar fazer mirror seria bem mais interessante, ou é só no always on mesmo?

    Manumauboy,

    Passei uma informação errada para você... a base mirror não pode ser acessada, somente quando a principal da problema, ou seja, não tem como fazer consulta na base mirror.

    Esse é um recurso antigo, que será retirado das versões futuras do SQL Server, pois o AlwaysOn melhorou tudo.

    Na época eu precisei fazer consulta na base mirror e não teve jeito, tive que criar eu mesmo um script para isso, a solução foi restaurar o backup full com a opção STANDBY, com essa opção você consegue fazer consultas na base.... e para atualizar era só ir restaurando os log (fazia isso com um JOB), mas essa solução precisa de um tempo de "sincronização" maior, pois durante a restauração dos log os usuários não conseguiam fazer consultas... embora a restauração de log é rápida.


    Tulio Rosa | http://tuliorosa.com.br | Se resolveu seu problema, marque como resposta ou vote

    terça-feira, 23 de setembro de 2014 13:39
  • Tulio

    Você me ajudou tremendamente. Muito obrigado.

    Vou ir pelo caminho a seguir.

    1-Informar que a replicação merge não é a mais adequada, nos testes que fiz tudo foi replicado, porém não é o indicado pela Microsoft para este cenário.

    2-Sugerir uma replicação transacional a partir de um Enterprise.

    3-Se não houver permissão para utilizar este Enterprise por questões de licença, pois desconfio que é licença casada com outra aplicação, então como ultimo recurso utilizar Linked Server.

    4-Se houver restrição de licença me parece que irão sugerir usar mysql, replicação por ele. O problema é que nunca trabalhei com Mysql, rs, daí nem sei se vai atender bem.

    terça-feira, 23 de setembro de 2014 14:11