Replicação Merge e Constraints de limitação para Assinante

[Pandashop]

Olá pessoal!

Estou querendo tirar uma dúvida sobre a replicação Merge no SQL Server 2005. Fazendo testes percebi que quando criamos um campo de autonumeração numa tabela e replicamos a mesma para o assinante, a própria replicação cria umas contraints e dentre elas aparece uma que me deixou preocupado.

Tenho duas máquina virtuais com W2K3 SP1 no virtualbox 4.0.2 e ambos com SQL Server 2005 Enterprise SP1.

Ao fazer uma INSERÇÃO com uns 10.000 registros, como teste, no assinante, para ver a replicação no Publicador, apenas 2.000 registros são inseridos. Interessante que se eu fizer o contrário, do Publicador para o Assinante, os 10.000 registros passam sem problemas na mesma tabela. Outro teste que não deu problema foi atualizar 10.000 registros. Nas duas pontas testei e não ocorreu problema, todos foram atualizados sem erro.

Analisando o campo da tabela eu tenho as seguintes informações:

Nome do campo: id

tipo: INT IDENTITY (1, 1)

Constraint que aparece: ([id]>(500000) AND [id]<=(501000) OR [id]>(501000) AND [id] <=(502000))

Obs.:

O campo "id" está com a propriedade da Constraint: "Enforce For INSERTs And UPDATEs" como "Yes".

Bom até aí eu entendi que existe uma limitação de inserção do assinante para o publicador e a constraint limita em 2000 registros.

As perguntas são:

a.) para que ocorre esta limitação se são dois servidores, em apenas dois pontos(Publicador e Assinante)?

b.) Como faço para resolver isso sem ter que tirar o campo de autonumeração da tabela, e todos os registros entrarem normamente como acontece no publicador para o assinante?

c.) Alguém conhece alguma documentação que pudesse ajudar?

Agradeço muito a todos que puderem colaborar comigo. ;)

[fulvio]

Boa tarde Panda,

Nos seus testes, você pega uma tabela de origem e outra de destino (que seria o publicador e o assinante).

Os dados do publicador são replicados no assinante sem problemas (de origem para destino). Mas os dados do assinante não são inteiramente replicados... pode ser em decorrência dos dados que foram primeiramente inseridos no assinante (que são os 2000).

Para que os dados inseridos no assinante sejam replicados, o assinante terá que ser um publicador também.

Tente fazer os testes sem utilizar a identity. Depois acrescente a mesma!! :.)

Link de exemplos:

http://www.linhadecodigo.com.br/artigo/165...erver-2008.aspx

[Pandashop]

Boa tarde Panda,

Nos seus testes, você pega uma tabela de origem e outra de destino (que seria o publicador e o assinante).

Os dados do publicador são replicados no assinante sem problemas (de origem para destino). Mas os dados do assinante não são inteiramente replicados... pode ser em decorrência dos dados que foram primeiramente inseridos no assinante (que são os 2000).

Para que os dados inseridos no assinante sejam replicados, o assinante terá que ser um publicador também.

Tente fazer os testes sem utilizar a identity. Depois acrescente a mesma!! :.)

Link de exemplos:

http://www.linhadecodigo.com.br/artigo/165...erver-2008.aspx

Olá Fúvio, obrigado por responder.

Entre os testes que fiz do assinante para o publicador, na mesma configuração descrita acima, eu criei outra tabela com os mesmos campos de texto sem um campo de autonumeração e ao inserir uma massa de 10.000 registros, não ocorreram erros. A única situação que houve erros foi a desrita no meu texto acima.

Os testes éram importantes porque eu preciso avaliar uma replicação que já está em andamento, más não posso fazer esse tipo de teste logicamente e o problema da Constraint me deixou com dúvidas a respeito de uma grande movimentação de transações por parte do Assinante para o Publicador.

Sobre o texto indicado, não sei se esse recurso está disponível no SQL Server 2005. Creio que somente para consultas no 2008, ou não :blink: ?

[fulvio]

Bom dia Panda,

Desculpa, mas não prestei atenção que era o 2005. Para exemplos em 2005, você irá encontrar vários em inglês...

Dá uma olhada neste link. Na parte "Nota 1" há uma explicação bem interessante que poderá te ajudar. A atenção está bem voltada ao Indentity. você pode especificar para cada Assinante o intervalo do identity que irá manipular.

http://www.devmedia.com.br/post-339-Coluna...como-criar.html

Espero que ajude... :.)

[Pandashop]

Bom dia Panda,

Desculpa, mas não prestei atenção que era o 2005. Para exemplos em 2005, você irá encontrar vários em inglês...

Dá uma olhada neste link. Na parte "Nota 1" há uma explicação bem interessante que poderá te ajudar. A atenção está bem voltada ao Indentity. você pode especificar para cada Assinante o intervalo do identity que irá manipular.

http://www.devmedia.com.br/post-339-Coluna...como-criar.html

Espero que ajude... :.)

Caro Fulvio, obrigado pela indicação. A matéria é muito boa. Tão boa que li logo as 3 partes e achei bem interessante.

Sobre a nota do devmem, entendi o que é o range do campo indetificador, más ainda, não sei como se aplica a uma coleção de assinantes. Sei que o subscriber deve limitar o número de registros a serem incluidos dentro da faixa especificada, más não entendo porque ele não pula automaticamente para a faixa seguinte, após a faixa ter sido totalmente preenchida durante o processo de inclusão. Nos meus testes eu só consigo incluir 2000 registros. Pelo que diz o texto, deveria ser possível incluir todos os 10.000 registros, no caso então em 5 faixas diferentes automaticamente, más ele não resolve isso e simplesmente para. Fiz um novo teste em dois momentos diferentes em sequencia, mandei 1500 registros e em seguida 3000 registros. A primeira parte passou a segunda so até os 500 primeiros. Creio que o erro foi porque os registros da primeira parte ainda não haviam entrado no publicador. Refiz o teste monitorando agora a enttrada dos registros no publicador. Os primeiros 1500 passaram e dos 3000 que mandei logo em seguida só passaram 1500 em vez dos 2000. O que já me deixa mais confuso ainda. Refiz o teste esperando 1 minuto para enviar novamente os 3000 registros depois de ter enviado 1500, e mesmo com este tempo maior ele só enviou 1500. Parece que abaixou o tamanho do range. Olhando nas constraints da mesma tabela no publicador e no assinante apesar de terem ranges diferentes, o intervalo continua o mesmo daquele que postei. Cara acho que so desenhando vou conseguir entender o funcionamento deste tipo de campo na replicação :huh: . A boa notícia é que nem uma das tabelas replicadas, daquela replicação que estou monitorando e que me referi nos textos anteriores, possuem esse tipo de campo, ufa! :rolleyes:

Editado Fevereiro 22, 2011 por Pandashop

[fulvio]

Bom dia Panda,

É.... apesar de estar confuso, entendi o problema q está ocorrendo. Nunca vi ranges difererentes em execuções de testes iguais.

Vou dar uma olhada e fazer alguns testes para entender o que pode estar ocorrendo...

[Pandashop]

Bom dia Panda,

É.... apesar de estar confuso, entendi o problema q está ocorrendo. Nunca vi ranges difererentes em execuções de testes iguais.

Vou dar uma olhada e fazer alguns testes para entender o que pode estar ocorrendo...

Olá Fuvio, tive uma reunião com o pessoal do ERP da empresa e me disseram que algumas tabelas no futuro serão replicadas e estas estão todas com campos de autonumeração. Más como a experiência deles, comparada com a minha, é kilométrica, me disseram que existe uma forma de habilitar isso na replicação, sem passar pela constraint. Creio que talvez seja alguma forma de desabilitá-la. Sinceramente não sei, más já pedi de antemão que me repassem o procedimento, numa outra oportunidade em que tivermos reunidos, para ver como isso funciona, antes que eu coloque tais tabelas na replicação. Vamos ver como é isso. :unsure:

Editado Fevereiro 23, 2011 por Pandashop

[fulvio]

Há como você desativar os campos de autonumeração sim. Poderá acrescentar isto nos seus testes... :.)

--desabilita identity
set IDENTITY_INSERT [Nome da tabela] on

--habilitando identity
set IDENTITY_INSERT [Nome da tabela] off

[Pandashop]

Há como você desativar os campos de autonumeração sim. Poderá acrescentar isto nos seus testes... :.)

--desabilita identity
set IDENTITY_INSERT [Nome da tabela] on

--habilitando identity
set IDENTITY_INSERT [Nome da tabela] off

Ok, obrigado. Vou fazer uns testes assim que possível, Valeu! :blush: