Agrupar alterações a linhas relacionadas com registros lógicos

Aplica-se a:SQL Server

Por padrão, a replicação de mesclagem processa alterações de dados linha por linha. Em muitas circunstâncias isto é apropriado, mas para alguns aplicativos, é essencial que as linhas relacionadas sejam processadas como uma unidade. O recurso de registros lógicos da replicação de mesclagem permite definir um relacionamento entre linhas relacionadas em tabelas diferentes, para que essas linhas sejam processadas como uma única unidade.

Considere estas três tabelas relacionadas:

A tabela Customers é a tabela pai nesta relação e tem uma coluna de chave primária CustID. A tabela Orders tem uma coluna de chave primária OrderID, com uma restrição de chave estrangeira na coluna CustID que faz referência à coluna CustID na tabela Customers . De forma semelhante, a tabela OrderItems tem uma coluna de chave primária OrderItemID, com uma restrição de chave estrangeira na coluna OrderID que faz referência à coluna OrderID na tabela Orders .

Neste exemplo, um registro lógico consiste de todas as linhas na tabela Orders que são relacionadas a um valor CustID único e todas as linhas na tabela OrderItems são relacionadas a aquelas linhas na tabela Orders . Este diagrama exibe todas as linhas nas três tabelas que estão no registro lógico para Customer2:

Para definir uma relação de registro lógico entre artigos, consulte Definir uma Relação de Registro Lógico Entre Artigos da Tabela de Mesclagem.

Benefícios de registros lógicos

O recurso de registros lógicos tem dois benefícios primários:

• Aplicação das alterações de dados como uma única unidade.

• A detecção e a resolução simultâneas de conflitos em múltiplas linhas de múltiplas tabelas.

A aplicação das alterações em bloco

Se o processamento de mesclagem for interrompido, como no caso de uma conexão descartada, o conjunto parcialmente completado de alterações replicadas relacionadas será revertido se forem usados registros lógicos. Por exemplo, considere o caso onde um Assinante adiciona um novo pedido com OrderID = 6 e duas novas linhas na tabela OrderItems com OrderItemID = 10 e OrderItemID = 11 para OrderID = 6.

Se o processo de replicação for interrompido depois que a linha de Orders para OrderID = 6 for concluída, mas antes de os OrderItems 10 e 11 serem concluídos, e se registros lógicos não forem usados, o valor de OrderTotal para OrderID = 6 não será consistente com a soma dos valores de OrderAmount das linhas de OrderItems. Se forem usados registros lógicos, a linha Orders para OrderID = 6 não será efetivada até que as alterações relacionadas a OrderItems sejam replicadas.

Em um cenário diferente, se forem usados registros lógicos e alguém estiver consultando tabelas quando o processo de mesclagem estiver aplicando alterações, o usuário não verá alterações replicadas parcialmente até que todas elas sejam concluídas. Por exemplo, se o processo de replicação tiver carregado a linha de Pedidos para OrderID = 6, mas um usuário consultar as tabelas antes que o processo de replicação tenha replicado as linhas de OrderItems , o valor de OrderTotal não será o mesmo da soma dos valores de OrderAmount . Se forem usados registros lógicos, a linha de Pedidos não será visível ate que as linhas de OrderItems sejam concluídas e a transação seja confirmada como uma unidade.

A aplicação de manipulação de conflito para mais do que uma tabela

Considere o caso em que dois assinantes têm o conjunto de dados acima:

• Um usuário no primeiro Assinante altera o OrderAmount do OrderItemID 5 de 100 para 150 e o OrderTotal do OrderID 3 de 200 para 250.

• Um usuário no segundo Assinante altera o OrderAmount do OrderItemID 6 de 25 para 125 e o OrderTotal do OrderID 3 de 200 para 300.

Se essas alterações forem replicadas sem usar registros lógicos, os valores diferentes de OrderTotal resultarão em um conflito e apenas um deles será replicado. Mas as alterações não conflitantes na tabela OrderItems serão replicadas sem conflito, deixando os valores finais OrderTotal em um estado inconsistente em relação às linhas OrderItems . Se registros lógicos forem usados neste cenário, a alteração de OrderItems associada à alteração da tabela Orders que seria perdida também seria revertida, e o valor final de OrderTotal seria um sumário preciso das linhas de OrderItems.

Para mais informações sobre as opções relacionadas à detecção e à resolução de conflitos com registros lógicos, consulte Detectando e resolvendo conflitos em registros lógicos.

Considerações para usar registros lógicos

Lembre-se das seguintes considerações ao usar registros lógicos:

Considerações gerais

• É recomendável que você mantenha o número de tabelas em um registro lógico o mais baixo possível; cinco tabelas ou menos é o recomendável.

• Registros lógicos não podem fazer referência a colunas com quaisquer dos tipos de dados seguintes:

  • varchar(max) e nvarchar(max)

  • varbinary(max)

  • text e ntext

  • imagem

  • XML

  • UDT

• Não podem ser definidas relações de chave estrangeira em tabelas publicadas com a opção CASCADE. Para obter mais informações, consulte CREATE TABLE (Transact-SQL) e ALTER TABLE (Transact-SQL).

• Você não pode atualizar qualquer coluna que é usada na cláusula de relação lógica.

• A resolução de conflitos personalizada com manipuladores de lógica de negócios ou resolvedores personalizados não é compatível com artigos incluídos em um registro lógico.

• Se registros lógicos forem usados em uma publicação que inclui filtros com parâmetros, você deverá inicializar cada Assinante com um instantâneo de sua partição. Se você inicializar um Assinante com outro método, o Agente de Mesclagem falhará. Para obter mais informações, consulte Snapshots for Merge Publications with Parameterized Filters.

• Não são exibidos conflitos que envolvem registros lógicos no Visualizador de Conflitos. Para exibir informações sobre esses conflitos, use procedimentos armazenados de replicação. Para obter mais informações, consulte Exibir informações sobre conflitos em publicações de mesclagem (Programação Transact-SQL de replicação).

Configurações de Publicação

• A publicação deve ter um nível de compatibilidade de 90RTM ou maior. Para mais informações, consulte a seção "Nível de Compatibilidade para publicações” em Compatibilidade com a replicação.

• A publicação deve usar modo de instantâneo nativo. Este é o padrão a menos que você esteja replicando para SQL Server Compact, que não oferece suporte a registros lógicos.

• A publicação não pode permitir sincronização da Web. Para obter mais informações sobre a sincronização da Web, consulte Web Synchronization for Merge Replication.

• Para usar registros lógicos em uma publicação filtrada:

  • Também devem ser usadas partições pré-computadas. Os requisitos de partições pré-computadas também se aplicam a registros lógicos. Para obter mais informações, consulte Optimize Parameterized Filter Performance with Precomputed Partitions (Otimizar o desempenho do filtro parametrizado com partições pré-computadas).

  • Você não pode usar filtros com parâmetros que não se sobrepõem. Para obter mais informações, consulte a seção "Configurando opções de partição" em Filtros de linha com parâmetros.

• Se a publicação usar filtros de junções, a propriedade juntar chave exclusiva deverá ser definida como verdadeiro para todos os filtros de junção que são envolvidos em relações de registro lógico. Para obter mais informações, consulte Join Filters.

Relações entre tabelas

• Tabelas relacionadas por registros lógicos devem ter uma relação chave primária-chave estrangeira.

• A opção NOT FOR REPLICATION não pode ser definida para restrições de chave estrangeira.

• Tabelas filho podem ter só uma tabela pai.

  Por exemplo, um banco de dados que rastreia classes e estudantes poderá ter um design semelhante a:

  

  Você não pode usar um registro lógico para representar as três tabelas nessa relação, porque as linhas em ClassMembers não são associadas com uma linha de chave primária única. As tabelas Classes e ClassMembers poderiam ainda formar um registro lógico, como poderiam as tabelas ClassMembers e Students, mas não todas as três.

• A publicação não pode conter relações de filtro de junção circulares.

  Usando o exemplo com as tabelas Customers, Orderse OrderItems, você não poderia usar registros lógicos se a tabela Orders também tivesse uma restrição de chave estrangeira que fez referência à tabela OrderItems .

Implicações de desempenho de registros lógicos

O recurso de registro lógico vem com um custo de desempenho. Se não forem usados registros lógicos, o agente de replicação poderá processar todas as alterações para um determinado artigo ao mesmo tempo, e como as alterações são aplicadas no modo linha por linha, os requisitos de bloqueio e log de transação, necessários para aplicar as alterações, serão mínimos.

Se registros lógicos forem usados, o Agente de Mesclagem deverá processar as alterações para cada registro lógico inteiro, de forma conjunta. Isto tem um efeito no tempo necessário para o Agente de Mesclagem replicar as linhas. Adicionalmente, como o agente abre uma transação separada para cada registro lógico, os requisitos de bloqueio podem aumentar.

Conteúdo relacionado

• Opções de artigos para a replicação de mesclagem